История изменений

Чет я пропустил это решение. Скинь, пожалуйста, ссылку.

Стоимость строки кода в разных регионах и на удалёнке (комментарий)

Но я приведу пример того, почему я называю наследование негибким. Есть Event и Day — несколько типов объектов, на которые можно подписаться. Допустим, в нашей системе они настолько родственны, что есть основание создать родительский класс Subscribable и включить в него значительную часть общей реализации.

В этот момент происходит привязка к реализации, что нарушает принцип инкапсуляции.

Какой именно принцип инкапсуляции был нарушен с твоей точки зрения?

Ты не можешь легко заменить Subscribable на, допустим, IntenseSubscribable — то же самое поведение, но с другой механикой.

Если пришлось бы менять родительский класс, то это неправильная попыткая использования наследования?

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

Множественное наследование не приветствуется ни в Java, ни в C#.

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

Твой пример просто не подходит для наследования, только и всего.

Понять других людей важнее, чем опровергнуть.

Чтобы опровергнуть, если есть объективные причины для опровержения, нужно хорошо понять оппонента.

Личный опыт, сравнение с другими нежелательными аспектами создания программ (примеры есть в том же сообщении).

Композиция может использоваться одновременно с наследованием. Ненужно пытаться впихнуть в невпихуемое.

Сокращает ли наследование реализации код? Возможно.

Не возможно, а точно.

Как и процедуры.

ООП с наследованием намного сильнее сокращает код при правильном использовании, чем процедурное программирование, я уже устал объяснять.

Позволяет ли оно более просто воспринимать программу? С этим сложнее. Я не уверен.

Как раз позволяет при правильном использовании.

Я не хотел сказать, что процедуры могут сравниться или даже опередить наследование в смертельной схватке за истребление объёма кода. Я говорил о том, что это не самое главное. Говорил без деталей, но всё-таки об этом.

Главное для чего?

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

Можно накидать кривых примеров и для композиции.

Опять же, здесь существенная характеристика — абстракции. Выберешь нужные абстракции, будешь их правильно использовать — количество кода сократится.

Но при правильном использовании наследования количество кода может быть сильно меньше, чем при использовании композиции.

Чет я пропустил это решение. Скинь, пожалуйста, ссылку.

Стоимость строки кода в разных регионах и на удалёнке (комментарий)

Но я приведу пример того, почему я называю наследование негибким. Есть Event и Day — несколько типов объектов, на которые можно подписаться. Допустим, в нашей системе они настолько родственны, что есть основание создать родительский класс Subscribable и включить в него значительную часть общей реализации.

В этот момент происходит привязка к реализации, что нарушает принцип инкапсуляции.

Какой именно принцип инкапсуляции был нарушен с твоей точки зрения?

Ты не можешь легко заменить Subscribable на, допустим, IntenseSubscribable — то же самое поведение, но с другой механикой.

Если пришлось бы менять родительский класс, то это неправильная попыткая использования наследования?

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

Множественное наследование не приветствуется ни в Java, ни в C#.

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

Твой пример просто не подходит для наследования, только и всего.

Понять других людей важнее, чем опровергнуть.

Чтобы опровергнуть, если есть объективные причины для опровержения, нужно хорошо понять оппонента.

Личный опыт, сравнение с другими нежелательными аспектами создания программ (примеры есть в том же сообщении).

Композиция может использоваться одновременно с наследованием. Ненужно пытаться впихнуть в невпихуемое.

Сокращает ли наследование реализации код? Возможно.

Не возможно, а точно.

Как и процедуры.

ООП с наследованием намного сильнее сокращает код при правильном использовании, чем процедурное программирование, я уже устал объяснять.

Позволяет ли оно более просто воспринимать программу? С этим сложнее. Я не уверен.

Как раз позволяет при правильном использовании.

Я не хотел сказать, что процедуры могут сравниться или даже опередить наследование в смертельной схватке за истребление объёма кода. Я говорил о том, что это не самое главное. Говорил без деталей, но всё-таки об этом.

Главное для чего?

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

Можно накидать кривых примеров и для композиции.

Опять же, здесь существенная характеристика — абстракции. Выберешь нужные абстракции, будешь их правильно использовать — количество кода сократится.

Но при использовании наследования количество кода может быть сильно меньше, чем при использовании композиции.

Чет я пропустил это решение. Скинь, пожалуйста, ссылку.

Стоимость строки кода в разных регионах и на удалёнке (комментарий)

Но я приведу пример того, почему я называю наследование негибким. Есть Event и Day — несколько типов объектов, на которые можно подписаться. Допустим, в нашей системе они настолько родственны, что есть основание создать родительский класс Subscribable и включить в него значительную часть общей реализации.

В этот момент происходит привязка к реализации, что нарушает принцип инкапсуляции.

Какой именно принцип инкапсуляции был нарушен с твоей точки зрения?

Ты не можешь легко заменить Subscribable на, допустим, IntenseSubscribable — то же самое поведение, но с другой механикой.

Если пришлось бы менять родительский класс, то это неправильная попыткая использования наследования?

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

Множественное наследование не приветствуется ни в Java, ни в C#.

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

Твой пример просто не подходит для наследования, только и всего.

Понять других людей важнее, чем опровергнуть.

Чтобы опровергнуть, если есть объективные причины для опровержения, нужно хорошо понять оппонента.

Личный опыт, сравнение с другими нежелательными аспектами создания программ (примеры есть в том же сообщении).

Композиция может использоваться одновременно с наследованием. Ненужно пытаться впихнуть в невпихуемое.

Сокращает ли наследование реализации код? Возможно.

Не возможно, а точно.

Как и процедуры.

ООП с наследованием намного сильнее сокращает код при правильном использовании, чем процедурное программирование, я уже устал объяснять.

Позволяет ли оно более просто воспринимать программу? С этим сложнее. Я не уверен.

Как раз позволяет при правильном использовании.

Я не хотел сказать, что процедуры могут сравниться или даже опередить наследование в смертельной схватке за истребление объёма кода. Я говорил о том, что это не самое главное. Говорил без деталей, но всё-таки об этом.

Главное для чего?

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

Можно накидать кривых примеров и для композиции.

Опять же, здесь существенная характеристика — абстракции. Выберешь нужные абстракции, будешь их правильно использовать — количество кода сократится.

Но при использовании наследования количество кода может быть сильно меньше, чем при использовании композиции.