Множественное наследование не нарушает ООП? Если не брать во внимание какой-либо конкретный язык, а рассуждать в рамках программирования,
то как выглядит множественное наследование в канонах ООП?
Прошу объяснить на своем наболевшем примере - есть класс Node с методами next, prev и есть класс
Task с его execute. Так же есть класс List c inser,Node removeNode.
И вот теперь я хочу получить класс реализующий поведение и Task и Node. Это нормально?
То есть, по сути я хочу реализовать третий класс коллекцию или в моем случаи List, который
будет оперировать нодами-тасками, но до тех пор, пока сам не станет нодой. То есть он для своих
детей будет главным узлом, но в глобальном масштабе будет обычным листом.
Но так как у меня все листы таски, то и сам узел должен быть ещё и таском. Вот как это выглядит
со стороны ООП и со стороны множественного наследования?
В моем случаи это даже не множественное наследование, а множественная реализация интерфейсов
INode, ITask и IList ( IList, это очень сильно сказано, потому что есть ещё один интерфейс, который предоставляет один метод set, в реализации которого происходит вставка переданного объекта в текущий this.next = устанавливаемый метод).
Что скажите?
Для наглядности немного кода...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;
}
}UPD:1
Спасибо всем за развернутые ответы. Сегодня, продолжая делать вчерашнее, первым что пришло в голову, это строение списка отображения. У языков, которые имеют дисплей лист, есть такие понятия, как parent и child. То есть, если я объект списка отображения и в меня вложены другие объекты списки отображения, то они child. Если меня добавят в точно такой же объект списка отображения, то я стану его чилдом, а так же у меня появится парент. Так же у меня, как у объекта дисплей листа, есть методы для добавления в меня детей.
Этот пример прям мой случай! Только как реализовано хранение детей и парентов?
У меня, как у объекта списка отображения есть лист списка отображения, которым у
меня компазиционные отношения? Или же там тоже next - prew и т.д.?
Множественное наследование не нарушает ООП? Если не брать во внимание какой-либо конкретный язык, а рассуждать в рамках программирования,
то как выглядит множественное наследование в канонах ООП?
Прошу объяснить на своем наболевшем примере - есть класс Node с методами next, prev и есть класс
Task с его execute. Так же есть класс List c inser,Node removeNode.
И вот теперь я хочу получить класс реализующий поведение и Task и Node. Это нормально?
То есть, по сути я хочу реализовать третий класс коллекцию или в моем случаи List, который
будет оперировать нодами-тасками, но до тех пор, пока сам не станет нодой. То есть он для своих
детей будет главным узлом, но в глобальном масштабе будет обычным листом.
Но так как у меня все листы таски, то и сам узел должен быть ещё и таском. Вот как это выглядит
со стороны ООП и со стороны множественного наследования?
В моем случаи это даже не множественное наследование, а множественная реализация интерфейсов
INode, ITask и IList ( IList, это очень сильно сказано, потому что есть ещё один интерфейс, который предоставляет один метод set, в реализации которого происходит вставка переданного объекта в текущий this.next = устанавливаемый метод).
Что скажите?
Для наглядности немного кода...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;
}
}UPD:1
Спасибо всем за развернутые ответы. Сегодня, продолжая делать вчерашнее, первым что пришло в голову, это строение списка отображения. У языков, которые имеют дисплей лист, есть такие понятия, как parent и child. То есть, если я объект списка отображения и в меня вложены другие объекты списки отображения, то они child. Если меня добавят в точно такой же объект списка отображения, то я стану его чилдом, а так же у меня появится парент. Так же у меня, как у объекта дисплей листа, есть методы для добавления в меня детей.
Этот пример прям мой случай! Только как реализовано хранение детей и парентов?
У меня, как у объекта списка отображения есть лист списка отображения, которым у
меня компазиционные отношения? Или же там тоже next - prew и т.д.?
то как выглядит множественное наследование в канонах ООП?
Прошу объяснить на своем наболевшем примере - есть класс Node с методами next, prev и есть класс
Task с его execute. Так же есть класс List c inser,Node removeNode.
И вот теперь я хочу получить класс реализующий поведение и Task и Node. Это нормально?
То есть, по сути я хочу реализовать третий класс коллекцию или в моем случаи List, который
будет оперировать нодами-тасками, но до тех пор, пока сам не станет нодой. То есть он для своих
детей будет главным узлом, но в глобальном масштабе будет обычным листом.
Но так как у меня все листы таски, то и сам узел должен быть ещё и таском. Вот как это выглядит
со стороны ООП и со стороны множественного наследования?
В моем случаи это даже не множественное наследование, а множественная реализация интерфейсов
INode, ITask и IList ( IList, это очень сильно сказано, потому что есть ещё один интерфейс, который предоставляет один метод set, в реализации которого происходит вставка переданного объекта в текущий this.next = устанавливаемый метод).
Что скажите?
Для наглядности немного кода...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;
}
}UPD:1
Спасибо всем за развернутые ответы. Сегодня, продолжая делать вчерашнее, первым что пришло в голову, это строение списка отображения. У языков, которые имеют дисплей лист, есть такие понятия, как parent и child. То есть, если я объект списка отображения и в меня вложены другие объекты списки отображения, то они child. Если меня добавят в точно такой же объект списка отображения, то я стану его чилдом, а так же у меня появится парент. Так же у меня, как у объекта дисплей листа, есть методы для добавления в меня детей.
Этот пример прям мой случай! Только как реализовано хранение детей и парентов?
У меня, как у объекта списка отображения есть лист списка отображения, которым у
меня компазиционные отношения? Или же там тоже next - prew и т.д.?
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
Множественное наследование может вызывать проблемы и сложности при реализации и поддержке кода, поскольку может возникнуть конфликт имен методов и свойств, объявленных в разных классах. Однако, при использовании интерфейсов, как в вашем примере, можно избежать этих проблем.
В вашем случае, класс SomeClass реализует интерфейсы INode, ITask и ISet, что является примером множественной реализации интерфейсов. Это позволяет классу иметь поведение как у Node, так и у Task, в то же время предоставляя свои собственные методы и свойства.
Что касается вашего вопроса о хранении детей и родителей в объекте списка отображения, это может быть реализовано различными способами. В зависимости от конкретных требований вашего приложения, вы можете использовать композицию объектов, хранить ссылки на детей и родителей в свойствах объекта списка отображения или создать отдельные структуры данных для хранения этих связей.
В целом, ваш подход к реализации класса SomeClass с множественной реализацией интерфейсов выглядит логичным и соответствует принципам ООП. Важно продолжать анализировать требования вашего приложения и выбирать подходящие методы и структуры данных для их реализации.