copal
@copal
𝄞 ...оооо baby

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

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

Вчерашний вопрос звучал как - может ли один класс реализовывать множество не схожих по поведению интерфейсов. Типа -
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;
  }
}

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

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

Где правда?
  • Вопрос задан
  • 229 просмотров
Решения вопроса 2
Neuroware
@Neuroware
Программист в свободное от работы время
вопрос немного странно поставлен, не понятно зачем вообще в таком простом примере городить кучу интерфейсов если все это решается элементарно:
class SomeClass 
        {
         public SomeClass parent;
         public SomeClass child;
  
          void execute{

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

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

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

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

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

Данный ответ основывается на результатах оригинального исследования. :-)
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы