Алгоритм проектирования программы.
 

Недавно возникла интересная мысль. А как продумывают свои будущие проекты опытные девелоперы?
Господа поделитесь пожалуйста опытом.

Как вы продумываете сколько классов будет в программе, сколько методов, как они между собой связаны будут.

Что то мне подсказывает при грамотном подходе время проектирования создания приложения снижается и весьма весомо.
Был бы очень благодарен так же за ссылки или литературу где можно прочитать про подобные подходы и рекомендации. :)

Отлично понимаю что многие вещи приходят только с опытом и временем, но хотелось бы сократить это время и не изобретать велосипед. :)

З.Ы. желательно разговор вести в контексте action script 3.0 (хотя думаю для всех языков весьма похоже)

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

спасибо за советы :)

во вырыл книженцию. Грят классика может кому понравится, ну вобщем мне подход в описании нравится читается просо и в захлеб а главное примеры есть. К сожалению на C++ тем не мение описание подхода очень широкое и затрагивает все языки.

http://www.helloworld.ru/texts/comp/other/oop/index.htm

s8000_1
до вашего совета покуда еще не дорос. :( потому и просил чего посоветовать. но совет запомню.

Ну паттерны потом почитайте и все остальные книжки этих чуваков и друзей этих чуваков...

Быть может, я не столь опытный по годам - но время от времени приходится заниматься написанием обширных программ.

Во-первых: самый ценный (мой) совет - это не спешить бросаться реализовывать первую попавшуюся идею. Последнюю подобную работу я, например, проектировал на листках бумаги 3 дня и программировал + отлаживал ещё 10 дней. То есть проектирование заняло 25% времени.

Как я это делаю:
Сперва я начинаю "набирать материал". То есть начинаю докапываться как можно дальше - какие именно операции и функциональность должна присутствовать в программе. Выписываю их в виде конечных "мнимых" свойств и методов (в программе, скорее всего, будет по другому). Накапливаемый материал объединяю в такие же "мнимые" классы.

После того, как мне кажется, что я уже прошёлся по всем аспектам программы, и по нескольку раз пересмотрел все мнимые классы - я начинаю проектирование готовой структуры классов. Обычно, по уже готовому, это занимает не много времени.

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

Потом я применяю "бритву Оккамы". Каждый следующий потомок должен добавлять самый наивозможный минимум для того, чтобы реализовать свою функциональность - только то, без чего он уже точно не будет работать. Цепочка наследования растягивается, что придаёт большую открытость к незапланированным изменениям. Кроме того я думаю, что куда лучше перенести, чтобы добиться наибольшей "упорядоченности".

Под конец у меня часто бывает перебор с длиной цепочек и подумав хорошенько, я соединяю обратно несколько подклассов в один.

Полученный результат я рассматриваю с позиции "нравится/ненравится". В хорошо спроектированном проекте любая вещь "на своём месте" - сразу понятно и для чего она и как её использовать. Если же начинаешь путаться уже глядя на блок-схему - значит, вполне вероятно - будешь путаться и при реализации.

Конечно, бывает не всё гладко - но как правило, такой подход позволяет очень легко разбить работу на простые логичные этапы и сокращает количество ошибок и переписываний уже готового кода.

Проект, занимающий 2 недели работы одного программиста - необширный ) Тут можно особо не заморачиваться )
2 Stargazer: Ну да наверное как то так все и мыслят + все зависит от проекта сильно.

При реализации проекта первым делом я делаю примерное проектирование — я не стараюсь точно определиться с классами, методами и свойствами, главное выяснить, как должна правильно работать программа, какие функции нужно реализовать раньше, а какие будут зависеть от них и их надо реализовать позже. Дальше идет проектирование классов для основных функций — нет смысла продумывать всю систему на неделю вперед — гадать умеют не все и в итоге получиться все-равно не так, как предполагалось. Следующий этап — реализация основного функционала. Просматриваю систему, ищу слабые места, объединяю общие классы, реализую наследование, где это необходимо. Здесь еще есть два пути — если проект разовый и не требует дальнейшего развития — закрываю глаза на незначительные слабости в проектировании. Если проект планирует развиваться или требуется передача исходников, стараюсь устранить все минусы системы.

Вобщем процесс можно описать так — проектирование на один день -> реализация -> рефакторинг -> следующая итерация.

Рефакторить нужно по мере необходимости, признаки плохого ООП можно найти в сети — основными я считаю это, когда один класс реализует методы другого(утилитные классы не всчет) и "небезопасные" связи между объектами — два класса имеют ссылки друг на друга или доступ к объектам через глобальные статические переменные (синглтон не всчет).

Очень важным я считаю не стараться продумывать все и вся на недели вперед — так будет уходить очень много времени (25 % это слишком) на вещи, которые потом не будут иметь смысла — результат очень сильно разниться с тем, что задумывается заранее.

Это все относится к небольшим проектам (до месяца), с большими я еще дела не имел, но думаю, что там все примерно так же — разница только в том, что конкретизации функциональности отводится больше времени.

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

Эта тема так обширна, что о ней, навервное, каждый может писать бесконечно. Учитесь, проектируйте, работайте над проектами, приближайтесь к совершенству, это же искусство )

А кто где рисует структуру классов? Все на бумажках или в голове?

Поставил MS Visio, а там даже наследования нету. :confused: