#design-patterns #liskov-substitution-principle #flyweight-pattern
#шаблоны проектирования #принцип подстановки Лискова #шаблон наименьшего веса
Вопрос:
Вот структурная схема шаблона flyweight:
Здесь вы видите UnsharedConcreteFlyweight, который объясняет GoF:
UnsharedConcreteFlyweight : не все подклассы Flyweight должны быть общими. Интерфейс Flyweight позволяет совместное использование; он не применяет его. Для объектов UnsharedConcreteFlyweight обычно объекты ConcreteFlyweight имеют дочерние объекты ConcreteFlyweight на некотором уровне в структуре объекта flyweight (как у классов Row и Column).
Здесь, насколько я понимаю, Operation принимается в in extrinsicState качестве аргумента, но он вообще не будет его использовать, поскольку он имеет allState в качестве данных-членов.
Это хороший дизайн? Чтобы принимать аргументы, которые вы не используете, и если вы будете использовать, тогда у вас будет дублирование данных. Это может быть даже нарушением принципа подстановки Лискова?
Комментарии:
1. Я сомневаюсь, что вы редко найдете шаблон, который соответствует всем принципам SOLID для всех вариантов использования. Не так ли? «Удобство» здесь играет ключевую роль. Если мы жестко следуем какому-то принципу с огромным трудом, но достигаем всего-ничего, а не просто счастья от его следования, определенно не имеет смысла. :))
Ответ №1:
Это все равно хорошо! Принцип подстановки Лискова (LSP) полностью основан на проектировании по контракту. Пока UnsharedConcreteFlyweight.Operation удовлетворяет контракту Flyweight.Operation , проблем нет!
Игнорирование входных параметров (в данном случае внешнего состояния) является просто признаком нарушения LSP, и не всегда.