Какие существуют подходы к проектированию систем?

Question

[linqu]

Например существует каркасный подход в проектировании приложений (хотя прохо понимаю как этот подход наложить на php). А какие еще подходы есть в проектировании систем? Либо подскажите, пожалуйста, литературу соответсвующую.

Comments

[linqu]

Или вообще чушь я какую-то спрашиваю?

Answer 1

[Mikhail Osher]

Приемы объектно-ориентированного проектирования. Паттерны проектирования
Design Patterns: Elements of Reusable Object-Oriented Software
Автор: Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес

ака «Банда четырех». Лично я считаю, что каждый разработчик должен знать паттерны проектирования.

Comments

[Александр]

Мне кажется паттерны это не совсем то что автор ищет. Паттерны это детали реализации, нужна стратегия, поход к процессу проектирования, как я понял

[Николай Турнавиотов]

думаю, что общее понятие в любом случае не помешает. а вообще надо понять для себя что хочется от приложения, максимально точно поставить ТЗ — в вопросе, как правило, 80% ответа…

[linqu]

Спасибо за литературу, бум просвещатся.
Но действительно, как обратил внимание ncix, сейчас больше интересует какие подходы вообще существуют (не хочется тратить время на выдумывание велосипеда). Паттерны же описывают готовые подходы к созданию объектов, взаимодействию между объектами. А вот существуют ли подобные паттерны к проектированию в целом? Что-то типа модульной архитектуры или монолитной системы или еще что-то такое. Или среди этих паттернов есть такие, которые как раз описывают как могут строится приложения (может чего-то я упустил)?

[linqu]

Даже в приведенной книге говорится только о каркасном подходе (если я правильно понимаю, он же модульный). И ничего кроме найти не получается, наверное ничего больше и нет…
Спасибо за помощь :)

Answer 2

[Александр]

Прежде всего декомпозиция. Причем многоуровневая. Берёте весь проект, делите на основные части (сервер, БД, клиент). Каждую часть снова делите. На каждом уровне компонентов должно получаться немного.

Далее прототип каждого компонента.

Потом либо прототип превращаете в приложение, либо пишите с нуля с учетом опыта прототипа. Последнее намного лучше, но краткосрочно затратнее

Comments

[linqu]

Разбить задачу на множество подзадач? Безусловно. Но как реализации этих подзадач будут между собой связаны? Вопрос, который меня сейчас мучает, как раз в том, какие существуют подходы в разбиении всей задачи на подзадачи и связи этих кусков между собой? Пока смог найти только боле-менее внятное описание каркасного подхода. Представляю себе как можно всю задачу сделать монолитной (понятно что такое решения для боле-менее крупных проектов не годится). Но может быть есть какие-то другие готовые приемы?

[Николай Турнавиотов]

А как реализации этих подзадач должны быть связаны, наверное будет известно на этапе содания техзадания.
Зачем монолитной? Классика — есть обьект — у него есть вход, выход. надо что-то большее? главное, наверное, не перебарщивать со вложенностями, а то видел я как-то пример a -> b -> c-> d -> e -> маленькое свойство(f).

[linqu]

Я именно это и имел в виду — сильная сввязанность классов порождает монолитную архитектуру: очень сложно убрать или заменить какой либо класс без изменения классов, которые с ним связаны.

Answer 3

[Николай Турнавиотов]

Попробуйте поискать по ключевому слову паттерны программирования, ООП.\
сам сейачс активно интересуюсь, правда под C#

Answer 4

[Виталий Юшкевич]

Смотря какой проект. Если очень большой — то его следует разбивать на части, стараться искать оптимальные решения, изобретать минимум велосипедов, искать потенциально слабые места.

Дальше — смотрим паттерны проектирования, рисуем UML диаграммы, проектируем БД (сразу максимально оптимизируем), дальше можно по ней построить диаграмму классов.