Частно необходимо для автономного приложения Java?

Question

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

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

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

Если я знаю, что никто не будет использовать приложение (вызывая его методы из jar или API или что-то еще), что-то не так с тем, чтобы все было защищено? Или даже публично? Как насчет сохранения частных полей, но каждый способ публиковать? Где баланс между «правильной» доступностью на куски кода и простотой использования?

Answer 1

Как правило, нет необходимости следовать каким-либо правилам, если ваш код компилируется и работает правильно.

Однако стиль кода «лучшие практики» доказал, что улучшает качество кода, особенно со временем, когда проект развивается/созревает. Создание полей private делает ваш код более устойчивым к более поздним изменениям; если вы опускаете геттеры/сеттеры и поля доступа напрямую, любые изменения в поле, связанные с полем, гораздо более прямолинейны.

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

Наконец, чем меньше поверхность (доступные методы/поля) класс предоставляет другим классам (пользователям), тем меньше вы должны поддерживать. Уменьшение открытого API до абсолютного минимума уменьшает связь между классами, что опять-таки является преимуществом, когда что-то нужно изменить. Стремление скрыть внутреннюю работу каждого объекта как можно лучше не самоцель, а преимущества, которые являются результатом этого, являются целью.

Answer 2

Это не «необходимо», но применение стандартов хорошего дизайна и принципов кодирования даже в «небольших» проектах поможет вам в долгосрочной перспективе.

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

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

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

Другим фактором является то, что использование принципов ООП является способом укрощения сложности. Если у вас есть четко определенный API и, например, используйте только геттеры и сеттеры, вы можете отделить API от реализации в своем собственном уме. После написания класса A при написании клиента A, скажем B, вы можете думать только об API. Позже, когда вам нужно улучшить A, вы можете легко сказать, какие части A влияют на API, а какие части являются чисто внутренними. Если вы не использовали инкапсуляцию, вам придется отсканировать всю вашу кодовую базу, чтобы увидеть, может ли изменение на A сломать что-то еще.

Должен ли я применять это ко всему, что я пишу? Нет, конечно нет. Я не делаю этого с короткими одноразовыми сценариями в динамических языках (Perl, AWK и т. Д.), Но при написании Java я считаю, что всегда писать «хороший» код, хотя бы для того, чтобы мои навыки были острыми.

Answer 3

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

1. Трудно предвидеть, что произойдет с какой-то частью программного обеспечения с течением времени. Да, сегодня у вас нет пользователей. Но вы знаете, что: одно основное свойство отличное инструментов ... как только другие люди видят их, они тоже хотят их использовать. И вдруг у вас есть пользователи. И запросы функций, отчеты об ошибках ... и не ошибитесь: первые люди будут любить вас за повышение производительности вашего инструмента; и тогда они начнут оказывать на вас давление, потому что внезапно ваш инструмент необходим для других людей, чтобы сделать свои цели.
2. Многие вещи могут быть решены с помощью конвенции. Пример: иногда, если бы я использовал только публичные методы моего «теста класса», модульные тесты становятся более сложными, чем необходимо. В этом случае у меня абсолютно нет проблем с размещением геттера здесь или там, что позволяет мне проверять внутреннее состояние моего «класса под тестом»; так что мой тест может вызвать некоторую активность; а затем вызвать геттер. Я делаю эти методы «защищенными пакетами»; и я поставил над ними // used for unit testing. Я не видел проблем, возникающих из этой неофициальной практики. Обратите внимание: эти методы следует использовать только в тестовых случаях. Ни один другой производственный класс не должен их называть.
3. Что касается основного вопроса на частный материал: Я думаю, нужно всегда скрыть детали реализации извне. Всякий раз, когда вы пишете фрагмент кода, который должен жить дольше, чем на следующий час, вы должны поступать правильно - и старайтесь писать код с очень высоким качеством. И сделать внутренности ваших объектов видимыми снаружи приходит только с недостатками; в этом нет ничего позитивного. Хорошо ОО об использовании моделей, которые приходят с определенным поведением. Внутреннее состояние должно оставаться внутренним; нет никакой пользы в рекламе . Для записи: иногда у вас есть простые данные контейнеров. Классы, у которых есть только поля, но нет методов на им. В таком случае да, публикуйте поля; есть (не ) преимущество в предоставлении геттеров/сеттеров. (См. «Чистый код» на Роберт Мартин, глава 6 «Объекты и структуры данных»)