1. Первая буква названия класса должна быть заглавной. Первая буква полей, методов и объектов (дескрипторов) должна быть строчной. Как и во всех идентификаторах, все слова, содержащиеся в нем, должны располагаться близко друг к другу, причем первая буква промежуточного слова должна быть заглавной. Например:
Скопируйте код следующим образом: ThisIsAClassName
этоисметодорфилднаме
Если в определении присутствует постоянный символ инициализатора, напишите все буквы статического конечного базового идентификатора типа заглавными. Это пометит их как константы времени компиляции.
Пакеты Java представляют собой особый случай: все они написаны строчными буквами, даже средние слова. Имена расширений доменных имен, такие как com, org, net или edu и т. д., должны быть написаны строчными буквами (это также одно из различий между Java 1.1 и Java 1.2).
2. При создании класса для общего использования примите «классическую форму» и включите определения следующих элементов:
Скопируйте код кода следующим образом:
равно()
хешкод()
toString()
clone() (реализовать Cloneable)
реализовать сериализуемый
3. Для каждого создаваемого класса рассмотрите возможность размещения функции main(), содержащей код для тестирования этого класса. Чтобы использовать классы из проекта, нам не нужно удалять тестовый код. Если внесены какие-либо изменения, можно легко вернуться к тестированию. Код также служит примером использования классов.
4. Метод должен быть спроектирован в виде краткого функционального блока, который можно использовать для описания и реализации разрывной части интерфейса класса. В идеале подход должен быть кратким и по существу. Если длина большая, рассмотрите возможность каким-либо образом разделить ее на более короткие части. Это также облегчает повторное использование кода внутри класса (иногда методы должны быть очень большими, но они все равно должны делать одно и то же).
5. При разработке класса поставьте себя на место клиентского программиста (метод использования класса должен быть предельно ясен). Затем поставьте себя на место человека, управляющего кодом (предвидите, какие изменения могут быть внесены, и подумайте, как их упростить).
6. Сделайте занятие максимально коротким и лаконичным и решайте только конкретную проблему. Вот несколько предложений по дизайну класса:
1. Сложный оператор переключения: рассмотрите возможность использования «полиморфного» механизма.
2. Большое количество методов включает в себя операции очень разных типов: рассмотрите возможность использования нескольких классов для реализации их по отдельности.
3. Многие переменные-члены имеют очень разные характеристики: рассмотрите возможность использования нескольких классов.
7. Сделайте все максимально «приватным». Вы можете сделать часть библиотеки «публичной» (метод, класс, поле и т. д.), чтобы ее никогда нельзя было удалить. Если вы его вытесните, он может разрушить существующий код других людей, вынуждая их переписывать и проектировать его. Если вы публикуете только то, что необходимо опубликовать, вы можете свободно менять все остальное. В многопоточных средах конфиденциальность является особенно важным фактором. Только частные поля могут быть защищены от несинхронизированного использования.
8. Остерегайтесь «синдрома гигантского объекта». Некоторым новичкам, привыкшим к последовательному программированию и плохо знакомым с областью ООП, часто нравится сначала писать программу последовательного выполнения, а затем встраивать ее в один или два огромных объекта. Согласно принципам программирования, объекты должны выражать концепцию приложения, а не само приложение.
9. Если вам нужно заняться каким-то неприглядным программированием, вам следует хотя бы поместить код внутри класса.
10. Всякий раз, когда вы обнаруживаете, что классы очень тесно интегрированы, вам нужно подумать, стоит ли использовать внутренние классы для улучшения работы по кодированию и сопровождению (см. «Улучшение кода с помощью внутренних классов» в главе 14, раздел 14.1.2).
11. Добавляйте комментарии как можно тщательнее и используйте синтаксис документов комментариев Javadoc для создания собственной документации по программе.
12. Избегайте использования «магических чисел». Эти числа сложно вписать в код. Если вам понадобится изменить его в будущем, это, несомненно, станет кошмаром, потому что вы понятия не имеете, относится ли «100» к «размеру массива» или к «совершенно другому». Поэтому нам следует создать константу, дать ей убедительное и описательное имя и использовать идентификаторы констант во всей программе. Это упрощает понимание и поддержку программы.
13. Когда дело доходит до сборщиков и исключений, вы обычно хотите повторно создать любое исключение, обнаруженное в сборщике, если оно привело к сбою создания этого объекта. Таким образом, вызывающий объект не будет продолжать слепо думать, что объект создан правильно.
14. Если после того, как клиентский программист завершит использование объекта, если ваш класс требует какой-либо работы по очистке, рассмотрите возможность размещения кода очистки в четко определенном методе, используя имя типа cleanup(), чтобы четко указать на ваше использование. Кроме того, внутри класса можно разместить логический флаг, указывающий, был ли объект очищен. В методе Finalize() класса убедитесь, что объект очищен и что класс, наследуемый от RuntimeException, удален (если это еще не было сделано), что указывает на ошибку программирования. Прежде чем принимать подобное решение, убедитесь, что метод Finalize() работает в вашей системе (возможно, вам придется вызвать System.runFinalizersOnExit(true), чтобы обеспечить такое поведение).
15. В определенной области, если объект должен быть очищен (не обработан механизмом сборки мусора), используйте следующий метод: инициализируйте объект; в случае успеха немедленно введите блок try, содержащий предложение Final, чтобы начать работу по очистке. .
16. Если вам нужно переопределить (отменить) Finalize() во время процесса инициализации, не забудьте вызвать super.finalize() (если Object принадлежит нашему прямому суперклассу, в этом нет необходимости). В процессе переопределения метода Finalize() вызов super.finalize() должен быть последним, а не первым действием, чтобы гарантировать, что компоненты базового класса по-прежнему действительны, когда они необходимы.
17. Создавая коллекции объектов фиксированного размера, переносите их в массив (особенно, если вы планируете возвращать эту коллекцию из метода). Таким образом, мы можем воспользоваться преимуществами проверки типа массива во время компиляции. Более того, получателю массива может не потребоваться «приводить» объект в массив, чтобы его использовать.
18. Попробуйте использовать интерфейсы вместо абстрактных классов. Если вы знаете, что что-то будет базовым классом, первым делом вам следует превратить это в интерфейс. Только когда вам нужно использовать определения методов или переменные-члены, вам нужно превратить его в абстрактный класс. Интерфейс в основном описывает то, что хочет сделать клиент, тогда как класс посвящен (или допускает) конкретные детали реализации.
19. Внутри строителя выполняйте только ту работу, которая необходима для приведения объекта в правильное состояние. По возможности избегайте вызова других методов, поскольку эти методы могут быть переопределены или отменены другими, что приведет к непредсказуемым результатам в процессе сборки (подробности см. в главе 7).
20. Объекты не должны просто хранить какие-то данные; их поведение также должно быть четко определено.
21. При создании нового класса на основе существующего класса сначала выберите «Новый» или «Создать». Эту проблему следует рассматривать только в том случае, если необходимо унаследовать ваши собственные требования к проектированию. Если наследование используется там, где разрешено новое создание, весь проект становится излишне сложным.
22. Используйте наследование и покрытие методов, чтобы выразить разницу между поведениями, и используйте поля, чтобы выразить разницу между состояниями. Крайним примером является представление цветов посредством наследования от разных классов, чего определенно следует избегать: напрямую использовать поле «цвет».
23. Чтобы избежать проблем при программировании, убедитесь, что каждое имя соответствует только одному классу, куда бы ни указывал ваш путь к классам. В противном случае компилятор может сначала найти другой класс с тем же именем и сообщить об ошибке. Если вы подозреваете, что столкнулись с проблемой пути к классу, попробуйте найти файл .class с тем же именем в каждой начальной точке пути к классам.
24. При использовании «адаптеров» событий в Java 1.1 AWT особенно легко столкнуться с ловушкой. Если метод адаптера переопределен, а метод написания не является особенным, конечным результатом будет добавление нового метода вместо переопределения существующего метода. Однако, поскольку это совершенно законно, вы не получите никаких сообщений об ошибках от компилятора или системы выполнения, а просто ваш код будет вести себя неправильно.
25. Используйте разумные проектные решения для устранения «псевдофункций». То есть, если вам нужно создать только один объект класса, не ограничивайтесь приложением заранее и добавляйте комментарий «создать только один из них». Пожалуйста, рассмотрите возможность инкапсуляции его в «единственную дочернюю» форму. Если в основной программе много разрозненного кода, который используется для создания собственных объектов, рассмотрите возможность принятия творческого решения для инкапсуляции этого кода.
26. Остерегайтесь «паралича анализа». Помните, что несмотря ни на что, вам нужно заранее понять состояние всего проекта, а затем изучить детали. Поскольку вы понимаете ситуацию в целом, вы можете быстро распознать некоторые неизвестные факторы и не впасть в «мертвую логику» при изучении деталей.
27. Остерегайтесь «преждевременной оптимизации». Сначала запустите его, потом подумайте о том, чтобы стать быстрее, но оптимизируйте только в том случае, если вам нужно и если доказано, что в какой-то части кода есть узкое место в производительности. Если вы не используете специализированные инструменты для анализа узких мест, вы, вероятно, зря тратите время. Неявная цена улучшения производительности заключается в том, что ваш код становится сложнее понимать и сложнее поддерживать.
28. Помните, вы тратите гораздо больше времени на чтение кода, чем на его написание. Четкий дизайн приводит к тому, что программа становится простой для понимания, но комментарии, подробные объяснения и несколько примеров часто оказываются неоценимыми. Они очень важны как для вас самих, так и для тех, кто за вами следует. Если вы все еще сомневаетесь в этом, просто представьте свое разочарование, пытаясь найти полезную информацию в онлайн-документации по Java, и, возможно, вы в этом убедитесь.
29. Если вы считаете, что провели хороший анализ, проектирование или реализацию, немного измените точку зрения. Попробуйте пригласить посторонних людей, не обязательно экспертов, а людей из других подразделений компании. Попросите их взглянуть на вашу работу совершенно свежим взглядом и посмотреть, смогут ли они обнаружить проблемы, к которым вы были слепы. Применяя этот метод, мы часто можем выявить некоторые ключевые проблемы на этапе, наиболее подходящем для модификации, и избежать потерь денег и энергии, вызванных решением проблем после выпуска продукта.
30. Хороший дизайн может принести максимальную отдачу. Короче говоря, часто требуется много времени, чтобы найти наиболее подходящее решение той или иной проблемы. Но как только вы найдете правильный метод, ваша дальнейшая работа станет намного легче, и вам не придется терпеть часы, дни или месяцы мучительной борьбы. Наш упорный труд принесет величайшие награды (даже неизмеримые). И поскольку я приложил к этому много усилий, я наконец получил отличный дизайн-план, и радость от успеха тоже захватывает. Не поддавайтесь искушению торопиться с работой, которая часто не стоит затраченных усилий.