Почему использование является классом как структурой плохая практика в Java?
Это постоянное решение для MySql 5.7+ на Ubuntu 14 +:
$ sudo bash -c "echo -e \"\nsql_mode=IGNORE_SPACE,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION\" >> /etc/mysql/mysql.conf.d/mysqld.cnf"
$ sudo service mysql restart
# Check if login attempt throws any errors
$ mysql -u[user] -p # replace [user] with your own user name
Если вы можете войти в систему без ошибок - вы должны быть настроены сейчас.
6 ответов
Существует аргумент, что классы должны или быть "структурами данных" (т.е. внимание на то, чтобы хранить данные без функциональности) или "функциональности, ориентированной" (т.е. внимание на выполнение определенных действий при хранении минимального состояния). Если Вы следуете за тем аргументом (который имеет смысл, но не всегда легок сделать), затем нет ничего обязательно неправильно с этим.
На самом деле, можно было бы утверждать, что бобы и компоненты сущности по существу что - контейнеры данных с методами считывания и методами set.
я видел определенные источники (например, книга "чистый код") утверждающий, что нужно избежать методов с несколькими параметрами и вместо этого передать их как отдельный объект с методами считывания и методами set. Это также ближе к "smalltalk модель" именованных параметров, где порядок не имеет значения.
, Таким образом, я думаю, что при соответствующем использовании дизайн имеет смысл.
Обратите внимание, что существует два отдельных вопроса здесь.
-
"подобный структуре" разумный класс?
-
создает класс для возвращения нескольких значений из разумного метода?
подобные Структуре классы
класс объекта должен - по большей части - представляют класс реальных объектов. Пассивный, подобный структуре боб Java (все методы считывания и методы set) может представлять реальную вещь.
Однако большинство реальных вещей имеет правила, ограничения, поведения и основные глаголы, в которых они участвуют. Подобный структуре класс редко является хорошим соответствием для реальной вещи, это обычно - некоторая техническая вещь. Это делает это меньше, чем идеальный дизайн OO.
Несколько возвратов из метода
, В то время как Python имеет это, Java не делает. Несколько возвращаемых значений не являются вопросом о OO, по сути . Это - вопрос работы посредством ограничений языка.
Несколько возвращаемых значений могут означать, что объект изменил состояние. Возможно, один метод изменяет состояние, и некоторая группа методов считывания возвращает значения, происходящие от этого изменения состояния.
Честно говоря, это звучит прекрасным мне. Какую альтернативу рецензент предлагал?
После ООП "лучшие практики" и все в порядке, но необходимо быть прагматически настроены и на самом деле делать задание.
Используя Объекты Значения как это (OO выступают за 'структуру') совершенно законный подход в некоторых случаях.
В целом Вы захотите изолировать знание, должен был работать на класс в сам класс. Если у Вас есть класс как это, или он используется в нескольких местах и таким образом может взять часть функциональности в обоих из тех мест, или это находится в единственном месте и должно быть внутренним классом. Если это используется несколькими способами, но совершенно другими способами, такими, что нет никакой общей функциональности, имение его является единым классом, вводит в заблуждение, указывая на общую функциональность, где нет ни одного.
Однако часто существуют определенные причины того, где эти общие правила могут или не могут применяться, таким образом, это зависит от того, что Ваш класс, как предполагалось, представил.
Возможно, Josh Bloch предлагает некоторое понимание этого здесь .
Я думаю, что он мог бы путать "не очень ООП" для плохой практики. Я думаю, что он ожидал, что Вы предоставите несколько методов, которые каждый возвратят 1 значение, которое было необходимо (поскольку необходимо будет использовать их в новом классе так или иначе, который не слишком плох).
Примечание, что в этом случае Вы, вероятно, не должны использовать методы считывания/методы set, просто обнародовало данные. Нет это - "не очень ООП", но является правильным способом сделать это.