Как начать с дизайна класса для корпоративного приложения?

Question

Как я могу начать с дизайна класса до начала разработки большого приложения (как WinForm, так и WebApp). Какие начальные «осторожные» вещи я должен проверить перед проектированием структур классов?

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

Answer 1

Для полного ответа на этот вопрос потребуется книга, а не сообщение StackOverflow!На самом деле, об этом уже есть немало книг, таких как Шаблоны корпоративной прикладной архитектуры Мартина Фаулера .Вот несколько общих указателей:

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

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

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

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

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

• Будьте осторожны, когда кто-то говорит вам, что это «корпоративное приложение».Это загруженный термин со слишком большим количеством коннотаций для слишком большого количества разных людей.Не забудьте про сквозные вопросы, такие как безопасность, авторизация, аутентификация, гарантии обслуживания и т. Д.

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

• Наконец, всеумеренно.Принятие любого из вышеперечисленного (или вообще ничего, на самом деле) до крайности - плохая идея.Единственное, что вы действительно должны делать в экстремальных условиях, это сама умеренность!:)

Answer 2

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

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

Answer 3

Я вижу два основных вида дизайнерской деятельности.

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

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

Следующее упражнение в части бизнес-логики. Интерфейсы, абстрактные классы и т. Д. Являются методами структурирования реализации сложности. Разделяйте свой код, чтобы детали были скрыты, а гибкость включена. Я рассматриваю это как упражнение по разработке ОО, есть много книг по этому поводу, например, head first .