 |
Структурирование класса с учетом его изменений. Принципы проектирования классов в ООП
|
|
|
|
Вопрос 18
Структурирование класса с учетом его изменений. Принципы проектирования классов в ООП
Большинство систем находится в процессе непрерывных изменений. Каждое изменение создает риск того, что остальные части системы будут работать не так, как мы ожидаем. В чистой системе классы организованы таким образом, чтобы риск от изменений был сведен к минимуму.
Код каждого класса становится до смешного простым. Время, необходимое для понимания класса, падает почти до нуля. Вероятность того, что одна из функций нарушит работу другой, ничтожно мала. С точки зрения тестирования проверка всех фрагментов логики в этом решении упрощается, поскольку все классы изолированы друг от друга.
Что не менее важно, когда придет время добавления update, вам не придется изменять ни один из существующих классов!
Принцип проектирования классов в ООП, называемый принципом открытости/ закрытости: классы должны быть открыты для расширений, но закрыты для модификации.
Структура системы должна быть такой, чтобы обновление системы (с добавлением новых или изменением существующих аспектов) создавало как можно меньше проблем. В идеале новая функциональность должна реализовываться расширением системы, а не внесением изменений в существующий код.
Вопрос 19
Понятие эффективности программы. Выбор между эффективностью и удобочитаемостью. Оптимизирующие компиляторы
Эффективная программа не нужна, если она не обеспечивает правильных результатов.
Другой вопрос, требующий рассмотрения, состоит в том, что правильность не является дополнительной характеристикой программы в отличие от эффективности. Эффективная, но неправильная программа редко может быть сделана правильной, в то время как правильную, хотя и неэффективную программу можно оптимизировать и сделать эффективной. Нет смысла повышать быстродействие неправильной программы. Неправильное программное обеспечение бесполезно независимо от его эффективности.
|
|
|
Наиболее разумный подход к программированию заключается в создании программы наилучшим возможным способом, не уделяя особого внимания эффективности. Затем, если программа в таком виде пригодна, если она нужна для работы, если ее будут выполнять многократно и если статус проекта и фирмы позволяет, тогда и только тогда следует рассмотреть возможность ее оптимизации.
Определяйте требования к эффективности программы на стадии проектирования.
ЭФФЕКТИВНОСТЬ ИЛИ УДОБОЧИТАЕМОСТЬ
Многие методы, делающие программу эффективной, не наносят ущерба ее удобочитаемости. Эти методы следует использовать всегда.
Удобочитаемость программы более существенна, чем ее эффективность. Дело в том, что удобочитаемую программу легче отлаживать, модифицировать и использовать. А всякую большую программу обычно изменяет, модифицирует и применяет совсем не тот человек, который ее писал.
Лишь в особых случаях программу следует делать более эффективной: программа либо не помещается в памяти, либо слишком долго выполняется. Или же программа должна быть включена в библиотеку и часто использоваться. В этом случае эффективность становится очень важным фактором и ей отдают предпочтение в ущерб удобочитаемости, Удобочитаемость программы обычно более важна, чем эффективность.
ОПТИМИЗИРУЮЩИЕ КОМПИЛЯТОРЫ
Эффективность важна на двух стадиях разработки программы: компилирования и выполнения. Если компилятор работает быстро, то он обычно составляет программу, которая выполняется
медленно. Компиляторы, создающие эффективную объектную программу, обычно бывают большими и работают медленно, так как оптимизируют объектную программу.
|
|
|
В связи с этим в настоящее время на одной машине обычно используют по два компилятора для каждого входного языка. Первый компилятор работает быстро, но создает неэффективную объектную программу. Этот компилятор используется для отладки программ. Второй компилятор работает медленнее, однако производит эффективную объектную программу, оптимизируя ее. Этот компилятор используют для создания объектных модулей.
Вопрос 24
Понятие отладки. Отличие между отладкой и тестированием. Средства отладки. Защитное программирование
ОТЛАДКА ПРОГРАММ
Мало в какой области деятельности имеется столько возможностей для ошибок, как в программировании. Искусство локализации таких ошибок, когда факт их существования установлен, носит название отладки. Таким образом, отладка программы предполагает обязательное наличие той или иной ошибки, в противном случае, мы имеем дело с тестированием.
РАЗЛИЧИЕ МЕЖДУ ОТЛАДКОЙ И ТЕСТИРОВАНИЕМ
Многие программисты путают отладку программ с тестированием, предназначенным для проверки их работоспособности. Отладка имеет место тогда, когда программа со всей очевидностью работает неправильно. Поэтому отладка начинается всегда в предвидении отказа программы. Если же оказывается, что программа работает верно, то она тестируется. Часто случается так, что после прогона тестов программа вновь должна быть подвергнута отладке. Таким образом, тестирование устанавливает факт наличия ошибки, а отладка выявляет ее причину, и эти два этапа разработки программы перекрываются.
|
|
|
