Приложение C. Правила программирования на Java

ThisIsAClassName
thisIsMethodOrFieldName

equals()
hashCode()
toString()
clone() (реализует Cloneable)
реализует Serializable
```(3) В каждом созданном вами классе рассмотрите возможность добавления метода `main()`, содержащего код для тестирования этого класса. Это позволяет использовать классы проекта без удаления тестового кода. После любых изменений можно легко вернуться к тестированию. Этот код также может служить примером того, как использовать класс.(4) Разработайте методы таким образом, чтобы они были краткими функциональными единицами, описывающими и реализующими часть непрерывного интерфейса класса. Оптимально, методы должны быть короткими. Если метод слишком длинный, рассмотрите возможность его разделения на несколько более коротких методов. Это также способствует повторному использованию кода внутри класса (в некоторых случаях методы могут быть очень большими, но они всё равно должны выполнять одну задачу).

(5) При проектировании класса представьте себя на месте программиста-клиента (способность использовать класс должна быть очевидной). Затем представьте себя на месте человека, который будет управлять этим кодом (предположите возможные виды модификаций и подумайте, какие способы могут сделать эти изменения проще).

(6) Сделайте классы максимально компактными и решайте ими только один конкретный вопрос. Вот некоторые советы по дизайну классов:

+   Сложный оператор `switch`: рассмотрите использование механизма полиморфизма

+   Количество методов, выполняющих различные действия: рассмотрите использование нескольких классов для реализации этих действий

+   Многие члены-переменные отличаются друг от друга по своим характеристикам: рассмотрите использование нескольких классов.(7) Делайте всё как можно более "частным" — `private`. Можно сделать часть библиотеки "общедоступной" (метод, класс или поле и т.д.), но это значит, что вы никогда не сможете его изменить. Если вы вынесёте его, то это может сломать существующий код других людей, заставив их переписывать и переформатировать его. Если вы будете публиковать только то, что действительно необходимо, то можете смело менять всё остальное. В многопоточной среде приватность является особенно важным фактором — только поля `private` могут быть защищены в случае ненаследования.

(8) Будьте осторожны с "синдромом огромного объекта". Для новичков, привыкших к последовательному программированию, часто проще всего начать с написания последовательной программы, а затем поместить её внутрь одного или двух огромных объектов. По принципам программирования, объекты должны представлять концепции приложения, а не само приложение.

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

(10) Каждый раз, когда вы замечаете, что классы слишком сильно связаны между собой, следует рассмотреть возможность использования вложенного класса, чтобы улучшить код и упростить обслуживание (см. раздел 14.1.2 главы 14 "Улучшение кода с помощью вложенных классов").(11) Добавляйте максимально подробные комментарии и используйте синтаксис `javadoc`, чтобы создать документацию вашего кода.

(12) Избегайте использования "магических чисел", которые сложно связать с кодом. Если вам потребуется изменить эти числа в будущем, это станет настоящей проблемой, поскольку вы не знаете, указывает ли число "100" на размер массива или на что-то совершенно другое. Поэтому создайте константы и назначьте им убедительно описывающие имена, используемые во всем вашем коде. Это поможет сделать ваш код более понятным и легче поддерживать его.(13) Когда дело доходит до конструкторов и исключений, обычно желательно перехватывать любые исключения, пойманные в конструкторе — если они вызвали ошибку создания объекта. Таким образом, вызывающий код не будет считать объект правильно созданным и продолжит работу вслепую. Когда клиентский программист завершил использование объекта, если ваш класс требует выполнение каких-либо очисточных действий, рассмотрите возможность помещения очисточного кода в хорошо определенный метод с названием типа `cleanup()`, которое явно указывает его назначение. Кроме того, вы можете поместить в класс булевое (`boolean`) значение, показывающее, был ли объект очищен. В методе `finalize()` класса убедитесь, что объект уже был очищен, и выбросьте класс, унаследованный от `RuntimeException` (если еще этого не сделали), чтобы указать на ошибку программирования. Перед применением такого подхода убедитесь, что `finalize()` работает в вашей системе (может потребоваться вызвать `System.runFinalizersOnExit(true)`, чтобы гарантировать это поведение).Примечание: В данном контексте используется терминология и стиль, характерный для русскоязычной IT-документации. (15) В определённой области видимости, если объект должен быть очищен (не через сборщик мусора), используйте следующий подход: инициализируйте объект; если это удалось, немедленно войдите в блок `try`, содержащий `finally`, чтобы начать процесс очистки.

(16) При необходимости переопределить (`override`) метод `finalize()`, помните о вызове `super.finalize()` (если `Object` является нашим прямым суперклассом, этот шаг не требуется). При переопределении `finalize()`, вызов `super.finalize()` должен быть последним действием, а не первым, что гарантирует, что компоненты базового класса остаются доступными при необходимости.

(17) При создании фиксированной коллекции объектов передайте их в массив (особенно если планируете вернуть эту коллекцию из метода). Это позволит вам воспользоваться преимуществами статической типизации массивов во время компиляции. Кроме того, получатель массива может использовать эти объекты без необходимости преобразования их в массив.(18) Предпочтительно использовать `интерфейсы` вместо `абстрактных` классов. Если известно, что что-то должно стать базовым классом, то первым выбором должно быть его определение как `интерфейса`. Только когда необходимы определённые методы или члены данных, следует выбирать `абстрактный` класс. Интерфейсы описывают действия, которые клиент хочет выполнить, тогда как классы сосредоточены на конкретной реализации этих действий.(19) В конструкторах выполняйте только те операции, которые необходимы для установки объекта в правильное состояние. Избегайте вызова других методов, поскольку они могут быть переопределены или удалены другими пользователями, что может привести к непредсказуемому поведению при создании объекта (см. подробное описание в главе  Yöntemler).

(20) Объекты должны содержать не только данные, но также иметь четко определенное поведение.

(21) При создании нового класса на основе существующего класса, сначала выберите "создание" или "реализацию". Используйте наследование только в том случае, если ваш дизайн требует обязательного наследования. Если вы используете наследование там, где можно было бы просто создать новый класс, это сделает ваш дизайн неоправданно сложным.(22) Используйте наследование и переопределение методов для представления различий в поведении, а поля для представления различий в состоянии. Очень крайний пример — использование наследования от разных классов для представления цвета, что следует полностью избегать: лучше всего использовать поле типа `Color`. Чтобы избежать проблем при программировании, убедитесь, что каждое имя в вашем классовом пути указывает только на один класс. В противном случае компилятор может сначала найти другой класс с таким же именем и выдать сообщение об ошибке. Если вы подозреваете наличие проблемы с классовым путём, попробуйте поискать файлы `.class` с тем же именем от каждого начала вашего классового пути.

(24) При использовании "адаптеров" событий в AWT Java 1.1 легко попасть в ловушку. Если вы переопределили метод адаптера, но при этом допустили ошибку в написании имени метода, то вместо того чтобы переопределить существующий метод, будет создан новый метод. Однако поскольку это абсолютно легально с точки зрения компилятора и выполнения программы, никаких сообщений об ошибках не будет — просто ваш код начнёт работать некорректно.(25) Используйте разумные паттерны проектирования для удаления "ложных функций". То есть, если вам нужна только одна экземплярная переменная класса, не ограничивайте себя заранее и не добавляйте примечание типа "генерировать только один экземпляр". Рассмотрите возможность использования паттерна Singleton. Если в основной программе много рассеянного кода для создания объектов, рассмотрите возможность его упаковки в более организованную структуру.

(26) Будьте осторожны с "аналитической параличью". Помните, что перед тем как исследовать детали проекта, следует иметь общую картину всего проекта. Это позволит быстро понять некоторые незнакомые аспекты, избегая застревания в "мертвых узлах" при анализе деталей.

(27) Будьте осторожны с "ранним оптимизированием". Сначала сделайте так, чтобы программа работала корректно, затем подумайте о том, как сделать её быстрее — но только тогда, когда действительно требуется оптимизация и существует реальная производительность, являющаяся бутылочным горлышком. Без специализированного анализа проблем производительности, вероятнее всего, вы потратите время зря. Оптимизация может привести к усложнению понимания и поддержки вашего кода.(28) Помните, что время, затраченное на чтение кода, значительно превышает время, затраченное на его написание. Ясно продуманный дизайн позволяет получить понятную программу; однако комментарии, подробные объяснения и примеры имеют огромное значение. Они важны как для вас самих, так и для последующих разработчиков. Если вы сомневаетесь в этом, подумайте о трудностях, с которыми вы сталкивались, пытаясь найти полезную информацию в онлайн-документации Java.(29) Если вы считаете, что выполнили хорошее анализирование, проектирование или реализацию, попробуйте изменить свой угол восприятия. Пригласите внешних наблюдателей — они могут быть не экспертами, но коллегами из других отделов компании. Попросите их посмотреть на вашу работу свежим взглядом и указать на возможные проблемы, которые вы могли упустить. Такой подход часто помогает выявить ключевые проблемы на ранней стадии разработки, что позволяет избежать дорогостоящих исправлений этих проблем после выпуска продукта.### Хороший дизайн приносит максимальную отдачу

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

### Веб-ресурсы для программистовНа Web можно найти множество полезных справочных материалов для программистов, включая новостные группы, форумы обсуждения и рассылки. Ниже представлен список полезных ссылок:[http://www.ulb.ac.be/esp/ip-Links/Java/joodcs/mm-WebBiblio.html](http://www.ulb.ac.be/esp/ip-Links/Java/joodcs/mm-WebBiblio.html)