Ну, в конкретно взятой ситуации...

я не могу придумать ни одного кейса где наследование единственно вервый выбор

не в 2016-ом году

когда памяти хоть жопой жуй

А кто сказал, что единственно верный выбор существует?

Парадигмы можно бесконечно придумывать и всех будут недостатки.

окей, просто не могу придумать кейса где наследование однозначно лучше чем композиция.

мы уже в нашей команде вводим правило что extends в коде надо обосновать.

так же как и protected)

На кулаках?)

по понятиям

Жестко у вас там.

Это мы еще даже до инкапсуляции не добрались.

Там тоже можно пояснять.

Это мы еще даже до инкапсуляции не добрались.

вообще-то Сергей как раз таки затронул этот вопрос)

ну и в целом вот эти загоны про типы это как раз про инкапсуляцию

инкапсуляция - важный принцип, причем никакого отношения к ООП он не имеет. он просто важный. Наследование - ненужный механизм.

полиморфизм - тоже присущ не только ооп, это тоже про типы

а ООП это message passing (инкапсуляция) и late binding (полиморфизм).

инкапсуляция - важный принцип, причем никакого отношения к ООП он не имеет. он просто важный. Наследование - ненужный механизм.

ребята из фейсбука решили, что для интерфейсов implements не нужен

я не до конца понимаю, зачем они вообще ввели понятие интерфейса(уже было понятие type), но есть как есть

ребята из фейсбука решили, что для интерфейсов implements не нужен

это во flow

как жить когда все immutable?

@fes0r этот Егор за AR топит

active record который

как жить когда все immutable?

нууу append only структуры, event sourcing....

@fes0r этот Егор за AR топит

я если честно не все его мысли знаю) возможно) точнее скорее он топит на DAO и row data gateway

я если честно не все его мысли знаю) возможно) точнее скорее он топит на DAO и row data gateway

ну да, скорее так

Есть спор Егорки и чувака из Spring

где они размышляют на тему "чье ООП круче"

нууу append only структуры, event sourcing....

из write model сущность, которая пересоздается, вместе с новыми ивентами и потом должна быть проброшена в в UoW

сложна

https://www.youtube.com/watch?v=Y-16C5yhKLo

https://gbracha.blogspot.com.by/2007/06/constructors-considered-harmful.html

занятно

ща осознал, что в хаскеле DIP тебя заставляет сам язык соблюдать

Какой Сергей? Ненужный для кого? Может, просто у тебя и без него все хорошо, поэтому тебе и не нужен?)

Никто часом в Ubisoft не работал?

так же как и protected)

у меня был юзер. Потом их решили разделить на покупателей и продавцов

И, собственно, решилось как? Через наследование?

И, собственно, решилось как? Через наследование?

сначала через наследование, потом я проиграл, теперь я знаю что так лучше не делать)

сейчас структура примерно такая

User { Credentials $credentials; ?Customer $customer; ?Merchant $merchant; Profile $profile; }

$profile как embeddable структура

Хорошо. Получился гибридный объект. В чем преимущество перед тем, если отнаследоваться, например: User / \ Customer Merchant \ / CustoMerchant

User { Credentials $credentials; ?Customer $customer; ?Merchant $merchant; Profile $profile; }

?

Хорошо. Получился гибридный объект. В чем преимущество перед тем, если отнаследоваться, например: User / \ Customer Merchant \ / CustoMerchant

добавь теперь Agent

и это не гибридный объект, это юзер. Он может быть мерчантом, кастомером... у него могут быть новые креды

он может "обновить" профайл

а как с кучей if борешься в таком случае?

if($user->isCustomer()) { ... } else { ... }

полиморфизмом?

$user->doSmth()

а если это действия только для определенного типа

вывываешь и функция ничего не делает?

ну, перед нами юзер и он как-то будучи не того типа это сделал, значит надо кинуть эксепшн

мол как ты сюда вообще попал чувак

я вот не парюсь, юзаю как в симфони сделано

в юзере только маркер роли

а сами роли отдельно

и юзера воспринимаю только как набор крендельков

для базовой проверки доступа к чему-либо

а дальше если есть доступ, оперирую только его id

связи с отдельными обьектами Customer/Merchant + роли да

сложна

ERROR: S client not available

user->isCustomer() или isGranted(User::ROLE_CUSTOMER)

да даже не нужно так проверять, все на уровне beforeAction или подобного

Он может быть мерчантом new Merchant(); Он может быть кастомером new Customer();

MerchantCustomer extends Merchant extends Customer ?

не вариант

?

Как отнаследоваться это уже другой вопрос. Тут говорят, что наследование в принципе не надо.

Тогда придется при условии создавать копию класса внутри

class B { public function method_from_b($s) { echo $s; } } class C { public function method_from_c($s) { echo $s; } } class A extends B { private $c; public function __construct() { $this->c = new C; } // fake "extends C" using magic function public function __call($method, $args) { $this->c->$method($args[0]); } } $a = new A; $a->method_from_b("abc"); $a->method_from_c("def");

сложно

MerchantCustomer extends Merchant extends Customer ?

множественного наследования нету в пхп

Если захотеть будет. И вопрос не про пхп.

traits?)

CustomerTrait, MerchantTrait

Его делали еще и до трейтов на костылях.

Остается только тот вариант с гребанным __call

коооомпооозиция

который я скинул наверху

зачем ты делаешь __call

если мог явно написать method_from_c

?

:magic:

Еще нашлось вот это

class Extendable{ private $extender=array(); public function addExtender(Extender $obj){ $this->extenders[] = $obj; $obj->setExtendee($this); } public function __call($name, $params){ foreach($this->extenders as $extender){ //do reflection to see if extender has this method with this argument count if (method_exists($extender, $name)){ return call_user_func_array(array($extender, $name), $params); } } } } $foo = new Extendable(); $foo->addExtender(new OtherClass()); $foo->other_class_method();

Мне кажется, тут идеологическое отличие. Наследование это иерархия связей, отношения между объектами, а композиция - создание объекта из разрозненных частей. Что-то типо усыновленного ребенка или цыганей.

Как отнаследоваться это уже другой вопрос. Тут говорят, что наследование в принципе не надо.

так оно ж твою проблему не решает никак, тогда зачем?)

Мне кажется, тут идеологическое отличие. Наследование это иерархия связей, отношения между объектами, а композиция - создание объекта из разрозненных частей. Что-то типо усыновленного ребенка или цыганей.

наследование это иерархия - да. Отношения - нет.

Мне кажется, тут идеологическое отличие. Наследование это иерархия связей, отношения между объектами, а композиция - создание объекта из разрозненных частей. Что-то типо усыновленного ребенка или цыганей.

в этом и соль. Роль "мерчант" или "кастомер" - это роль, характеристика юзера а не его тип. Просто пропертя.

у тебя может быть $roles

а может быть как у меня и метод getRoles который возвращает что чувак умеет

и да, с наследованием как раз появляются ифы, а когда все разделено на отдельные объекты, я просто там где нужен мерчант даю мерчанта, а там где нужен кастомер - даю кастомера. Где пофигу - даю юзера