Comments 7
Ужасный дизайн. Ужасное наименование классов, методов, переменных. Допотопное использование итератора.
Яркий пример, как НЕ надо программировать.
Да, и нигде не указан язык - типа, кто знает, тот сам догадается. А остальные - в баню.
Спасибо за комментарий и за Ваше мнение. Пример кода, представленный в статье, носит исключительно обучающий характер паттерна Компоновщик.
Вот именно - обучающий! Но в коде сделано всё, чтобы сбить с толку обучаемых.
Извините, а когда это вдруг стало оправданием? Обучающий код, наоборот, должен закладывать правильные паттерны его написания.
Представьте, если бы вы учились писать в первом классе по тетрадке с прописью, где все буквы написаны ужасным почерком.
Примеры не совсем отражают патерн копозиции, тут больше похоже на обычное дерево. Копозиция это больше метод расширения функционала как наследывание а точней множественного наследывания. Например у вас есть два класса и вам нужен функционал обоих в третем. Вот тут и пригодится композиция
class Class3 implements IClass1, IClass2 {
constructor(object1: IClass1, object2: IClass2) {
this._object1 = object1;
this._object2 = object2;
}
funObject1() {
return this._object1.funObject1();
}
funObject2() {
return this._object2.funObject2();
}
}
или вот еще один более жизненный пример обработчика платежей
interface IHandler {
process(params);
}
class PayHandler implements {
process(params) {
// обработка платежа
}
}
class ValidateHandler implements IHandler {
constructor(payHandler:IHandler, rules: Rule[]) {
this._payHandler = payHandler;
}
private _validate(params):boolean {
// Сдесь валидация
// ....
return true;
}
process(params) {
if(this._validate(params)) {
return this._payHandler.handler(params);
} else {
throw new Error('Validate error');
}
}
}
// Тут можно использовать напрямую обработчик
const handler = new PayHandler();
handler.process({});
// А можно завернуть в валидатор
const handler = new ValidateHandler(new PayHandler(),[
//... правила
])
handler.process({});
Спасибо за комментарий.
Определение паттерна компоновщик с wikipedia Компоновщик (англ. Composite pattern) — структурный шаблон проектирования, объединяющий объекты в древовидную структуру для представления иерархии от частного к целому. Компоновщик позволяет клиентам обращаться к отдельным объектам и к группам объектов одинаково.
То есть тут ничего нету про наследование двух и более интерфейсов.
Также информация с сайта refactoring.guru
Также нету ничего про наследование нескольких интерфейсов.
Зачем у абстрактного корневого класса реализации методов? Может их сделать абстрактными? Или даже абстрактный класс заменить интерфейсом?
Зачем у корневого класса метод add, если не всё подклассы будут его использовать/реализовывать? Может опять таки разбить интерфейсы на Компонент и ГруппируемыйКомпонент? Метод add тогда оставить второму.
Шаблон проектирования: Composite