Вопрос о стиле получения / установки Java

Question

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

Я занимаюсь разработкой библиотеки, которую другие люди будут использовать на моей работе. Способ, которым другой код будет использовать мою библиотеку, по сути, для создания экземпляра основного класса и, возможно, для вызова одного или двух методов. Им не нужно будет использовать ни одну из моих структур данных или любые классы, которые я использую в фоновом режиме, чтобы добиться цели. Я, вероятно, буду основным человеком, который поддерживает эту библиотеку, но другие люди, вероятно, будут время от времени просматривать код.

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

Мой вопрос: будет ли это выглядеть как плохой стиль для других Java-программистов? Должен ли я предоставлять геттеры и сеттеры, даже когда я точно знаю, что будет получать и устанавливать мои поля, и я не беспокоюсь о том, что кто-то еще напишет что-то, что нарушит мой код?

Answer 1

Даже в вашем пакете с закрытым исходным кодом инкапсуляция - хорошая идея.

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

Answer 2

Я не думаю, что хороший язык должен иметь ЛЮБОЙ уровень доступа, кроме частного - я не уверен, что вижу выгоду.

С другой стороны, также будьте осторожны с получателями и установщиками ввсе - у них много подводных камней:

• Они склонны поощрять плохой дизайн ОО (обычно вы хотите попросить ваш объект сделать что-то для вас, а не воздействовать на его атрибуты)
• Эта плохая ОО-структура приводит к тому, что код, связанный с вашим объектом, распространяется по разным объектам и часто приводит к дублированию.
• сеттеры делают ваш объект изменчивым (что всегда приятно избегать, если вы можете)
• сеттеры и геттеры выставляют ваши внутренние структуры (если у вас есть геттер для int, позже сложно изменить его на double - вам нужно дотронуться до каждого места, к которому был получен доступ, и убедиться, что он может обрабатывать double без переполнения/ вызывая ошибку, если вы только что попросили ваш объект манипулировать значением в первую очередь, единственные изменения будут внутренними для вашего объектакт.

Answer 3

Я бы придерживался общего стиля (и в этом случае предоставил бы сеттеры / геттеры). Почему?

1. это хорошая практика, когда вы работаете с другими людьми или предоставляете библиотеки для третьих лиц
2. многие Java-фреймворки предполагают соглашения о методах получения / установки и вынуждены искать их / выставлять их / опрашивать. Если вы этого не сделаете, то ваши Java-объекты будут закрыты от этих структур и библиотек.
3. если вы используете сеттеры / геттеры, вы можете легко изменить то, что стоит за ними. Простое использование полей напрямую ограничивает вашу способность делать это.

Действительно заманчиво принять подход «только для меня», но существует множество соглашений, поскольку материал использует их и / или является хорошей практикой по определенной причине. Я постараюсь следовать им как можно больше.

Answer 4

Меня не очень заботит стиль как таковой (или любая другая догма в этом отношении), а скорее удобство ремонтопригодности , которое поставляется с набором методов получения / установки. Если вам (или кому-то еще) позже потребовалось изменить поведение, связанное с изменением одного из этих атрибутов (зарегистрировать изменения, сделать его потокобезопасным, очистить входные данные и т. Д.), Но уже напрямую изменили их во многих других мест в вашем коде, вы бы хотели, чтобы вы использовали вместо этого методы getter и setter.

Answer 5

Большинство разработчиков Java предпочитают видеть геттеры и сеттеры.

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

Если вы публично предоставляете внутреннюю реализацию класса:

• Невозможно запретить потребителям использовать класс не по назначению
• Потерян контроль над точками входа / выхода; любое публичное поле может быть изменено в любое время
• Увеличение связи между внутренней реализацией и внешними потребителями

Обслуживание геттеров и сеттеров может занять немного больше времени, но предлагает гораздо больше безопасности плюс:

• Вы можете реорганизовать свой код в любое время, сколько угодно, до тех пор, пока вы не нарушите свой публичный API (методы получения, установки и публичные методы)
• Модульное тестирование хорошо инкапсулированных классов проще - вы тестируете открытый интерфейс и все (только ваши входы / выходы в «черный ящик»)
• Наследование, компоновка и дизайн интерфейсов станут более понятными и их будет легче создавать с помощью разделенных классов
• Решите, что вам нужно добавить проверку в мутатор, прежде чем он будет установлен? Одно хорошее место в сеттере.

Вам решать, стоит ли получать дополнительное время.

Answer 6

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

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

Код должен быть написан так, чтобы он соответствовал Скажите, не спрашивайте . Вы можете практиковать это, например, выполняя упражнение Object Calisthenics .

Answer 7

Короче говоря, вы сказали: «Я спрашиваю, потому что я собираюсь, чтобы люди действительно впервые просмотрели мой код, и я хочу выглядеть так, будто знаю, что делаю». Итак, измените свой код, потому что он выглядит так, будто вы не знаете, что делаете.

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

Answer 8

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

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

Итак, чтобы прямо ответить на ваш вопрос: "Это будет выглядеть как плохой стиль?" Да, будет.

Было ли ваше решение разумным? Только если вы действительно уверены, что этот код никуда не денется. В типичном магазине могут быть шансы повторно использовать код, выделить вещи в служебные классы и т. Д. Этот код не будет кандидатом без существенных изменений. Некоторые из этих изменений могут быть автоматизированы с помощью IDE и в основном имеют низкий уровень риска, но если ваша библиотека находится на том этапе, когда она стабильна, протестирована и используется в производстве, инкапсуляция, которая в дальнейшем будет рассматриваться как больший риск, чем это было необходимо.

Answer 9

Стиль является предметом соглашения. Правильного ответа не существует, если он последовательный.

Я не фанат верблюда, но в мире Java правила camelStyle являются главными, и все переменные-члены должны быть закрытыми.

getData();
setData(int i);

Следуйте Официальному соглашению Java-кода от Sun ( кашель Oracle), и все будет в порядке.

http://java.sun.com/docs/codeconv/

Answer 10

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

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