Избегайте дублирования кода в POJO Class

Предположим, у нас есть 3 класса: A, B и C. Каждый класс имеет остальные параметры. Как это: EDIT:Избегайте дублирования кода в POJO Class

+-----+ +-----+ +-----+ 
| A | | B | | C | 
------- ------- ------- 
| X x | | X x | | Z z | 
| Z z | | Y Y | | Y y | 
------- ------- -------

Геттеры и сеттеры будут дублироваться. Итак, это плохая практика, и мы должны избегать этого? Или это не следует воспринимать как код дублирования анализаторами кода (например, PMB)?

Я думал о «стратегии шаблон», но я думаю, что это может быть слишком много, просто для получения и установки ...

EDIT: Мой первый вопрос, может быть, не совсем понятно. Вопрос в том, есть ли у нас два класса (не связанные) с общим атрибутом и точно таким же геттером/сеттером. Сонар или PMD должны рассматривать эти методы как дублированный код или нет? А если нет, будет ли это исправлено?

источник

2012-05-25 Pith

Эти классы кажутся очень плотно связанными. Почему они? –

Неправильное копирование кода. Почему вы не можете просто указать класс B из A и использовать методы таким образом? – Limey

A.getB() не должен означать то же, что C.getB(). Так что это не дублируется. Тем не менее, я видел где-то аннотации '@ Getter' и' @ Setter', которые упрощают даже это (я не помню, какая инфраструктура/библиотека была) – SJuan76

Как уже отмечалось, сначала подумайте, действительно ли вам нужно дублирование. Возможно, они должны быть в общем объекте, который проходит мимо. Может быть, они не нужны.

Теперь давайте предположим, что они действительно необходимы. Что может быть, конечно. Детектор копирования пачки PMD позволяет установить минимальное количество строк до того, как он будет считаться дубликатом. Поскольку геттер/сеттер имеет только три строки (или 6 для обоих), вы можете установить порог чуть выше.

источник

2012-05-26 02:44:43

Это круговая ссылка и, как правило, плохая практика. Можете ли вы перепроектировать, чтобы не делать этого?

источник

2012-05-25 14:23:21 Starkey

Да, вы правы, но в моем реальном случае нет круглых ссылок. Я отредактирую свой пост, чтобы иметь лучший пример. – Pith

Сеттеры и геттеры автоматически генерируют код, поэтому они никогда не дублируют код (кто-то, кто пишет их вручную)?

Единственная проблема, которую вы должны рассмотреть, - это если у вас есть дублирование данных? И на вашем примере нет способа сказать, потому что поле «b» в классах «A» и «C» может иметь другое значение.

Это как поле «Адрес» в «Клиент» и «Строительство». Это означает что-то еще.

источник

2012-05-25 14:30:31

В Java, getters и seters не генерируются автоматически. Вы должны думать о C#. –

@Matt Ball: для java-разработчиков требуется много времени, чтобы заставить eclipse генерировать геттеры и сеттеры, eclipse также отражает переименования полей в get/seters. – Synox

Дублирующий код не всегда является ошибочной идеей, в некоторых случаях неизбежно делать некоторые клоны. Также верно, что сеттеры и геттеры в настоящее время генерируются, но для и в то время как петли также генерируются, и эти коды не должны автоматически исключаться, поскольку они поддерживаются вручную. Агрессивное устранение дублирования кода без какого-либо рассмотрения не является хорошей идеей. В основном не все дублирования плохие, и это не всегда оправдывает их устранение. То, что окупается, - это так называемое управление клонами, т. Е. Отслеживание существующих дубликатов и устранение тех, которые действительно вызывают проблемы. Для этого вам нужен сложный инструмент, например FrontEndART QualityGate, который включает в себя модуль CloneManager. Он не только перечисляет дубликаты, но и отслеживает их жизнь через версии и позволяет узнать, какие дублирования вы должны смотреть ближе. Вы можете проверить этот инструмент на online demo version of QualityGate.

источник

2014-08-14 13:04:53

Избегайте дублирования кода в POJO Class

ответ

Смежные вопросы