Да, если оперировать объектами, а не id, то первый параметр будет не нужен. Ну а почему неправильно использовать сеттер в данном случае я писал в комментарии к соседнему вопросу.
Сергей Протько: разве эта боль не решается тем, что внутри метода likes() всё делегируется переданной сущности? То есть это однострочный метод, который введён исключительно ради красивого DSL.
Никки Априлия: как я писал выше, я сам не считаю, что здесь нужен LikesManager. Но при грамотной архитектуре можно легко менять такие решения, в этом её прелесть. Вариант, предложенный в ответе мне кажется излишне академичным и многословным, об этом я тоже выше писал.
Сергей Протько: я не вижу ничего плохого, если будет интерфейс Likable: тогда от увеличения количества сущностей ничего не пострадает.
Мне этот вариант нравится потому, что больше похоже на естественный язык, но согласен, с точки зрения чистого программирования так лучше не делать.
Ещё во многом это зависит от размера приложения. Если пользователь может делать много всего, тогда да, лучше класс не перегружать этой информацией. А если это условный Инстаграм, в котором функционала немного, я бы плясал от пользователя.
А вообще, если подумать, то конструкция (new Like())->setUser($user)->setPhoto($photo) плохая. Не может же лайк не иметь пользователя или сущность, значит их нужно передавать сразу в конструкторе. Поменяться пользователь или сущность тоже не может во время жизни лайка, так что сеттеры вообще не нужны.
Строго говоря, это действительно уже произошло, ведь лайкает он на клиенте, потом идёт запрос на сервер и уже там вызывается нужный метод. А это миллисекунд 15, не меньше, с момента лайка :)
Если в качестве источника действия установить пользователя, то можно будет написать $user->noLongerLikes($entity), чтобы снять лайк. При другой организации DSL получится страшненький.
Никки Априлия: про "не стоит делать" это я о $user->setPhoto. $like->save() мне видится вполне нормальным. В конце-концов, никто не мешает внутри делегировать сохранение тому же LikesManager, но пользовательское API оставить максимально простым и лаконичным.
Ваш API с точки зрения программирования в вакууме, конечно, хорош, но на мой взгляд это overkill. Для кровавого энтерпрайза с десятилетней поддержкой самое то, но для простых и средних приложений - многословно.
