Шаги, которым нужно следовать при попытке OO разработать формулировку проблемы - PullRequest
1 голос
/ 25 сентября 2010

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

Ответы [ 6 ]

2 голосов
/ 27 сентября 2010

Я бы предложил следующие шаги. 1. Напишите вариант использования. Это поможет вам понять проблему, оно должно содержать основной поток выполнения (правильный путь) и альтернативные пути. 2. Проведите лингвистический анализ и выясните класс и методы. (Это необязательно, если вы знаете какой-либо другой хороший метод, тогда используйте его.) 3. Используйте SOLID принципал для разработки ваших классов. 4. Помните об инкапсуляции, наследовании, полиморфизме. Если вы не можете вспомнить их, напишите это на бумаге или наклейте на стол. 5. Еще одна вещь, которую вы должны иметь в виду: «Что меняется, инкапсулируйте это» 6. Используйте шаблоны проектирования, когда они необходимы. Не применяйте шаблон проектирования в своем коде. Попробуйте сопоставить вашу проблему дизайна с любым шаблоном дизайна.

Я бы также предложил книгу "Head First OOAD". Это очень хорошая книга для склонности OOAD.

1 голос
/ 27 сентября 2010

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

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

не забудьте прочитатьна архитектурные модели тоже.

1 голос
/ 27 сентября 2010

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

Узнайте о вещахкак и принцип единоличной ответственности, но вам также нужно будет почувствовать, что такое «правильный размер», а не чрезмерную разработку чего-либо.Это в конечном итоге будет зависеть от требований.

1 голос
/ 26 сентября 2010

Я рекомендую бесплатную онлайн книгу http://my.safaribooksonline.com/0131489062/ch01.В нем представлены некоторые архитектурные концепции, а также UML.UML - это инструмент диаграмм для составления плана дизайна, который действительно полезен, особенно для планирования больших проектов перед тем, как сесть и кодировать их.

1 голос
/ 25 сентября 2010

Одним из важных шагов при разработке ОО будет «Принцип единой ответственности».Что в значительной степени является основой для хорошего дизайна.Компонент http в вашем дизайне будет выполнять http-связь для получения заданий, но определенно позволит избежать обработки этих заданий.Процессор Jobs должен быть независимым.Оба эти (http и Job Processor) имеют свою единственную ответственность, возложенную на них.Это более общий вид, и внутри ваших компонентов вы создадите дополнительные классы, которые также следуют этому принципу.

0 голосов
/ 27 ноября 2016

Понимание требований в более широкой перспективе очень важно для разработки чего-то, что выживет в течение длительного времени.Понимание предметной области, бизнеса, потребностей пользователей, ожиданий клиентов, выявление неописанных деталей также имеет большое значение при разработке программного обеспечения.Может быть N факторов, которые влияют на дизайн, таких как частота использования, время использования, сложность рабочего процесса, приоритет пользователей, ограничения системы, ресурсы, навыки разработчика, время, бюджет и многое другое.Вы должны быть в состоянии визуализировать более широкую картину проблемы для решения или требования.Этот анализ должен привести к определению того, что является постоянным в системе и что может измениться в будущем. Дизайн должен абстрагировать часть, которая может измениться. Новое требование не должно приводить к изменению дизайна.Разделяй и властвуй - это формулы, упрощающие сложность.Создавайте специальные пакеты или модули.Определите отношения между ними. Определите важные варианты использования и постарайтесь представить, как ваш дизайн будет обрабатывать или удовлетворять варианты использования.Сделайте детальный дизайн с классами, типами, интерфейсами.Следуйте подходящим шаблонам дизайна в соответствии с необходимостью.Не забывайте твердые принципы.Тестируемость, расширяемость, ремонтопригодность, сложность - это вещи, которые необходимо принять во внимание в начале.Вам нужно нечто большее, чем умение.Таким образом, некоторые люди считают это искусством.Ни один дизайн не может быть идеальным.Делайте ошибки, учитесь на них, не повторяйте.Вот как это для меня.Мой ответ может быть не точным для рассматриваемого вопроса, но, надеюсь, будет полезным.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...