Как вы проектируете объектно-ориентированные проекты? [закрытый]

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

Я взял курс OOD несколько семестров назад и многому научился у него; например, писать UML и переводить документы требований в объекты и классы. Мы тоже выучили диаграммы последовательности, но почему-то я пропустил лекцию или что-то еще, они не очень придерживались мне.

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

У меня есть копия Стива Макконнелла Код что я постоянно слышу удивительно, здесь и в других местах. Я прочитал главу о дизайне и, кажется, не вышел с информацией, которую я ищу для. Я знаю, он говорит, что это не простой процесс, что он в основном основан на эвристике, но я не могу взять всю его информацию и применить ее к моим проектам.

Так что вы делаете на этапе проектирования высокого уровня (до начала программирования), чтобы определить, какие классы вам нужны (особенно те, которые не основаны на каких-либо "объектах реального мира") и как они будут взаимодействовать друг с другом?

конкретно меня интересует что методы вы используете? Какой процесс вы следуете, что обычно yeilds хороший, чистый дизайн, который будет близко представлять конечный продукт?

23 ответов


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

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

  2. составьте повествование об отдельных случаях использования.

  3. пройдите повествование и выделите существительные (человек, место, вещь), как классы кандидатов и глаголы (действия), как методы / поведения.

  4. отбросить дубликаты существительных и исключить общую функциональность.

  5. создать диаграмму классов. Если вы разработчик Java, NetBeans 6.7 от Sun имеет модуль UML, который позволяет рисовать диаграммы, а также туда и обратно, и это бесплатно. Eclipse (Java IDE с открытым исходным кодом) также имеет структуру моделирования, но у меня нет опыта работы с ней. Вы также можете попробовать ArgoUML, с открытым исходным кодом инструмент.

  6. применить ООД принципов для организации классов (фактор общей функциональности, построение иерархий и т. д.)


У меня еще недостаточно репутации, чтобы делать комментарии (присоединился сегодня), или я бы просто прокомментировал ответ Скотта Дэвиса. И добавил к тому, что должен был сказать:--1-->

  1. убедитесь, что вы знаете, что ваша программа Все о, Прежде чем начать. Что?!--5-- > is ваша программа? Что это будет?--5-->не делать? Какую проблему он пытается решить?

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

  3. Как вы пришли с потенциальными классами, не думайте о них только в терминах того, какое существительное они представляют, но какие обязанности они имеют. Я обнаружил, что это самая большая помощь в выяснении того, как классы связаны друг с другом во время выполнения программы. Легко придумать такие отношения, как" Собака-животное "или" у щенка есть одна мать."Обычно сложнее понять отношения, описывающие взаимодействия во время выполнения между объектами. Ты алгоритмы программы не менее важно, чем ваше объекты, и их намного проще проектировать, если вы указали, в чем состоит работа каждого класса.

  4. Как только у вас будет минимальный набор вариантов использования и объектов, начните кодирование. Получить что-то, что на самом деле работает как можно скорее, даже если это не делает много и, вероятно, выглядит как дерьмо. Это отправная точка и заставит вас ответить на вопросы, которые вы можете замять на бумаге.

  5. теперь вернитесь назад и выберите больше вариантов использования, напишите как они работайте, изменяйте свою модель класса и пишите больше кода. Так же, как ваш первый разрез, возьмите как можно меньше за раз, все еще добавляя что-то значимое. Промыть и повторить.

просто мои два цента. Надеюсь, это полезно.


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

на первой итерации (или запуске) я разрабатываю общий макет приложения в соответствии с объектами модели, алгоритмами и ожидаемым (действительно ожидается, не может быть ожидаемые) будущие направления. Я не пишу проектные документы, но если мне нужно координировать несколько человек, конечно, необходим грубый эскиз процедуры вместе с анализ зависимостей и угадывание необходимого времени. Постарайтесь свести эту фазу к минимуму, если, как и я, вы предпочитаете более гибкий метод. Есть случаи, когда требуется сильная фаза проектирования, в частности, когда все известно и верно о логике вашей программы, и если вы планируете иметь много взаимодействий между функциями в своем коде. В этом случае варианты использования или пользовательские истории-хорошая идея высокого уровня, в частности для приложений GUI. Для приложений командной строки и в конкретные библиотеки, попробуйте написать "программные истории", в которых вы код против библиотеки вы должны разработать и проверить, как это выглядит. Эти программы станут функциональными тестами вашей библиотеки по завершении.

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

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

