Внутренние приложения - почему бы не сделать все публичным?

Question

Есть ли причина, по которой я не должен отмечать все как общедоступное в нашем приложении для создания отчетов в интрасети?

Никто, кроме нас, никогда не будет иметь доступ к этому коду - у нас около 20 проектов - в основном небольших иконкретный.

Есть ли действительно причина, по которой мы должны помечать что-то, кроме публики?

У меня есть свои мысли по этому поводу, которые я пытаюсь опустить, так как хочу, чтобы это былобеспристрастный.

(я слегка разделил заголовок)

Answer 1

Поиск инкапсуляции и / или «сокрытие информации» :

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

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

Answer 2

Предполагая, что вы имеете в виду пометку членов / методов класса как общедоступных / частных: речь идет не о безопасности в том смысле, что кто-то из вашей организации получает доступ к «частной» информации. Речь идет о том, как научить компилятор обнаруживать проблемы.

Например, скажем, у меня есть класс Account с двойным членом balance. и методы-члены Deposit(), Withdraw() и GetBalance(). Вызов Deposit () и Withdraw () делает две вещи: обновляет таблицу, изменяет balance

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

Answer 3

Полагаю, вы говорите об открытых членах в объектно-ориентированном программировании.

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

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

Answer 4

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

Answer 5

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

Кроме того, вы делаете предположения относительно использования кода, который вы не можете гарантировать.

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

Answer 6

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