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

Ответ 1

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

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

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

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

• Отбросьте дублирующиеся существительные и разделите общую функциональность.

• Создайте диаграмму классов. Если вы разработчик Java, NetBeans 6.7 от Sun имеет UML-модуль, который позволяет создавать диаграммы, а также осуществлять обратную связь и БЕСПЛАТНО. Eclipse (с открытым исходным кодом Java IDE) также имеет структуру моделирования, но у меня нет опыта с ней. Вы также можете попробовать ArgoUML, инструмент с открытым исходным кодом.

• Применяйте принципы OOD для организации ваших классов (учитывайте общую функциональность, создавайте иерархии и т.д.).

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

Итак, суммируем:

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

Ответ 4

Самый интересный источник, который я знаю об этом, - это часть D Object Oriented Software Construction, 2nd Edition Бертран Мейер.

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

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

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

Ответ 5

Это повторяется, но полностью верно - понимайте свои данные.

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

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

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

Ответ 6

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

http://behaviour-driven.org/

Ответ 7

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

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

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

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

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

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

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

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

Ответ 8

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

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

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

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

Ответ 9

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

Шаблоны проектирования для разработки

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

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

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

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

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

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

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

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

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

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

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

Посредник. Определите объект, который инкапсулирует взаимодействие объекта. Посредник способствует свободному соединению, не допуская прямого доступа объектов друг к другу, и позволяет вам независимо изменять их взаимодействие.

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

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

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

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

Нулевой объект. Предоставляет объект в качестве суррогата для отсутствия объекта данного типа. /The Null Object Pattern обеспечивает интеллектуальное поведение, не скрывая действий, скрывая детали от своих соавторов.

Структурные шаблоны проектирования

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

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

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

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

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

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

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

Ответ 10

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

Из Википедии:

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

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

альтернативный текст http://www.ryanknu.com/ryan/bluej.png

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

_{(источник: altinoren.com)}

Ответ 11

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

Ответ 12

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

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

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

Ответ 13

Просто укажите http://www.fysh.org/~katie/computing/methodologies.txt

И в основе RUP - небольшая область, где вы должны использовать OO-дизайн таланты.... если у вас их нет, ему нравится иметь методологию для запуск 100 м.

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

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

Ответ 14

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

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

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

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

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

Вы узнаете много о своей кодовой базе. Инструменты - это инструменты, они ничего не научат.

Ответ 15

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

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

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

Ответ 16

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

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

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

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

Ответ 17

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

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

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

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

• Используйте динамический язык.
• Напишите проект (прототип) на этом языке.
• При необходимости оптимизируйте определенные области с помощью C/С++.
• Обеспечить расширяемость с помощью интерпретатора самого языка реализации.

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

Ответ 18

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

Head First Design Patterns

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

Ответ 19

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

Ответ 20

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

Ответ 21

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

Ответ 22

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

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

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

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

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

Ответ 23

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