How should I design a new function according to OOP?

Say I need to add some function foo that takes an instance of type A and produces an instance of type B (assuming A and B are interfaces). In object-oriented design, what are the design limitations of either of the following designs?

Design 1:

class A {
  foo(): B { /* … */ }
}

Design 2:

class B {
  static foo(a: A): B { /* … */ }
}

From the technical point of view there's no difference.

What OOP can suggest is that in a concrete case (where A, B and foo means something specific) you can refer to the SOLID/GRASP set of recommendations and check if there's a rule judging one approach over the other.

In OOP, it's a matter of responsibilities.

Take three examples:

1. A is Order, B is ProcessingResult and foo is Place and you are just implementing a domain model of your DDD approach. The natural choice for Place is Order

   public class Order 
   {
      public ProcessingResult Place() { ... }
   }
   

2. A is an auxiliary class (Parameters), B is a domain class and foo is a factory method of a the class. The natural choice for a factory method is the class it's supposed to create

   public class B
   {
      public static B Create( Parameters parameters ) { ... }
   }
   

(however, a separate factory class would also be correct here, it all depends on a content)

3. A is FooUseCaseParameters, B is FooUseCaseResult and foo is Execute and you are just designing a primary port for your hexagonal architecture. The natural choice in this case is a new class (C) which would be the FooUseCase:

   public class FooUseCase
   {
      public FooUseCaseResult Execute( FooUseCaseParameters useCase ) { ... }
   }