Философия Java


Проектировка - часть 2


Члены групповой разработки стараются избавляться от ненужных частей проекта, что существенно сказывается на их производительности.

  • Автоматизируй все! Пишите тестовый код в первую очередь (до того, как напишите сам класс) и сохраните его вместе с классом. Автоматизируйте запуск ваших тестов посредством makefile или похожей приблуды. Тогда любые изменения в коде могут быть автоматически проверены запуском теста, а Вы при этом немедленно получите все ваши ошибки. Поскольку Вы знаете о том, что ваши тесты верны и безопасны (ведь так?), то Вы можете больше экспериментировать в поиске правильного решения поставленных задач. Вспомните, что наибольшим повышением производительности в языках программирования стал встроенный тест по проверке типов, а так же по обработке исключений и т.д. Вы должны отойти от создания трудоемкой системы к для созданию тестов, которые будут проверять вашу программу на спецификации.
  • Пишите сперва тестовый код, до того, как Вы напишите ваш класс, в порядке проверки правильности проектировки. Если Вы не можете написать тестовый код, то Вы и не знаете как будет выглядеть ваш класс в действительности. В дополнение, написание тестового кода часто смывает дополнительные возможности или принуждает внести необходимые возможности в ваш класс, а так же пересмотреть модель вашего проекта. Тесты так же служат кодом примеров, показывающим, как нужно использовать ваш класс.
  • Все проблемы проектировки программного обеспечения могут быть выявлены введением дополнительного уровня абстрактного "отрешения". Это фундаментальное правило программных разработок[85] является базой абстракции, основной возможности объектно-ориентированного программирования.
  • "Отрешение" должно иметь смысл (в сочетании с принципом 9). Это означает, что все что "простое" должно быть отдельно (отдельный код в отдельном методе). Если же Вы добавите еще один уровень абстракции, то это будет уже плохо.
  • Создавайте классы настолько атомарными, на сколько это возможно. Давайте каждому классу простое, понятное предназначение. Если ваши классы или ваша система проектирования растет слишком сложной, разделите сложные классы на несколько простых. Наиболее понятным индикатором можно считать абсолютный размер: если класс велик, то есть шанс его разделить на несколько маленьких.




    Начало  Назад  Вперед