1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/wizardforcel-thinking-in-java-zh

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
В этом репозитории не указан файл с открытой лицензией (LICENSE). При использовании обратитесь к конкретному описанию проекта и его зависимостям в коде.
Клонировать/Скачать
5.5 总结.md 6.9 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
Отправлено 11.03.2025 09:15 d56454c

5.5 Заключение

Для любой зависимости самое важное — это установление границ или правил, которые должны соблюдать все стороны. Создание библиотеки эквивалентно установлению отношений с пользователями этой библиотеки (т. е. "клиентскими программистами"), которые могут использовать нашу библиотеку для создания своего приложения или для создания более крупной библиотеки.

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

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

Обычно проект на C начинает сталкиваться с проблемами где-то между 50К и 100К строк кода. Это связано с тем, что C имеет всего одно "название пространства", поэтому имена начинают конфликтовать друг с другом, вызывая дополнительные затраты на управление. В Java ключевые слова package, схема названий пакетов и ключевое слово import предоставляют полный контроль над именами, позволяя легко избежать конфликтов именования.Существуют две причины необходимости контроля доступа к членам. Первая заключается в том, чтобы предотвратить доступ пользователей к тем инструментам, которые они не должны использовать. Эти инструменты необходимы для внутренних механизмов типов данных, но они не являются частью пользовательского интерфейса и не требуются пользователям для решения своих задач. Поэтому, сделав методы и поля "частными" (private), можно значительно упростить жизнь пользователям. Они могут легко видеть, какие части класса наиболее важны для них, а какие следует игнорировать. Таким образом, понимание одного класса для пользователя упрощается.Вторая и самая важная причина для контроля доступа состоит в возможности изменения внутренней работы класса разработчиком библиотеки без опасений за влияние на клиентских программистов. На начальной стадии можно создать класс одним способом, а затем выяснить, что требуется перестроить его для повышения производительности. Если интерфейсы и детали реализации были четко разделены и защищены, то можно легко достичь цели без необходимости переписывать код пользователей. Используя спецификаторы доступа в Java, можно эффективно контролировать создателя класса. Пользователи этого класса точно знают, какие части могут использовать, а какие — игнорировать. Но более важной является возможность гарантировать, что ни один пользователь не будет зависеть от каких-либо частей базового реализации класса. В качестве создателя класса мы можем свободно изменять детали базовой реализации, и эти изменения не повлияют на клиентских программистов, так как они не имеют доступа к этим частям класса. После того как вы получили возможность изменять базовую реализацию, вы можете не только улучшать свои настройки в будущем, но также иметь свободу "делать ошибки". Независимо от того, насколько внимательно были спланированы и спроектированы начальные шаги, все ещё могут возникнуть некоторые недочеты.Поскольку вы знаете, что сможете безопасно исправить эти ошибки, вы можете смело проводить больше и более свободных экспериментов. Это очень полезно для повышения вашего уровня программирования и помогает завершить проект быстрее и лучше.Открытый интерфейс класса виден всем пользователям, поэтому при анализе и проектировании это самая важная часть, которую следует сделать максимально точно. Однако нет необходимости сильно нервничать; небольшие ошибки всё ещё допустимы. Если первоначальный интерфейс имел небольшие проблемы, можно рассмотреть добавление дополнительных методов, при условии, что ничего не будет удалено, если клиентские программисты уже используют это в своих кодах.

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/wizardforcel-thinking-in-java-zh.git
git@api.gitlife.ru:oschina-mirror/wizardforcel-thinking-in-java-zh.git
oschina-mirror
wizardforcel-thinking-in-java-zh
wizardforcel-thinking-in-java-zh
master