18. Структурирование класса с учетом его изменений. Принципы проектирования классов в ооп.

СТРУКТУРИРОВАНИЕ С УЧЕТОМ ИЗМЕНЕНИЙ

Большинство систем находится в процессе непрерывных изменений. Каждое из­менение создает риск того, что остальные части системы будут работать не так, как мы ожидаем. В чистой системе классы организованы таким образом, чтобы риск от изменений был сведен к минимуму

Код каждого класса становится до смешного простым. Время, необходимое для понимания класса, падает почти до нуля. Вероятность того, что одна из функций нарушит работу другой, ничтожно мала. С точки зрения тестирования проверка всех фрагментов логики в этом решении упрощается, поскольку все классы изо­лированы друг от друга.

Что не менее важно, когда придет время добавления update, вам не придется из­менять ни один из существующих классов!

Принцип проектирования классов в ООП, называемый принципом открытости/ закрытости [РРР]: классы должны быть открыты для расширений, но закрыты для модификации.

Структура системы должна быть такой, чтобы обновление системы (с добав­лением новых или изменением существующих аспектов) создавало как можно меньше проблем. В идеале новая функциональность должна реализовываться расширением системы, а не внесением изменений в существующий код.

19. Понятие эффективности программы. Выбор между эффективностью и удобочитаемостью. Оптимизирующие компиляторы.

ЭФФЕКТИВНОСТЬ ПРОГРАММ

Эффективная программа не нужна, если она не обеспечивает правильных результатов.

Эффективная, но неправиль­ная программа редко может быть сделана правильной, в то время как правильную, хотя и неэффективную программу можно опти­мизировать и сделать эффективной.

Определяйте требования к эффективности программы на стадии проектирования.

ЭФФЕКТИВНОСТЬ ИЛИ УДОБОЧИТАЕМОСТЬ?

Многие методы, делающие программу эффективной, не наносят ущерба ее удобочитаемости.

Удобочитаемость программы более существенна, чем ее эффек­тивность. Дело в том, что удобочитаемую программу легче отла­живать, модифицировать и использовать. А всякую большую про­грамму обычно изменяет, модифицирует и применяет совсем не тот человек, который ее писал.

Лишь в особых случаях программу следует делать более эф­фективной: программа либо не помещается в памяти, либо слиш­ком долго выполняется. Или же программа должна быть включена в библиотеку и часто использоваться. В этом случае эффективность становится очень важным фактором и ей отдают предпочтение.

ОПТИМИЗИРУЮЩИЕ КОМПИЛЯТОРЫ

Эффективность важна на двух стадиях разработки програм­мы: компилирования и выполнения. Если компилятор работает быстро, то он обычно составляет программу, которая выполняется медленно. Компиляторы, создающие эффективную объектную про­грамму, обычно бывают большими и работают медленно, так как оптимизируют объектную программу.

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

20. Методология разработки через тестирование (tdd). Последовательность этапов разработки при использовании методологии tdd. Три закона tdd.

В 1997 году никто не слыхал о методологии TDD (Test Driven Development, то есть «разработка через тестирование»). Для подавляющего большинства разработчиков модульные тесты представляли собой короткие фрагменты временного кода, при помощи которого мы убеждались в том, что наши программы «работают». Мы тщательно выписывали свои классы и методы, а потом подмешивали специализированный код для их тестирования. Как правило, при этом использовалась какая-нибудь несложная управляющая программа, которая позволяла вручную взаимодействовать с тестируемым кодом.

Как я уже говорил, наша профессия прошла долгий путь. Сейчас я бы написал комплексный тест,

Да, мы прошли долгий путь; но дорога еще не пройдена до конца. Движения гибких методологий и TDD поощряют многих программистов писать автоматизированные модульные тесты, а их ряды ежедневно пополняются новыми сторонниками. Однако в лихорадочном стремлении интегрировать тестирование в свою работу многие программисты упускают более тонкие и важные аспекты написания хороших тестов.

ТРИ ЗАКОНА TTD

В наши дни каждому известно, что по требованиям методологии TDD модульные тесты должны писаться заранее, еще до написания кода продукта. Но это правило — всего лишь верхушка айсберга. Рассмотрим следующие три закона:

Первый закон. Не пишите код продукта, пока не напишете отказной модульный тест.

Второй закон. Не пишите модульный тест в объеме большем, чем необходимо для отказа. Невозможность компиляции является отказом.

Третий закон. Не пишите код продукта в объем большем, чем необходимо для прохождения текущего отказного теста.

Эти три закона устанавливают рамки рабочего цикла, длительность которого составляет, вероятно, около 30 секунд. Тесты и код продукта пишутся вместе, а тесты на несколько секунд опережают код продукта.

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