Дизайн классов
 

Не могли бы опытные программеры (ака "архитекторы") посоветовать общий подход и программы для создания небольшого проекта? Просьба об'яснять подробно, для не-программиста.
Имеется в виду создание общей архитектуры проекта, связь между классами и их наследниками, описание необходимых параметров классов.
Желательно также прога для визуального представления всех этих странных отношений.

У меня есть подозрение что меня отправят на UML, поэтому заранее предупреждаю - не ругаться непонятными словами.
спасибо заранее

Например так:
Для начала определяется специфика самого проекта, потом проект "разбивается" на составляющие: функционал, GUI. Каджая из частей также разбивается на отдельные, по возможности независимые элементы, с определением способов взимодействия между элементами системы. На основе этого вырабатывется некая модель системы (в простом случае отдельного приложения, в более сложном совокупность приложений). При детальном рассмотрении выявляются элементы, которые могут быть унифицированы и т.п. И на основе всех этих знаний выстаривается примерная иерархия классов проекта.

Простой пример - аудиоплеер:
Функционал: чтение аудио-файлов различных форматов и проигрывание их, ведение плейлистов и т.п..
GUI: Отображение списка проигрываемых файлов, управление процессом проигрывания и т.п.
Примерные классы:
Класс самого приложения;
класс отображения плейлиста;
класс оттображения состояния плеера;
класс движка плеера (то что непосредственно воспроизводит);
набор кодеков для различных форматов - при этом с учетом что фунции работы с разными форматами различаются по реализации, а для движка выглядят одинаково, то кодеки представляют из себя иерархию классов, например с одним базовым и несколькими наследниками, непосредственно отвечающими за реализацию каждого отдельного кодека;
класс управления плейлистами (как сущностями);
класс отдельно взятого плейлиста;
и так далее.

Немного непрофессионально может быть я излагаю, но я просто не хочу вдаваться в технические детали.
А UML - это всего лишь описание и визуализация системы для более наглядного представления как всей системы так и отдельно взятых ее частей. Так что почитать про него советую, как правило где-то рядом встречаются и описания процесса разработки и описания проектов.

"Перескажите мне Библию в двух словах, только чтоб доходчиво"...
Проектирование ПО - институтский курс, причём, как правило, рассчитанный не на один семестр. Коротко и доходчиво объяснить такую обширную дисциплину, ИМХО, невозможно в принципе. Особенно человеку, который не имеет соответствующей базовой подготовки...
Если есть желание заняться изучением - начать рекомендую с _http://rsdn.ru/?summary/3387.xml и приобретения книги _http://rsdn.ru/res/book/prog/oomethods.xml
А ещё - PSyton
Замечательно, но малоинформативно... Как я и сказал выше - дисциплина слишком обширна.

Сорри, я не имел в виду совсе с нуля. Я довольно давно пишу код, и имею неплохую базу, но по формальному образованию - не программер, поэтому когда говорят сокращениями - не понимаю.
Я ищу какой-то инструмент, чтобы облегчить проектирование. То есть я примерно знаю какие у меня класссы, какие в них методы. Но держать в голове отношения 10-20 классов мне тяжело. Я хотел узнать как мне облегчить себе работу (общий подход), и конкретно есть ли проги (желательно фриварные) которые помогут мне нарисовать диаграмму классов, и отношений между ними. Как передаются данные, в какой последовательности . Чтоб и самому понятно было, и другим мог бы об'яснить.

_http://en.wikipedia.org/wiki/List_of_UML_tools
Но UML изучать придётся по-любому...
_http://www.uml.org/

P.S. Вообще говоря, проектирование ПО и его реализация в коде - несколько разные отрасли программирования...

Все же UML -это только средство, меня больше интересует методология. Мне неохота изобретать велосипед (придумывать КАК лучше проектировать)

То есть используя пример PSyton у меня есть "примерный" список классов, но я не до конца представляю как они взаимодействуют.

Уже писал:

Ты один раз определись. :cool:

EvroStandart,
1) как
2) чем

Причем "чем" - явно вторично. Рисовать то я могу и на бумажке. Интересует именно подход к дизайну. Наплодить кучу классов и заставить это как-то работать - это не так уж и сложно.

Подход к дизайну зависит от конкретной задачи. Рассыльщика майлов можно одним большим классом оформить. А чтото очень навороченное можно делать через шаблоны.

шаблоны

Подход не должен зависить от задачи. От задачи зависит выбор решения. Шаблонные методы (design patterns)- лишь набор методов, помогающих с'экономить время.

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

