Вопрос об инкапсуляции (книга: HF OOA & D)

Question

Я читаю эту книгу (Head First Object-Oriented Design & Analysis). В главе 5 есть предложение, о котором я хотел бы рассказать о некоторых других проблемах. Книга говорит:

"Когда у вас есть набор свойств которые варьируются в зависимости от ваших объектов, используйте коллекция, как карта для хранения тех, свойства динамически. "

и далее, некоторые объяснения, почему это сделать:

"Вы удалите множество методов из ваши занятия, и избегать необходимости изменить свой код, когда новые свойства добавлены в ваше приложение ".

Я понимаю преимущество этого подхода, но разве нет и сокращения? Я имею в виду, если я использую карту для хранения этой информации (в примере это была карта String to Enum) и предоставляю метод getProperty (String) для доступа, вызывающая сторона этого метода должна знать, какие строки разрешены. Мне это как-то не нравится. Я имею в виду, конечно, вы можете утверждать, что в javadoc может быть указано, какой ввод разрешен.

Это действительно способ решения этой проблемы, есть ли альтернативы? Я понимаю, что делать это с наследованием нехорошо из-за большого количества подклассов, и эти подклассы не будут переопределять что-либо, только добавят новые свойства, которые, на мой взгляд, не очень хороши.

Answer 1

Лично я считаю, что использование Map вместо реальных полей - ужасная идея. Мне не повезло работать с системами, которые широко использовали этот (анти) шаблон, и поддерживать его было кошмаром.

Я не вижу абсолютно никакой причины использовать карты для «проверки будущего», аргумент, что вы можете избежать добавления новых методов, смешен, особенно если учесть, что добавление нового поля занимает около 20 нажатий клавиш, добавление методов получения и установки для это еще 3-4 щелчка мышью. То, что вы получаете, - это ничто, а то, что вы теряете, - это безопасность типов и проверка времени компиляции, возможность контролировать и контролировать то, что устанавливается и когда, не говоря уже о том, что вы нарушаете принцип инкапсуляции.

Следует также отметить, что развитие самого языка Java двигалось в направлении все большего количества проверок времени компиляции, причем перечисления и обобщения являются наиболее очевидными примерами этого направления. Выбросить все это еще хуже, чем это было в эпоху 1.3-1.4

Карты следует использовать только тогда, когда что-то действительно динамично, т. Е. Список ключей не может быть известен во время компиляции.

Answer 2

Вы можете реализовать свой метод getProperty для принятия значения enum в качестве ключа. Это обеспечит простой способ показать пользователю, какие ключи действительны, и вам даже не придется изменять исходный enum, когда вы хотите добавить больше, поскольку вы можете расширить enum. Конечно, может быть проще изменить исходный enum, так как это немного сбивает с толку наличие иерархии наследования enum.

Answer 3

Да, вам нужно знать ключи для получения данных. Нет, это не вызовет каких-либо фундаментальных изменений; если вы используете иерархию классов, вам нужно знать имена классов и методов для вызова.

Обратите внимание, что вы можете некоторые использовать элементы на карте, не зная имени заранее - вы можете перебирать карту и (например) показывать значения пользователю, разрешать изменение, и пусть они применяют определенные ключи к определенным настройкам.

Я не говорю, что это хорошая идея, но это можно сделать независимо от того, хорошая она или нет.