I will give an example. There is a function foo , in which you must pass two properties of two different objects. Here, the question arises how to transfer these properties more correctly - directly, or to transfer objects, and then in the function body to extract properties from them?

 function foo($id1, $id2){ return $id1+$id2 }

or

 function foo(Obj $obj1, Obj $obj2){ return $obj1->id+$obj2->id; }

It is clear that from the point of view of practicality, the first option is better. But which option will take into account the correct approaches of OOP programming and the principles of SOLID? Wouldn't the first option contradict them?

  • Very much depends on what the function does and what the objects are. Your question is too general and a clear answer to it will not work. Please add details on your specific situation to your question so that we can help you. - Dmitry Shevchenko
  • Add specifics: the function adds an entry to the table. This entry will display the "friendship" of two users, that is, both parameters are the id of two entries from the users table. So - what’s better: pass id or user objects as parameters of this function? Immediately asked the question more general, because I think that the question is relevant for many situations. - raskopin
  • Something tells me that your task with friendship generally needs to be done differently than to be wise)) - Alexey Shimansky
  • I work with the framework. so here nothing is "wise." And, by the way, an excerpt from the official help: public function store (Request $ request) {$ flight = new Flight; $ flight-> name = $ request-> name; $ flight-> save (); } - raskopin
  • In your case, only the first option. Why transfer an object for one field? Another thing, if the function will change. And as said above, there are certainly easier ways to accomplish this task. - VK

3 answers 3

It is necessary to choose the architecture of this site when.

Option 1: foo ($ id1, $ id2) If the function foo is really a function and is a component of the application logic as a single function, then it is better to transfer specific values. The less local dependencies, the better.

Option 2: foo (Obj $ obj1, Obj $ obj2) If the function foo is a class method of the application logic component, then it is better to pass an instance of the class (object) and in the arguments of the function to request a specific class for type checking. This provides security when it increases design convenience.

    Recommendations from supporters of clean code are quite clear - it is more correct to convey minimal dependencies, that is, data, and not objects in which this data is contained. The less function requires knowledge of the outside world, the easier it is to test and maintain. That is the theory.

    In practice, there are often doubts like "what if I need something else and have to change the signature" or "is it worth it to throw a text ip or IpAddress, which is a ValueObject for ip".

    So it is better to start with a minimum contract, but take into account the current and future requirements of the function, that is, how difficult it will be to change the signature to add fields or replace it with an object and data features of the object itself.

      The main principle is the principle of expediency. Why transfer entire objects when only their individual properties are needed? Moreover, semantics: let's say your function (or rather, the method) adds two numbers and you call it summarize . All around it is clear that it summarizes, not everyone understands why objects.

      Another thing, if you plan in the future to use other properties of these objects. Then the approach with the objects is correct.

      • one
        Minusanu because The answer does not consider all possible options, but only a special case. Moreover, this particular case is not so common in practice. - Razzwan 1:31
      • I would also like to see an answer that covers all possible options. If you already write it, I wish you to stock up on coffee and a sturdy keyboard. - Mik
      • one
        I have some @Ipatiev here forbidden to answer questions, if I'm not sure of the answer. I myself doubt the accuracy of my knowledge on this deep theoretical question. Let's wait for Ipatiev. (if anything, I am absolutely serious, but I re-read it, I realized that you can doubt it.) - Razzwan