В общем я уже понял в каком направлении копать, Borland - книга действительно отличная (я пока только просмотрел содержание, если у кого завалялась дигитальная копия (можно инглиш) - буду безмерно благодарен)

Чем так сильно отличается подход к дизайну (структура классов) от выбора решения?
Просвяти меня безграмотного. :biggrin:


Сделаю клас на 2000 строк кода и буду легко и успешно оформлять регулярные изменения. Уже делал и оформлял. :p

Подход - это не структура классов. Подход - это как найти наилучшую структуру. Например в каких случаях выбрать Визитера или Стратегию. Почему и когда лучше использовать темплейты. Какой паттерн выбрать и почему.

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

"наилучшей" не существует по определению - ибо нет предела совершенству

по существу - в любом проекте выделяются сущности (ака объекты класса), что эти сущности могут делать (ака методы класса)

затем идем вниз - ищем общие свойства объектов, сносим их на уровень иерархии ниже, оставляя на текущем слое лишь различия

так до тех пор, пока не дойдем до элементарщины

какую "визуальную" среду применять - да любую, в которой удобно работать - от UML до Notepad.

главное, чтоб было понятно и удобно

Позволю себе посоветовать...

Фундаментальный труд - Гради Буч - Объектно-ориентированный анализ и проектирование.

Для меня эта книга открыла глаза полностью... дальнейшее - уже вариации.

кстати, по поводу ругани непонятными словами... Без того, чтобы до упора разбираться в объектно-ориентированном программировании, ты так или иначе не осилишь архитектуру. Причина проста - ты досконально должен понимать всю логику полиморфизма, абстракции, виртуализации и прочих нюансов... Тогда вдруг все отношения между классами, типа "IS A", "CONTAINS", "USES" и прочие просто сами по себе выстраиваются в четкую картину.

УМЛ - на самом-то деле, под собой имеет всего лишь логику определения "актеров" и "действий" в системе, и их влияния на систему/взаимодействия между собой. И тут уже вступает в дело сам анализ.. Тот же аудио плэер - кто является актерами ? Определение актера - это сущность, способная к интеракции с системой, т.е. способная использовать систему каким-либо образом.
Т.е. в нашем случае актером является прежде всего юзер , верно ? Теперь смотрим, чего ж должен уметь этот актер. Прежде всего - составлять списки треков. Классно! Только что ж такое список треков ? Это лист! Лист чего? Лист треков.. Что имеем как сущность листа ? Трек. значит вот у нас уже связь образовалась: Юзер может составить список треков, т.е. использовать объект управления листами треков, который работает с объектом списка треков, который в свою очередь состоит из набора объектов треков. Мы определили взаимодействие как минимум 3-х классов в системе. И так делается полный анализ требований к системе, и их "перевод" в отношения между различными объектами в системе.

Да, кстати .. первая и самая банальная ошибка начинающих - совсем необязательно, чтобы абсолютно все классы в системе были связаны. Это скорее исключение, чем правило.. В реальном мире таких связей фактически нет. Ну, представим, например, объект автомашины, сидящий в иерархии "средство передвижения"->"моторное средство передвижения"->"Автомашина", и объект "голубь", находящийся в иерархии "животные"->"птицы"->"голубь". В нормальной ситуации эти две сущности никакого отношения не имеют. Однако если этот голубь решит обделать эту автомашину, отношение возникает, и оно не тривиально - т.е. не является подвидом "IS A" или "CONSISTS OF". Тогда появляется надобность уже в некоей сущности, управляющей этим отношением. Из примера ясно, что если требования взаимодействия двух сущностей в системе нет, то и связи, само собой, между ними не будет.

Вот это, как говорится, на пальцах - самое начало объектно-ориентированного анализа... Из этого уже строится архитектура. И, как я и сказал, прежде всего - матчасть. Без крепкой теоретической базы ООД (объектно-ориентированный дизайн) не осилить. Это мое мнение.

З.Ы. Гради Буч в дигитальном варианте у меня есть. Скину без проблем, если кому надо.

Гради Буч в оригинале есть на АваксХоум . Не реклама ;).

очень часто (а по опыту - всегда) когда общаются представители одной профессии, они очень быстро переходят на профессиональный сленг. Который для окружающих просто сотрясение воздуха. А когда просишь "сформулируй для идиота", люди начинают яснее выражать свои мысли, ведь вместо устоявшихся выражений необходимо об'яснять каждое понятие по отдельности.