Использование композиции вместо наследования

Question

Я пришел из фона ECMAScript (кажется, очень C / C ++). Таким образом, я изучил классическое наследование в стиле C ++, включающее классы , объекты и такие классные вещи, как полиморфизм .

В последнее время мне нравятся разработки для Android и iOS. Кажется, что Java основывается на C, поэтому я прекрасно использую большинство моих правил на основе C, но iOS достаточно отличается, поэтому я осторожен с моими подходами - особенно с чем-то вроде наследования объектов.

Я спрашиваю, потому что, кажется, есть некоторые сильные мнения о композиции. Из того, что я видел с композицией до сих пор, я не самый большой поклонник , если проект не дает веских оснований для работы с ним.

Вы - профессиональные разработчики Obj-C / iOS, вы бы порекомендовали композицию вместо классического наследования? Или это ситуативная вещь?

Answer 1

Объектная модель Objective-C сильно отличается от C / C ++ / Java. Он основан на сообщениях, поэтому больший упор делается на объекты, отвечающие на сообщения, а не на вызовы методов, как в C / C ++ / Java.

Подход к библиотекам Какао благоприятствует более плоской иерархии наследования объектов и опирается на шаблон делегата для настройки и поддержания плоских иерархий объектов. Зачем это делать? Многие библиотеки, особенно GUI, страдают от сложностей из-за раздувания иерархии до такой степени, что неясно, от какого класса вы унаследуете. Например, в большинстве современных объектных систем в видеоиграх (которые являются моей отраслевой компетенцией) используются композиционные парадигмы, в которых объекты создаются путем смешивания поведения, поскольку это более гибко и легче поддерживать на практике.

Я бы не сказал, что библиотеки Какао используют композиционную модель как таковую, а скорее использует взаимодействие между классами, четко разделенными в одной из областей Model-View-Controller, и использует делегирование для настройки. Хранение настройки отдельно от основной функциональности снижает сложность и иерархии более плоские.

Answer 2

Для меня это больше вопрос о том, какие классы вы используете. Если вы используете базовую основу Apple или библиотеки пользовательского интерфейса, я бы порекомендовал вам избегать создания подклассов. Многие из этих классов не являются конкретными классами, а скорее являются кластерами классов. В этих классах ОС может решить во время выполнения, какой класс на самом деле использовать.

В общем, я предпочитаю композицию, если у меня нет веских причин для подкласса. Даже когда у меня есть веская причина для подкласса, я часто вместо этого решаю создать категорию методов для исходного класса.

Answer 3

Если новый класс, как правило, следует Принципу замены Лискова по отношению к классу, из которого он получен, используйте наследование, в противном случае предпочтите композицию / агрегацию. Он не один против другого, оба широко используются.