Прямоугольник-квадрат
Повстречала вот реальный пример проблемы - класс Properties. Интуитивно понятно как с ним работать, кладем туда пару ключ-значение, потом достаем значение по ключу, то есть как у Hashtable. Но несмотря на то, что Properties is-a Hashtable, в то же время функциональность эквивалентная put и get у него через свои методы.
Иными словами, проблема прямоугольник-квадрат возникает, когда функциональность базового класса, должна быть ограничена контрактом функциональности потомка, например, у прямоугольника высота и ширина любые, а у квадрата только равные, в Hashtable разрешенный тип Object, а в Properties - String.
Решение, примененное в Properties не самое удачное - потомок должен расширять функциональность базового класса, а не надстраивать свою собственную поверх, в данном случае setProperty() и getProperty().
Из "правильных" мне пришли в голову следующие:
Проблему ограничения трансформаций эти способы помогают преодолеть вполне, а вот с ограничением обрабатываемых типов сложнее. Тут вариант 2 будет избыточным, а в 1 недопустимый тип сможет отсекаться только выбросом RuntimeException, что неудобно.
Поэтому в для решения проблем с типами в Java 5 есть очень удобный способ - Generics. Действительно стоило Properties унаследовать от HashMap, как исчезли бы надстройки над базовыми методами и избыточность.
Иными словами, проблема прямоугольник-квадрат возникает, когда функциональность базового класса, должна быть ограничена контрактом функциональности потомка, например, у прямоугольника высота и ширина любые, а у квадрата только равные, в Hashtable разрешенный тип Object, а в Properties - String.
Решение, примененное в Properties не самое удачное - потомок должен расширять функциональность базового класса, а не надстраивать свою собственную поверх, в данном случае setProperty() и getProperty().
Из "правильных" мне пришли в голову следующие:
- Изначально проектировать базовый класс расширяемым, то есть реализовывать паттерн Template Method. Hashtable мог бы иметь final get() и put() которые для проверки допустимости типов обращались бы к специальным методам, переопределяемым в потомке. Прямоугольник мог бы иметь в своих setHeight() и setWidth() подобные методы, которые выполняют добавочные трансформации по ограничениям потомка.
- Заменить наследование делегацией, то есть использовать паттерн Decorator. Если с потомком предполагается работать через интерфейс базового класса, то необходимо выделить общий интерфейс, который оба класса будут реализовывать. В случае Properties работать с общим интерфейсом вряд ли понадобится.
Проблему ограничения трансформаций эти способы помогают преодолеть вполне, а вот с ограничением обрабатываемых типов сложнее. Тут вариант 2 будет избыточным, а в 1 недопустимый тип сможет отсекаться только выбросом RuntimeException, что неудобно.
Поэтому в для решения проблем с типами в Java 5 есть очень удобный способ - Generics. Действительно стоило Properties унаследовать от HashMap, как исчезли бы надстройки над базовыми методами и избыточность.