
- •1. Предпосылки возникновения методологии структурного программирования. Основные принципы структурного программирования. Теорема Бёма-Якопини.
- •2. Структурное программирование. Проектирование сверху вниз. Модульное программирование. Структурное кодирование
- •4. Функции. Компактность. Правило одной операции. Опасность смешения уровней абстракции
- •5. Функции. Правило понижения. Паттерн «Абстрактная фабрика» и использование оператора switch
- •6. Аргументы функций. Приемлемое количество и качество аргументов. Побочные эффекты в функциях. Примеры
- •7. Комментарии. Основные правила написания хороших комментариев. Комментарии todo.
- •8. Комментарии. Основные признаки плохих комментариев. Примеры.
- •9. Форматирование исходного кода. Цель форматирования. Вертикальное разделение концепций, вертикальное сжатие. Вертикальное расстояние
- •10. Форматирование исходного кода. Цель форматирования. Горизонтальное форматирование. Горизонтальное разделение и сжатие. Отступы
- •11. Объекты и структуры данных. Отличия процедурного и объектно-ориентированного кода. Случаи применения
- •12. Закон Деметры. Опасность построения гибридов объектов и структур данных. Объекты передачи данных и активные записи
- •13. Обработка ошибок. Исключения и коды ошибок. Использование паттерна «Особый случай».
- •14. Использование стороннего программного кода. Учебные тесты как инструмент исследования и анализа граничного кода.
- •15. Проблемы использования стороннего программного кода. Применение паттерна «Адаптер» для организации взаимодействия с недоступным кодом.
- •16. Класс. Размеры класса. Принцип единой ответственности (srp).
- •17. Понятие связности класса. Влияние связности на размер классов.
- •18. Структурирование класса с учетом его изменений. Принципы проектирования классов в ооп.
- •19. Понятие эффективности программы. Выбор между эффективностью и удобочитаемостью. Оптимизирующие компиляторы.
- •20. Методология разработки через тестирование (tdd). Последовательность этапов разработки при использовании методологии tdd. Три закона tdd.
- •21. Тестирование как важный этап процесса разработки по. Чистота тестов. Тесты как средство обеспечения изменений. Правило «одна концепция на тест».
- •22. Экономические аспекты процесса тестирования. Тестирование методами «черного» и «белого» ящика. Невозможность исчерпывающего тестирования.
- •23. Основные принципы тестирования программного обеспечения.
- •24. Понятие отладки. Отличие между отладкой и тестированием. Средства отладки. Защитное программирование
- •25. Понятие отладки. Основные принципы отладки. Принципы локализации ошибок. Принципы устранения ошибок.
- •26. Понятие отладки. Основные подходы к отладке программ. Методы «грубой силы», индуктивная отладка, дедуктивная отладка, обратная трассировка, отладка тестированием.
- •27. Проблема ограниченности вычислительных систем. Возможности преодоления некоторых типов ограничений.
- •28. Понятие правильности программ. Доказательство правильности программ. Правильность программ
- •29. Типы разложения вычислений (сочленение, выбор, повторение).
- •If условие then оператор 1 else оператор 2
- •30. Неоднозначность определения программы. Проблема сравнения программ.
- •32. Понятие рефакторинга. Рефакторинги «Согласование различий», «Миграция данных», «Выделение метода».
- •33. Понятие рефакторинга. Рефакторинги «Встраивание метода», «Выделение интерфейса», «Перемещение метода».
- •Inline method (встраивание метода)
- •34. Понятие рефакторинга. Рефакторинги «Метод в объект», «Добавление параметра», «Параметр метода в параметр конструктора».
34. Понятие рефакторинга. Рефакторинги «Метод в объект», «Добавление параметра», «Параметр метода в параметр конструктора».
В рамках TDD рефакторинг1 используется интересным образом. Обычно рефакторинг не может изменить семантику программы ни при каких условиях. В рамках TDD условия семантики формулируются при помощи тестов, которые уже срабатывают. Таким образом, и рамках TDD мы можем, например, заменить константы переменными и с чистой совестью назвать эту процедуру рсфакторин- гом, потому что набор срабат ывающих тестов при этом не изменился. Однако набор срабатывающих тестов может состоять всего из одного теста. Возможно, семантика программы должна описываться большим количеством тестов. Возможно также, что некоторые из этих потенциальных тестов в результате выполнения ^факторинга перестали бы срабатывать, если бы они существовали. Однако их пег. поэтому мы о них не беспокоимся.
Отсюда следует, что на программиста, работающею о стиле TDD, возлагается важная обязанность: он должен иметь лопаточное количество тестов» описывающих семантику программы. Достаточное по крайней мере настолько, настолько он может судить на момент завершения работы над кодом. Необходимо понимать, что рефакторинг выполняется не с учетом всех существующих тестов, а с учетом всех шзможнмх гсстов. Фраза наподобие: «Я знаю, что там была проблема, но все тесты сработали, поэтому я посчитал код завершенным и интегрировал сто и систему», — не может считаться оправданием. Пишите больше тестов.
METHOD OBJECT (МЕТОД В ОБЪЕКТ)
Каким образом лучше всего реализовать сложный метод, использующий несколько параметров и локальных переменных? Преобразуйте метод в отдельный объект.
Как
Создайте класс с таким же количеством параметров, как и оригинальный метод.
Сделайте локальные переменные метода экземплярными переменными нового класса.
Определите в новом классе метод с именем run(). Тело этого метода будет таким же, как и тело оригинального метода.
В оригинальном методе создайте новый объект и обратитесь к методу run() этого объекта.
Зачем
Объекты-методы полезны в качестве подготовительного этапа перед добавлением в систему абсолютно нового вида внутренней логики. Например, представьте, что для вычисления обшего денежного потока используется несколько разных методов, позволяющих учесть в вычислении несколько разных компонентов общего денежного потока. Вначале вы можете создать объект-метод, вычисляющий общий денежный поток первым способом. Затем вы можете описать следующий способ вычислений при помощи тестой меньшего масштаба. После этого добавление в программу нового способа вычислений будет несложным делом.
Объекты-методы также позволяют упростить код. в отношении которого неудобно использовать Extract Method (Выделение метода). В некоторых ситуациях вы вынуждены иметь дело с блоком кода» который работает с обширным набором временных переменных и параметров, и каждый раз. когда вы пытаетесь выделить хогя бы часть этого кода в отдельный метод, вы вынуждены переносить в новый метод пять или шесть временных переменных и параметров. Результирующий выделенный метод выглядит ничем не лучше, чем изначальный код, так как его сигнатура слишком длинна. В результате создания обьекга-метода вы получаете в свое распоряжение новое пространство имен, в рамках которого вы можете извлекать методы, без необходимости передачи и них каких-либо параметров.
ADD PARAMETER (ДОБАВЛЕНИЕ ПАРАМЕТРА)
Каким образом можно добавить в метод новый параметр?
Как
Если метод входит в состав интерфейса, вначале добавьте параметр в интерфейс.
Добавьте параметр.
Воспользуйтесь сообщениями об ошибках, выдаваемыми вашим компилятором, для тою чтобы узнать, в каких местах происходит обращение к данному методу. В каждом из этих мест внесите необходимые модификации в вызывающий код.
Зачем
Добавление параметра зачастую связано с расширением функциональности. Чтобы обеспечить срабатывание первою теста, вы написали код без параметра, однако далее условия изменились, и для корректного выполнения вычислений нам необходимо принять во внимание дополнительные данные.
Добавление параметра также может быть вызвано необходимостью миграции от одною представления данных к другому. Вначале вы добавляете параметр, затем вы удаляете из кода все ссылки на старый параметр, затем вы удаляете сам старый параметр.
METHOD PARAMETER TO CONSTRUCTOR PARAMETER (ПАРАМЕТР МЕТОДА В ПАРАМЕТР КОНСТРУКТОРА)
Каким образом переместить параметр из метода или методов в конструктор?
Как
Добавьте параметр в конструктор.
Добавьте в класс экэемплярную переменную с тем же именем, что и параметр.
Установите значение переменной в конструкторе.
Одну за другой преобразуйте ссылки parameter в ссылки this.parameter.
Когда в коде не останется ни одной ссылки на параметр, уладите параметр из метода.
После этого удалите ненужный теперь префикс this.
Присвойте переменной подходящее имя.
Зачем
Если вы передаете один к тот же параметр нескольким разным методам одного и того же объекта, вы можете упростить API, передав параметр только один раз (удалив дублирование). Напротив, если вы обнаружили, что некоторая экземп- лярная переменная используется только в одном методе объекта, вы можете выполнить обратный рефакторинг.