Это мой общий подход к проектированию программного обеспечения. Он похож на спиральный дизайн, с короткими, трехмесячными итерациями и элементами гибкой разработки, что позволяет изучить проблемы и познакомиться с вашим программным обеспечением и его областью применения. Конечно, это вопрос масштабируемости, поэтому, если приложение настолько большое, чтобы привлечь сотни разработчиков, все немного сложнее, чем это, но в конце концов, я думаю, что идея всегда одна и та же,разделить et impera.

Итак, подводя итоги:

  1. в итерации один, вы получите вкус его, и узнать
  2. во второй итерации вы очищаете свой продукт и готовите его к будущему
  3. на третьей итерации вы добавляете новые функции и учитесь больше
  4. Гото 2

самый интересный источник, который я знаю об этом, - это часть D объектно-ориентированное программное обеспечение, 2-е издание Бертран Мейер.

часть D: объектно-ориентированная методология: применение метода хорошо

19: о методологии, 20: дизайн шаблон: Мульти-Пульти интерактивные системный, 21: пример наследования: "отменить" в интерактивной системе,22: Как найти классы, Двадцать три: Принципы дизайна класса, 24: использование наследование Ну, 25: полезно техника, 26: чувство стиля, 27: Объектно-ориентированный анализ, 28: процесс построения программного обеспечения, 29: Обучение методу

интересно, что глава 22. Как найти классы доступно онлайн.


Это часто повторяется, но совершенно верно - понять ваши данные.

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

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

Это просто расширение: точно знать, что вы пытаетесь сделать.


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

http://behaviour-driven.org/


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

сначала попробуйте думать с более высокого уровня абстракции. Подумайте об основных компонентах и их обязанностях (их интерфейсе с другими компонентами), посмотрите на некоторые архитектурные шаблоны для вдохновения (нет, не шаблоны дизайна, это слишком низкий уровень! MVC и многоуровневые примеры архитектурных шаблонов). Для достаточно крупных проектов такой вид должен иметь около 3-5 компонентов.

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

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

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

очень коротко: Возьмите ОО и принцип сокрытия информации и потяните его на другой уровень!


PS: Сделайте много эскизов во время проектирования, это так же, как настоящая архитектура!

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


Шаблоны Проектирования

Creational Шаблоны Проектирования

Singleton-убедитесь, что создан только один экземпляр класса, и укажите глобальную точку доступа к объекту.

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

Factory Method-определяет интерфейс для создание объектов, но пусть подклассы решают, какой класс создавать и ссылается на вновь созданный объект через общий интерфейс.

Abstract Factory-предлагает интерфейс для создания семейства связанных объектов без явного указания их классов.

Builder-определяет экземпляр для создания объекта, но позволяет подклассам решать, какой класс создавать и позволяет более тонкий контроль над процессом построения.

Prototype-укажите типы объектов для создания с помощью прототипического экземпляра и создайте новые объекты, скопировав этот прототип.

Поведенческие Шаблоны Проектирования

Chain of Responsibiliy-это позволяет избежать присоединения отправителя запроса к его получателю, предоставляя таким образом другим объектам возможность обработки запроса. - Объекты становятся частью цепочки и запрос передается от одного объекта к другому по всей цепочке пока один из объектов не справится с этим.

Command-инкапсулировать запрос в объект, позволяет параметризацию клиентов с различными запросами и позволяет сохранять запросы в очереди.

интерпретатор-учитывая язык, определите представление для его грамматики вместе с интерпретатором, который использует представление для интерпретации предложений на языке / сопоставляет домен с языком, язык с грамматикой и грамматику с иерархическим объектно-ориентированный дизайн

Iterator-предоставляет способ доступа к элементам агрегатного объекта последовательно, не подвергая его базовое представление.

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

Observer-определите зависимость "один ко многим" между объектами, чтобы когда один объект изменяет состояние, все его иждивенцы уведомляются и обновляются автоматически.

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

Template Method-определите скелет алгоритма в операции, отложив некоторые шаги до подклассов / Template Method позволяет подклассам переопределять определенные шаги алгоритма, не позволяя им измените структуру алгоритма.

посетитель-представляет операцию, которая будет выполняться над элементами структуры объекта / посетитель позволяет определить новую операцию без изменения классов элементов, на которых она работает.

