Почему то много вопросов "что бы почитать про паттерны". Складывается ощущение, что проектирование(софта) представляется как некий перебор паттернов с целью добиться некоторого приемлемого решения. На мой взгляд проектирование это решение конкретных проблем, немалую часть которых составляют большое количество похожих и даже одинаковых фрагментов функциональности, дорогой майнтенанс, трудность и сложность передачи опыта. Разумеется, функциональные требования как и нефункциональные(энергосбережение, расход ресурсов) никто не отменял.
Сильно думаю, вся инженерия программного обеспечения она целиком и полностью про время — время, которое можно потратить на решение, время, которое можно потратить на кодирование решения, время, которое потратит процессор, решая задачу, время, которое требуется на майнтенанс, время которое необходимо для обучения новых членов команд и даже новых команд и тд и тд.
Товарищи, хватаясь за паттерны, любят повторять, что они экономят время. В этом есть какое то рациональное зерно, но вообще говоря выглядит попыткой создать просто непровальное решение, максимум — что бы работало здесь и сейчас. Такой подход даёт очень хороший расклад, который описал Льюис Керрол в своей книге. Когда веселую компанию Мартовского Зайца, Шляпника и Сони покинул Время, у них постоянно время пить чай, при чем нет времени даже мыть посуду. В переводе на разработку софта, аналогичный подход даёт жосцкий, постоянный багфикс, с припадками переписывания с нуля чуть не всего а иногда и даже больше.
В этом плане мне нравится следующее утверждение: "Время всегда побеждает". В нашем случае время можно и нужно постигать через код. Именно по изменениям в коде можно видеть, что же происходило с проектом. А если наложить на эту картину календарь реального времени, то получится очень интересная картина. Код фактически есть аккумулятор всего, что только связано с проектом, происходило или хотя бы подразумевалось
— дедлайны
— невнятные требования
— проектирование через "паттерны"
— игнорирование проблем
Поэтому, считаю, справедливо формулу выше перефразировать в "Код всегда побеждает".
Возвращаясь к паттернам, замечу, что сами паттерны возникают в любой области деятельности сами собой. Однако проблемы решаются не перебором паттернов, а пользуясь более фундаментальными принципами. Это не отменяет роль паттернов, скорее четко ограничивает их применение — место паттернов в оформлении решения, чтото похожее на стиль а так же передача опыта и знаний. Одно и то же решение можно выдать в самых разных видах. На примере парсинга XML — парсить можно "в лоб", перемешивая парсинг с логикой приложения, можно отделить парсинг от обработки, например используя SAX-парсер. Тот же SAX-парсер пожно реализовать по разному. В данном случае имеем дело с отделением поведения от реакции на это поведение. Реакцию(равно как и поведение) можно реализовать как template method, observer, шину pub-sub и тд и тд. Даже сам обсервер можно реализовать как эвенты, сигналы или даже простые колбеки. Более того, к этому можно приспособить даже view model дизайн и это будет работать, а в некоторых случаях даже отлично выглядить. И уж совершенно точно ко всему этому можно прикрутить dependency injection. Важно, что во всех этих случаях имеет место одно и то же решение, только в разном оформлении. Решение проблемы находится не в паттернах, которые только что были перечислены, а в более фундаментальных вещах — поведение, состояние, реакция, обязанности, зависимости, типы данных, инварианты, контракты и тд.
Собственно ООП обеспечивает всю необходимую фундаментальщину. С момента появления ООП уже трижды или четырежды пересматривалось, при чем весьма радикально. Более того, до сих пор существует два "больших ООП" — симуловское, т.н. классическое, которое можно наблюдать в С++, Java и тд, и смоллтолковское, от Алана Кея, который, собтсвенно и является автором понятия ООП. Из книг, на тему "что прочитать про паттерны(ООП и тд)" нужно брать книгу Бертрана Мейера "Объектно-ориентированное конструирование программных систем", содержание доступно по ссылке http://library.hse.ru/incoming/docs/book5750202550.pdf Хотя автор сильно склоняется к симуловской концепции, тем не менее он увязывает воедино не только ветви Ислама направления ООП, но и функциональное программирование, что не может не радовать.