Инкапсуляция vs Агрегирование , размышления в различных реализациях (языках программирования)

Цитата Wound @ 23.10.19, 08:58

У тебя все классы, которые друг от друга наследуются, теперь будут наследоваться от IEvent

Это приведет к избыточности

Цитата Fester @ 23.10.19, 10:06

Это приведет к избыточности

В смысле? К какой избыточности? Они и так у тебя по факту все наследуются от одного интерфейса.

Цитата JoeUser @ 23.10.19, 09:03

1) Наследование используется, если имеем отношение "является"

Не всегда. Известная проблема Круга-Эллипса. Когда Круг является Эллипсом, но наследовать Круг от Эллипса - очень плохая идея.

Цитата Wound @ 23.10.19, 10:12

В смысле? К какой избыточности?

Если я правильно тебя понял, то ты предлагаешь что-то вроде такого:

interface IEvent
{
  string Textoverlay {get;}
}
 
class ShoeEvent : IEvent
{
  public string Textoverlay {get; }
}
 
class GameEvent : IEvent
{
  public GameEvent (ShoeEvent shoeEvent)
  {
     ShoeEvent = shoeEvent;
  }
  public ShoeEvent ShoeEvent {get; private set; }
  public string Textoverlay {get; }
}
 
class CardDrawEvent : IEvent
{
  public CardDrawEvent (GameEvent gameEvent)
  {
     GameEvent= gameEvent;
  }
  public GameEvent GameEvent{get; private set; }
  public string Textoverlay {get; }
}
 
class DiscardCardEvent : IEvent
{
  public DiscardCardEvent (CardDrawEvent cardDrawEvent)
  {
     CardDrawEvent = cardDrawEvent;
  }
  public CardDrawEvent CardDrawEvent {get; private set; }
  public string Textoverlay {get; }
}

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

Цитата applegame @ 23.10.19, 11:15

Не всегда. Известная проблема Круга-Эллипса. Когда Круг является Эллипсом, но наследовать Круг от Эллипса - очень плохая идея.

Есть еще более классическая фигня - лопата копает яму, или яма копается лопатой?

Цитата Fester @ 23.10.19, 11:21

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

Ну вот, видишь. Ты сам пришел к тому, что пытался опровергнуть, а именно:

Цитата Fester @ 22.10.19, 11:12

Цитата Wound

И я как то слабо представляю как можно, без дублирования кода, эффективно использовать агрегирование. Это же придется дублировать все методы из агрегата, в том классе в котором ты его юзаешь.

или просто сделать проперти, которая возвращает интерфейс агрегата.

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

Добавлено 23.10.19, 12:18
Если верить applegame'у, то в D - не придется копипастить все руками, язык поддерживает это из каробки. Соответственно в таком языке можно вообще уходить смело от наследования.

Сообщение отредактировано: Wound - 23.10.19, 12:18

Цитата Wound @ 23.10.19, 12:12

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

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

Добавлено 23.10.19, 12:24

Цитата Wound @ 23.10.19, 12:12

Если верить applegame'у, то в D - не придется копипастить все руками, язык поддерживает это из каробки. Соответственно в таком языке можно вообще уходить смело от наследования.

Это ради бога, вот только есть верить hh.ru, то этот D нахрен никому не нужен, а значит нет смыла тратить на него свое время

Цитата Fester @ 23.10.19, 12:22

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

Так вот многие сейчас говорят о том, что от наследования нужно отказываться вообще, полностью и навсегда. Ясный перец, что если у тебя уже есть система, которую проще переписать с нуля, чем рефакторить - никто не будет таким страдать. Но все же мне кажется это крайности.

Цитата Fester @ 23.10.19, 12:22

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

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

Добавлено 23.10.19, 12:28

Цитата Fester @ 23.10.19, 12:22

Это ради бога, вот только есть верить hh.ru, то этот D нахрен никому не нужен, а значит нет смыла тратить на него свое время

Ну ради справедливости, стоит заметить что я встречал вакансии на D, но никак основные, а как сопутствующие. Т.е. там Ищеться программист C# с знанием D, например.

Небось это контора applegame и искала спецов

Цитата OpenGL @ 23.10.19, 12:29

Небось это контора applegame и искала спецов

Цитата Астарот @ 23.10.19, 11:50

Есть еще более классическая фигня - лопата копает яму, или яма копается лопатой?

