Как формируется список отображения?

Question

[copal]

Вчера задал вопрос Множественное наследование не нарушает ООП?, в котором меня раскритиковали, а сегодня у меня появился другой взгляд на этот вопрос и по этому я решил переспросить.

Вчерашний вопрос звучал как - может ли один класс реализовывать множество не схожих по поведению интерфейсов. Типа -

interface INode {
  next: INode
  prev: INode
}

interface ITask {
  execute(): void;
}

interface ISet {
  insert(target: INode): void;
};

class SomeClass implements INode, ITask, ISet{
  next: INode;
  prev: INode;
  
  execute():void {}
  insert(target: INode):void
  {
    // и здесь просиходит установка таргета
    this.next = target;
    target.prev = this;
  }
}

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

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

Где правда?

Answer 1

[Виталий Пухов]

вопрос немного странно поставлен, не понятно зачем вообще в таком простом примере городить кучу интерфейсов если все это решается элементарно:

class SomeClass 
        {
         public SomeClass parent;
         public SomeClass child;
  
          void execute{

          }
          
          void insert(SomeClass target)
          {
            this.child = target;
            target.parent = this;
          }
        }

не понял что за язык у вас в примере, пример привел в C#

Answer 2

[Freeman]

Вот интересно... Я разрабатываю язык со встроенной поддержкой SOLID (в расширенном толковании), попробую ответить на ваш вопрос.

Расширенное толкование звучит так: множественное наследование допустимо только от взаимно-абстрактных классов, -- то есть классов, не имеющих реализации одинаковых методов. Одинаковость методов в языке определяется совместимостью по присваиванию с учетом ООП.

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

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

Данный ответ основывается на результатах оригинального исследования. :-)

Comments

[copal]

Я с Вами и согласен и в то же время хочется поспорить, ведь в таком виде класс является и элементом листа и листом одновременно. И вот с этого момента начинаются внутренние споры.

[halogen]

Vapaamies, я когда-то интересовался идеей встраивания шаблонов проектирования GoF в язык как first-class citizens. Можно ли ознакомиться с вашей разработкой или с тем, каким образом идеи были реализованы в самом языке?

[Freeman]

halogen: Ссылка кагбэ у меня в профиле. Язык разрабатывается, я больше акцентировался на частностях. Раньше мои теории никому не были интересны, поэтому я и не старался их изложить. :-)

[copal]

Vapaamies: не хочу показаться занудой, но язык без интерфейсов обречен на тоску..
Восемь лет назад mvc знали 5% программистов и столько же слышали. Сегодня о mvc знают все но пользоваться им умеет не больше 10%, а пользоваться им правильно умеет, как мне кажется ещё меньше. Что говорить, когда набирающий в России безумную популярность ror сделан на ошибочной интерпретации. 90% mvc фраймворков неправильны по своему. И это сегодня.
Но завтра, когда пройдет волна mvс и образуется вакуум, кто-нибудь откроет умную книгу и узнает, что первое правило современного программирование, это строить приложение на интерфейсах, а не как сейчас подгонять их под приложение чтобы умнее казаться.

По этому язык который сегодня не введет интерфейсы, завтра будет НЕ МОДНЫМ.

[Freeman]

copal: То есть, нужно следовать моде тех 90% "фреймворков", быть неправильными и надеяться, что волна не схлынет и мода не пройдет?

[copal]

Vapaamies: наоборот. Нужно следовать лучшим традициям и надеяться, что аудитория дорастет так быстро, как только Вы введете интерфейсы.
Ведь делать TDD хотят все, а делают процентов шестьдесят, а правильно делают только те несколько процентов, которые приложения строят на интерфейсах.