Как формируется список отображения? Вчера задал вопрос Множественное наследование не нарушает ООП?, в котором меня раскритиковали, а сегодня у меня появился другой взгляд на этот вопрос и по этому я решил переспросить.
Вчерашний вопрос звучал как - может ли один класс реализовывать множество не схожих по поведению интерфейсов. Типа -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;
}
}
И я уже было повелся на ответы, которые звучали как - "единая обязанность" и " Принцип подстановки Барбары Лисков" и даже что композиция уже полный отстой и будущие за агрегацией...
Но сегодня я открыл свой вопрос и сразу же мне в голову пришел дисплей лист.
Он и имеет тесную композиционную связь в виде ссылки на парента.
И чилдов своих сам устанавливает. И может добраться хоть до праотцов и сотых детей.
Получается один в один мой случай, в котором я и ссылки на предшествиников имею
и на детей и одновременно занимаюсь их установкой.
Где правда?
Как формируется список отображения? Вчера задал вопрос Множественное наследование не нарушает ООП?, в котором меня раскритиковали, а сегодня у меня появился другой взгляд на этот вопрос и по этому я решил переспросить.
Вчерашний вопрос звучал как - может ли один класс реализовывать множество не схожих по поведению интерфейсов. Типа -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;
}
}
И я уже было повелся на ответы, которые звучали как - "единая обязанность" и " Принцип подстановки Барбары Лисков" и даже что композиция уже полный отстой и будущие за агрегацией...
Но сегодня я открыл свой вопрос и сразу же мне в голову пришел дисплей лист.
Он и имеет тесную композиционную связь в виде ссылки на парента.
И чилдов своих сам устанавливает. И может добраться хоть до праотцов и сотых детей.
Получается один в один мой случай, в котором я и ссылки на предшествиников имею
и на детей и одновременно занимаюсь их установкой.
Где правда?
Вчерашний вопрос звучал как - может ли один класс реализовывать множество не схожих по поведению интерфейсов. Типа -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;
}
}
И я уже было повелся на ответы, которые звучали как - "единая обязанность" и " Принцип подстановки Барбары Лисков" и даже что композиция уже полный отстой и будущие за агрегацией...
Но сегодня я открыл свой вопрос и сразу же мне в голову пришел дисплей лист.
Он и имеет тесную композиционную связь в виде ссылки на парента.
И чилдов своих сам устанавливает. И может добраться хоть до праотцов и сотых детей.
Получается один в один мой случай, в котором я и ссылки на предшествиников имею
и на детей и одновременно занимаюсь их установкой.
Где правда?
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки в течение 1 года
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Поможем написать учебную работу
Ваш вопрос о множественном наследовании не нарушает ООП имеет много аспектов, и его можно рассматривать с разных точек зрения.
С одной стороны, ваш пример с классом SomeClass, который реализует несколько интерфейсов, вполне корректен в рамках объектно-ориентированного программирования. Класс реализует различные функциональности, определенные разными интерфейсами, и это может быть логичным и удобным.
С другой стороны, при использовании множественного наследования с классами (а не интерфейсами), могут возникнуть проблемы, связанные с конфликтами имен и дублированием кода. Некоторые языки программирования не поддерживают множественное наследование с классами по этой причине.
Таким образом, важно учитывать контекст и специфику языка программирования при рассмотрении вопроса о множественном наследовании. Ваш пример с классом SomeClass может быть абсолютно корректным и соответствовать принципам ООП, но в других случаях использование множественного наследования может быть менее желательным.