 |
Объектно-ориентированное проектирование.
|
|
|
|
ПРЕЛЮДИЯ
Модуль ПМ-05 «Разработка информационных систем» состоит из 3 частей + учебная практика и курсовой проект.
Первая часть посвящена проектированию ИС и разработке интерфейса
Вторая часть – разработка кода ИС
Третья часть – тестирование ИС
Объектно-ориентированное проектирование.
Представьте, что создается новое приложение. И в отношении него уже выработан полный и выверенный набор требований. Представьте себе еще один момент: после того как приложение будет создано, в него никогда не придется вносить изменения. В этом случае проектирование не требуется.
К сожалению, что-то должно измениться. Изменения происходят всегда. Клиенты не знают, чего хотят, нечетко выражают свои мысли. Вы порой не понимаете, что им нужно, зато знаете, как можно улучшить код. Даже самые совершенные приложения нестабильны. Приложение имело огромный успех, а теперь всем захотелось большего. Таким образом, изменения неизбежны, без них обойтись не удастся.
Приложения, легко поддающиеся изменениям, приятно создавать и комфортно расширять. Они обладают гибкостью и приспособляемостью. А приложения, сопротивляющиеся изменениям, совершенно иные: любое нововведение дается с большими затратами, и каждое из них приводит к подорожанию следующего изменения.
Объектно-ориентированные приложения составлены из взаимодействующих частей. Этими частями являются объекты, а взаимодействие осуществляется путем обмена сообщениями. Чтобы направить правильное сообщение в адрес нужного объекта, объект-отправитель сообщения должен знать, что представляет собой объект-получатель. Эти знания создают зависимости между двумя объектами, и они же мешают изменениям.
|
|
|
Объектно-ориентированное проектирование заключается в управлении зависимостями. Это набор методик создания программного кода, выстраивающих зависимости таким образом, чтобы объекты можно было изменять. При отсутствии проектирования неуправляемые зависимости порождают хаос, поскольку объекты слишком осведомлены друг о друге. Изменения, вносимые в один объект, заставляют изменять и те объекты, которые с ним сотрудничают, что, в свою очередь, заставляет вносить изменения в объекты, которые сотрудничают с этими объектами, и так до бесконечности.
В идеале: допустим, нам нужно куда-то отвезти некоторый груз на повозке. При этом нам все равно, какое конкретно абстрактное четвероногое копытное животное будет запряжено в упряжь (мул, лошадь или осёл), а животному глубоко фиолетово, какую оно тянет повозку: двух- или четырёхколесную, крытую карету или открытый воз. Точно так же грузу все равно, на чём его везут. Когда нам нужно отвезти что-то куда-то, мы просто берём этот груз, берём доступное животное и повозку и формируем упряжку (модуль верхнего уровня), которая будет двигаться и вернёт результат, когда доедет.
По факту может случиться так, что мул не может перевозить морковь (он ее ест, а заказчик уверял, что морковку они не перевозят, но через год стали перевозить), в крытую карету нельзя положить хлеб – заплесневеет и т.п. вещи, которые не были учтены.
Проектирование – это некоторая систематизация кода, таким образом, чтобы ваше приложение было экономически выгодно в настоящее время и оставалось таким же в будущем.
Понятие хорошая архитектура, следует определять именно из реальной пользы, которую она приносит, а не из абстрактных красивостей и надуманных проблем. Что же было бы, если бы продукт изначально обладал хорошей архитектурой? Его было бы легче сопровождать. Изменения вносились бы быстрее, легче и безопаснее. Это выгодно и разработчикам, и компании, и пользователям. Итак, что, по идее, должна давать хорошая архитектура? Список очевидностей:
|
|
|
Эффективность выполнения поставленных задач. Если спроектированная супер-красивая архитектура плохо выполняет поставленные задачи, не укладывается в требования по функционалу, стабильности, производительности и срокам разработки, то её вряд ли можно назвать хорошей.
Хорошо читаемый и понятный код. В первую очередь, код должен быть понятен. Пусть в вашей архитектуре нету дробления на 100500+ классов, но если код хорошо читается, не содержит дублирования, позволяет повторно использовать компоненты и вполне структурирован, – это главное.
Масштабируемость системы. Если ваша архитектура позволяет безболезненно добавлять новые сущности и функции – это хорошая архитектура.
Гибкость системы. Если ваша архитектура позволяет безболезненно вносить изменения в существующий функционал – это хорошая архитектура.
Лучшей/хорошей/приемлемой архитектурой будет та, которая будет удовлетворять перечисленным требованиям.
Чтобы достичь этой благодати, на сегодняшний день придумали целый сонм идей, принципов, подходов, методов, приемов, паттернов и правил проектирования объектно-ориентированного кода, которые мы и будем изучать.
Существуют принципы разумного проектирования SOLID, DRY, закон Деметры – это то, что мы будем изучать при проектировании. Еще одним инструментом объектно-ориентированного проектирования являются шаблоны. Шаблоны проектирования обладают невероятным функционалом. Они имеются в любом наборе инструментов проектировщика. Каждый широко известный шаблон является практически идеальным решением с открытым исходным кодом. Однако популярность шаблонов привела к своеобразному злоупотреблению ими начинающими программистами, которые из лучших побуждений применяли вполне удачные шаблоны для решения совершенно не тех проблем. Неверное использование шаблона приводит к излишне усложненному и запутанному коду. Попробуем во всем этом разобраться.
|
|
|