Ну это камень в другой огород. Не в огород наследования.

Цитата Wound @ 23.10.19, 12:12

Если верить applegame'у, то в D - не придется копипастить все руками, язык поддерживает это из каробки. Соответственно в таком языке можно вообще уходить смело от наследования.

Нет, динамический полиморфизм в D только через наследование. Но в некоторых случаях можно, а иногда и нужно уйти от наследования.

Цитата Fester @ 23.10.19, 12:22

Это ради бога, вот только есть верить hh.ru, то этот D нахрен никому не нужен, а значит нет смыла тратить на него свое время

Я уже писал, что такой же фокус можно провернуть как минимум на Ruby и на PHP. Ну и если верить hh.ru то и Rust "нахрен никому не нужен, а значит нет смыла тратить на него свое время". А вакансии для D периодически мелькают на форуме D.
Ну и в конце-концов, список-то довольно внушительный: Organizations using the D Language

Цитата OpenGL @ 23.10.19, 12:29

Небось это контора applegame и искала спецов

Не, контора applegame не ищет (и не искала) никаких спецов, а в данный момент вообще плотно обмазалась Elixir-ом.

Сообщение отредактировано: applegame - 23.10.19, 12:55

Цитата applegame @ 23.10.19, 11:15

Известная проблема Круга-Эллипса. Когда Круг является Эллипсом, но наследовать Круг от Эллипса - очень плохая идея.

Имхо, надуманная проблема. Наследование тогда хорошо, когда оно как минимум дополняет предка свойствами или методами. Для задание фигуры "круг" - параметров нужно меньше, чем для задания фигуры "элипс". Вывод однозначен - элипс наследуем от круга. Та же шляпа между "квадратом" и "прямоугольником". Да, можно сказать, что квадрат - частный случай прямоугольника. Не вопрос! Но для задания квадрата нужно меньше параметров, следовательно прямоугольник наследуем от квадрата. Тупо ради экономии в количестве полей.

Возникает вопрос в другом, от кого что наследовать, если параметров не добавляется? Можно и квадрат, и окружность наследовать от точки. Но можно ведь и окружность наследовать от квадрата (и наоборот). И там и там есть два параметра - точка позиционирования и второй параметр, сторона или радиус. С точки зрения кодирования - быстрее будет не от точки, ибо параметры не нужно будет N-раз прописывать. Вот тут наверное то место, где выгоднее все же прописать похожие параметры (иными словами наследоваться от точки), иначе потомки проклянут.

Цитата applegame @ 23.10.19, 12:51

Ну и если верить hh.ru то и Rust "нахрен никому не нужен, а значит нет смыла тратить на него свое время"

А-я-яй! Врешь и не краснеешь На первой же странице:

Цитата applegame @ 23.10.19, 12:51

Ну это камень в другой огород. Не в огород наследования.

Ууууу! Не видел ты, как из этой проблемы вырастали кадавры в которых ямы и лопаты наследовались от абстрактных "сущностей", а потом сливались в жарких объятьях в чем-то вроде "бытия", через которое можно было и копать яму лопатой, и наоборот ямой копатить, и вообще Но это я так, лирически набрасываю

Добавлено 23.10.19, 13:36

Цитата applegame @ 23.10.19, 12:51

а в данный момент вообще плотно обмазалась Elixir-ом.

В котором нет никакого наследования вообще

Цитата JoeUser @ 23.10.19, 13:30

Та же шляпа между "квадратом" и "прямоугольником". Да, можно сказать, что квадрат - частный случай прямоугольника. Не вопрос! Но для задания квадрата нужно меньше параметров, следовательно прямоугольник наследуем от квадрата. Тупо ради экономии в количестве полей.

Вот тут автор предлагает другое решение: https://dou.ua/lenta/articles/composition-v...itance-in-java/
Ну там он в принципе призывает отказываться от наследования. И приводит пример в самом начале.

Цитата

То, что квадрат является частным случаем прямоугольника никоим образом не означает, что должна быть иерархия классов и наследование. Нам достаточно интерфейса Фигура и класса Прямоугольник, который его реализует. Нет причин не сделать его иммутабельным, без сеттеров, с конструктором на два аргумента. Для частного случая — квадрата — может быть либо конструктор с одним аргументом, либо, что лучше, как рекомендует Блох, статический фабричный метод с названием.