Null Object-предоставить объект в качестве суррогата для отсутствия объекта данного типа. / Шаблон нулевого объекта обеспечивает интеллектуальное поведение ничего не делать, скрывая детали от его соучастники.

Структурные Шаблоны Проектирования

адаптер-преобразование интерфейса класса в другой интерфейс, ожидаемый клиентами. / Adapter позволяет классам работать вместе, что не может быть иначе из-за несовместимых интерфейсов.

Bridge-создание объектов в древовидные структуры для представления частично целых иерархий. / Composite позволяет клиентам обрабатывать отдельные объекты и композиции объектов равномерно.

Composite-Compose объекты в древовидные структуры для представления иерархии целое-часть. / Composite позволяет клиентам обрабатывать отдельные объекты и композиции объектов равномерно.

декоратор-динамическое добавление дополнительных обязанностей к объекту.

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

Memento-захват внутреннего состояния объекта без нарушения инкапсуляция и, таким образом, предоставление средства для восстановления объекта в исходное состояние, когда это необходимо.

Proxy-укажите "заполнитель" для объекта для управления ссылками на него.


метод, который я использовал в реальных проектах с разумным успехом, - это дизайн, основанный на ответственности, вдохновленный книгой Wirfs-Brock.

начните с пользовательских историй верхнего уровня и с коллегами, на доске, нарисуйте взаимодействия высокого уровня, которые они подразумевают. Это дает вам первое представление о том, что такое большие модули; и итерация или две высокоуровневой CRC-карты, такие как play, вы должны были стабилизировать список основных компонентов, что они делают и как они взаимодействовать.

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

знать, когда остановиться, - это вопрос суждения (которое приходит только с опытом).


Я бы рекомендовал вам использовать BlueJ а также ActiveWriter, чтобы узнать, а также развить хорошее понимание объектов. Рекомендуемая книга также является хорошим ресурсом.

с Википедия:

alt text

BlueJ является интегрированной разработкой Среда для программирования Java язык, разработанный главным образом для образовательные цели, но и подходит для мелких программного обеспечения развитие.

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

alt текст http://www.ryanknu.com/ryan/bluej.png

ActiveWriter - это инструмент для моделирования сущностей и связей, он также генерирует код и легко вносить изменения. Это сэкономит вам время и для гибкой разработки очень подойдет.

alt-текст http://altinoren.com/activewriter/Images/Introduction_1.png


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

Если у вас есть только один или два года опыта работы, то вы должны идти до того, что это: как вы доходите до того, что вы действительно знаете свои данные и точно понимаете, что вы пытаетесь сделать?

да, если вы работаете в реальном мире 5+ лет, то вы бы выбрать между любой из многих программ разработка моделей или методов процессов.

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

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

вы узнаете много нового о коде. Инструменты есть инструменты, они научат тебя. ничего.


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

Secondly-используйте OOP и классы только там, где существует естественная иерархия объектов. Не "привинчивайте" его к этому искусственно. Если строгой иерархии не существует (как в большинстве бизнесов приложения) - перейти к процедурным / функциональным, или, по крайней мере, использовать объекты только в качестве контейнеров данных с изолированными аксессорами.

и последнее-попробуйте прочитать это:алгоритм творческого мышления


цитата http://www.fysh.org/~katie/computing/methodologies.txt

и в основе РУП небольшая область, где вы должны использовать дизайн ОО таланты.... если у вас их нет, это как иметь методологию для бег 100 м.

"Шаг 1: напишите о беге очень быстро. Шаг 2: идите и нарисуйте план ипподрома. Шаг 3: пойдите и купите действительно узкие шорты из лайкры. Шаг 4: бегите очень, очень, очень быстро. Шаг 5: поперечная линия первый"

Это тот Шаг 4, который является жестким. Но если вы ставите много акцентов на 1,2,3 и 5, возможно, никто не заметит, и тогда вы могли бы вероятно, заработать много денег, продавая методологию, было бы спортсмены, которые думают, что есть какой-то" секрет " в том, чтобы быть бегуном на 100 м


вы задали вопрос, что многие авторы используют для написания книги. Существует множество методологий, и вы должны выбрать ту, которая кажется вам "самой красивой".
Я могу порекомендовать книги "Домен Управляемый Дизайн" Эрик Эванс. Кроме того, проверить сайт dddcommunity.org.


  1. изучение и мастер шаблонов проектирования.
  2. далее, узнать о домене Driven Design
  3. после этого изучите сбор требований

