Почему использование класса в качестве плохой практики структуры на Java?

Недавно мы просмотрели код. Один из моих классов использовался, чтобы я мог возвращать/передавать более одного типа данных из/в методы. Единственными методами, которые были у класса, были геттеры/сеттеры. Один из членов команды (чье мнение я уважаю) сказал, что наличие такого класса - плохая практика (и не очень ООП). Почему это?

6 ответов

Есть аргумент, что классы должны либо быть "структурами данных" (т.е. сосредоточиться на хранении данных без каких-либо функций), либо "ориентироваться на функциональность" (т.е. сосредоточиться на выполнении определенных действий при сохранении минимального состояния). Если вы будете следовать этому аргументу (что имеет смысл, но не всегда легко сделать), то в этом нет ничего плохого.

На самом деле можно утверждать, что beans и entity beans по существу таковы: контейнеры данных с геттерами и сеттерами.

Я видел некоторые источники (например, книгу "чистый код" ), утверждая, что следует избегать методов с несколькими параметрами и вместо этого передавать их как один объект с геттерами и сеттерами. Это также ближе к "малой модели" названных параметров, где порядок не имеет значения.

Поэтому я считаю, что при правильном использовании ваш дизайн имеет смысл.


Обратите внимание, что здесь есть две отдельные проблемы.

  • Является ли "структуроподобный" класс разумным?

  • Создает класс для возврата нескольких значений из метода разумным?

Структурные классы

Класс объекта должен - по большей части - представлять класс объектов реального мира. Пассивная, структурированная java bean (все геттеры и сеттеры) может представлять реальную вещь.

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

Несколько возвратов метода

В то время как Python имеет это, Java не делает этого. Множественные значения возврата не являются вопросом ОО, как таковым. Это вопрос работы через языковые ограничения.

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


Честно говоря, это звучит прекрасно для меня. Какой вариант предлагает рецензент?

Следуя "лучшим практикам" ООП, и все в порядке, но вы должны быть прагматичными и фактически выполнять свою работу.

Использование значений Объекты, подобные этому (OO говорят для "struct" ), в некоторых случаях являются совершенно законным подходом.


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

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


Я думаю, что он может ввести в заблуждение "не очень ООП" для плохой практики. Я думаю, он ожидал, что вы предоставите несколько методов, каждый из которых будет возвращать 1 значение, которое было необходимо (так как вам придется использовать их в своем новом классе, в любом случае это не так уж плохо).

Обратите внимание, что в этом случае вам, вероятно, не следует использовать геттеры/сеттеры, просто сделайте данные общедоступными. Нет, это "не очень ООП", но это правильный способ сделать это.


Возможно, Джош Блох предлагает некоторое представление об этом здесь.

licensed under cc by-sa 3.0 with attribution.