Для того чтобы решать какую-то проблему нужно как минимум осознать ее существование. Т.е. увидеть ее проявления и понять, что с ними надо бороться. Именно поэтому прежде чем говорить о принципах проектирования, я хочу рассказать о том, каких именно проблем эти принципы позволяют избежать.
Жесткость (Rigidity)
Жестким считается код, в который трудно вносить даже самые простые изменения. Потому что каждое изменение влечет за собой изменения в модулях, которые зависят от изменяемого модуля. Это очень неприятная ситуация, когда изначально казавшаяся простой задача растягивается на неопределенное время из-за необходимости вносить дополнительные изменения во множестве модулей программы.
Хрупкость (Fragility)
Очень близка по смыслу с жесткостью. Так же как и с жесткостью, любое изменение в программе вызывает поломки сразу в нескольких местах. Однако в отличие от жесткости хрупкость означает появление ошибок в модулях, которые не имеют явных связей с изменяемым модулем. Ошибки этого типа хуже предыдущих, т.к. их, как правило, труднее обнаружить.
Неподвижность (Immobility)
Неподвижным можно считать код, который трудно или совсем невозможно использовать повторно. Представьте себе такую ситуацию. Вы пишете приложение, одной из задач которого будет построение отчетов. Вы решаете не тратить время на написание модуля построения отчетов с нуля, а взять его другого приложения. Когда вы переносите модуль отчетов в новый проект, оказывается, что для работы ему нужны несколько модулей из исходного проекта. Вы переносите их, а им в свою очередь тоже что-то нужно. Вы видите что, в новый проект приходится переносить гораздо больше модулей, чем вы хотели, а некоторые из них даже не имеют прямого отношения к построению отчетов. В итоге перенос оказывается не таким уж и простым, и времени занимает не меньше чем написание с нуля.
Вязкость архитектуры (Viscosity of design)
Вязкость показывает насколько сложно вносить изменения в программу, учитывая требования архитектуры. Изменения, которые не учитывают архитектуру принято называть хаками. Когда хак реализовать проще, чем изменение учитывающее архитектуру, тогда вязкость архитектуры приложения считается сильной. Т.е. проще писать "неправильный" код, чем "правильный".
Жесткость, хрупкость, неподвижность и вязкость являются признаками плохой архитектуры приложения. Они не проявляются поодиночке. Как правило, если есть один из признаков, значит, есть и все остальные. Чем же плоха архитектура, демонстрирующая эти признаки? Сама по себе она может быть не так уж и плоха. И если ничего не менять, то программа будет нормально работать и все будут счастливы. Однако рано или поздно пользователи захотят изменить или добавить какие-то функции. И вот тут вы в полной мере ощутите все прелести внесения изменений в подобную систему. Причем, если не проводить рефакторинг, то уровень хаоса в приложении будет нарастать с каждым изменением. В итоге поддержка приложения превратится в головную боль, и будет занимать неадекватно много времени.
No comments:
Post a Comment