Я прошел курс УД несколько семестров вернулся и многому у него научился; вроде написание UML и перевод требования документы в объекты и занятия. Мы выучили последовательность диаграммы тоже, но почему-то я пропустил лекция или что-то в этом роде. действительно палка с мне.

  1. вы знаете о шаге 3. Тебе нужно овладеть им. Я имею в виду, через много практики, чтобы это стало вашей второй натурой. Это потому, что метод, который вы изучаете, просто противоречит тому, как мы привыкли. Так что тебе нужно по-настоящему овладеть им. В противном случае вы всегда обнаружите, что возвращаетесь к своему первоначальному способу делать что-то. Это как-то похоже на тестовый процесс, где многие разработчики java отказываются от него после нескольких попыток. Если только они не овладеют им полностью., в противном случае это просто обуза для них

  2. пишите варианты использования, особенно для альтернативного курса. Альтернативные курсы занимают более 50% времени разработки. Обычно, когда ваш PM назначает вам задачу, например, создать систему входа в систему, он будет думать, что это прямо вперед, вы можете взять 1 день, чтобы закончить его. Но он никогда не принимает во внимание то, что нужно учитывать, 1. что делать, если пользователь вводит неправильный пароль, 2. что делать, если пользователь вводит неправильный пароль в течение 3 раз, 3. что если пользователь не вводит имя пользователя и т. д. Вам нужно перечислить их и показать своему премьер-министру, попросить его перенести крайний срок.


Я боюсь, что это не ответ люди любят слушать. В любом случае, позвольте мне высказать свое мнение.

ООП следует рассматривать как одну из парадигм, а не как высшую парадигму. ООП хорош для решения определенных проблем, таких как разработка библиотеки GUI. Он также вписывается в стиль разработки программного обеспечения, за которым обычно следуют крупные программные компании-элитная команда дизайнеры или архитекторы кладет вниз дизайн программного обеспечения внутри UML-диаграммы или какой-либо другой подобный носитель и менее просвещенная команда разработчики перевести в исходный код. ООП предлагают небольшую выгоду, если вы работаете в одиночку или с небольшой командой очень талантливых программистов. Тогда лучше использовать язык, который поддерживает несколько парадигм и поможет вам быстро придумать прототип. Python, Ruby, Lisp / Scheme и т. д.-Хороший выбор. Прототип - это ваш дизайн. Тогда вы улучшите это. Используйте парадигму, которая лучше всего чтобы решить проблему. При необходимости оптимизируйте горячие точки с расширениями, написанными на языке C или на каком-либо другом системном языке. Используя один из этих языков, вы также получаете расширения бесплатно, не только на уровне программиста, но и на уровне пользователя. Такие языки, как Lisp, могут динамически генерировать и выполнять код, что означает, что ваши пользователи могут расширить приложение, написав небольшие фрагменты кода на языке, на котором кодируется само программное обеспечение! Или если вы решите написать программа на C или C++, рассмотрим встраивание переводчика на малый язык Луа. Выставить функциональные возможности как Плагины написано на этом языке.

Я думаю, что большую часть времени ООП и УД создают программное обеспечение, которое является жертвой чрезмерного дизайна.

подводя итог, мой предпочтительный способ написания программного обеспечения:

  1. используйте динамический язык.
  2. напишите дизайн (прототип) на этом языке.
  3. при необходимости, оптимизируйте определенные области с помощью C / C++.
  4. обеспечить расширяемость с помощью интерпретатора самого языка реализации.

последняя функция позволяет программному обеспечению легко адаптироваться к конкретному пользователю (включая себя!) требования.


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

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

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


Я использую тестовый дизайн (TDD). Написание теста сначала на самом деле помогает привести вас к дизайну, который является чистым и правильным. См.http://en.wikipedia.org/wiki/Test-driven_development.


изучать шаблоны проектирования. Это была моя личная революция за последние два года в отношении ОП. Возьми книгу. Я бы рекомендовал вам это:

Головы Первый Дизайн Шаблоны

Он находится в Java, но он может быть расширен на любой язык.


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



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

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

сведите вашу проблему с доменом к чему-то понятному вам; к чему вы можете относиться.

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

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


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