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

Question

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

Answer 1

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

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

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

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

Answer 2

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

1. Имеет ли смысл "структурный" класс?

2. Является ли создание класса, возвращающего несколько значений из метода разумным?

Структуроподобные классы

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

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

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

Хотя у Python это есть, у Java нет. Многократные возвращаемые значения не являются вопросом OO, per se . Это вопрос прохождения языковых ограничений.

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

Answer 3

Если честно, для меня это звучит нормально. Какую альтернативу предложил рецензент?

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

Использование таких объектов-значений (OO говорит как «структура») в некоторых случаях является вполне законным подходом.

Answer 4

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

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

Answer 5

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

Answer 6

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

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