Конфликт между принципом «Дизайн для расширения» и идеологией аксессоров (геттеров) / мутаторов (сеттеров)

Question

Конфликт между принципом «Дизайн для расширения» и идеологией аксессоров (геттеров) / мутаторов (сеттеров)

1

ЗАДНИЙ ПЛАН:

Анализаторы кода, такие как CheckStyle, содержат специальное правило "дизайн для расширения". Он обеспечивает действительно особый подход к дизайну класса. Как форма меня это действительно спорная вещь. Здесь была хорошая иллюстрация этого подхода к дизайну. Ключ - вы защищаете суперкласс от модификации, оставляя только маленькие "дыры". или вы делаете свои классы окончательными. Определенно хорошо для некоторых случаев безопасного создания библиотеки.

С другой стороны, у нас есть стиль Java "bean" POJO, в котором вы скрываете все ваши члены данных и предоставляете только публичные (или защищенные) аксессоры (getters) и мутаторы (сеттеры). Имея настоящие бобы жизни, это делает их практически невозможными, по моему мнению. Насколько я понимаю, единственный способ заключается в объединении компонента и повторной реализации всех необходимых аксессуаров/мутаторов. Но это серьезно снижает производительность ilke.

Я вижу, что SONAR снизил правило "дизайн для расширения" из профилей по умолчанию в 2011 году. Пожалуйста, обратите внимание, что один человек вернулся в этом году, чтобы перепроверить его ;-).

ВОПРОС:

Поэтому я планирую отказаться от правила "дизайн для расширения" из моего профиля качества Sonar, в первую очередь потому, что он делает повторное использование POJO намного сложнее, но у меня есть некоторые сомнения в том, что я пропустил какой-то подход, который позволяет использовать наследование классов с помощью аксессуаров/мутаторов, сохраняющих хорошую безопасность против потомков. Есть ли какой-либо стандартный подход, который мог бы изменить мой разум? Можно ли разрешить этот конфликт с принятым подходом "дизайн для расширения"?

Извините, не было 10 лет на Java, поэтому я действительно мог пропустить что-то огромное. ;-)

Roman Nikitchenko 06 авг. 2014, в 01:44

Источник

2

Я был бы прагматичен и спросил бы, кто является потребителями вашего кода. Если это какая-то структура для использования широкой (публичной?) Аудиторией, то вы можете тщательно рассмотреть ваши точки расширения. Частично, чтобы выразить свое намерение, частично, чтобы защитить части, которые не должны меняться. Однако, если это для внутреннего использования с небольшой аудиторией, то вы все могли бы согласиться быть немного более расслабленным.
Romski 06 авг. 2014, в 00:05
0

И это ключ, это внутренний компонент для относительно небольшой компании ... но это основной компонент инфраструктуры Big Data, поэтому он в некотором роде широко используется большинством проектов. Это вызывает мои сомнения. Однако я пришел к выводу, что могу игнорировать защиту расширений, поскольку все пользователи известны. Поэтому я решил просто не следовать этому подходу «дизайн для расширения». Но всегда хорошо переосмыслить свои подходы. ;-)
Roman Nikitchenko 06 авг. 2014, в 04:16
0

Не знаю , если это соглашение имеет имя: Но что исполнение назвать super -метод в каждом методе вы переопределить? Это гарантирует правильные расширения из расширяющего класса, вместо того, чтобы применять его в базовом классе.
Waog 06 авг. 2014, в 14:34
0

@ Комментарий Ромски должен быть ответом imho. Я бы вообще не требовал, чтобы классы были «разработаны для расширения» в духе проверки. Но если у вас есть класс, который, как вы знаете, будет значительно расширен, вы можете использовать эту проверку, чтобы убедиться, что вы продолжаете контролировать точки расширения.
barfuin 06 авг. 2014, в 20:26

Показать ещё 2 комментария

Теги:

java

design

pojo

checkstyle

javabeans

1 ответ

Ещё вопросы

Я был бы прагматичен и спросил бы, кто является потребителями вашего кода. Если это какая-то структура для использования широкой (публичной?) Аудиторией, то вы можете тщательно рассмотреть ваши точки расширения. Частично, чтобы выразить свое намерение, частично, чтобы защитить части, которые не должны меняться. Однако, если это для внутреннего использования с небольшой аудиторией, то вы все могли бы согласиться быть немного более расслабленным.
И это ключ, это внутренний компонент для относительно небольшой компании ... но это основной компонент инфраструктуры Big Data, поэтому он в некотором роде широко используется большинством проектов. Это вызывает мои сомнения. Однако я пришел к выводу, что могу игнорировать защиту расширений, поскольку все пользователи известны. Поэтому я решил просто не следовать этому подходу «дизайн для расширения». Но всегда хорошо переосмыслить свои подходы. ;-)
Не знаю , если это соглашение имеет имя: Но что исполнение назвать super -метод в каждом методе вы переопределить? Это гарантирует правильные расширения из расширяющего класса, вместо того, чтобы применять его в базовом классе.
@ Комментарий Ромски должен быть ответом imho. Я бы вообще не требовал, чтобы классы были «разработаны для расширения» в духе проверки. Но если у вас есть класс, который, как вы знаете, будет значительно расширен, вы можете использовать эту проверку, чтобы убедиться, что вы продолжаете контролировать точки расширения.

Romski · Accepted Answer · 2014-08-06T23-23-00.000Z

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