Как принять решение о создании классов в приложении ..?

Question

У меня здесь есть серьезные проблемы. Когда нам нужен класс?

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

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

Answer 1

В общем правило для определения границ набора данных и функциональных возможностей, которые необходимо переместить в собственный класс, является single responsibility principle.

В Мартин Фаулер отлично refactoring bliki вы найдете множество шаблонов для перемещения обязанностей, данных и функциональных возможностей между классами (очевидное Extract Class, конечно, но с мощной помощью Extract Method и, в вашем случае, Encapsulate Collection, может быть).

TDD - это хороший способ набросать дизайн очень рано. Обычно «легко проверить» приводит к «разъединению» и, следовательно, к разделению проблем.

Использование обоих этих согласований вместе (TDD + Рефакторинг) может помочь вам в переходе от дизайна к другому: все должно идти немного плавно.

И еще один отличный ориентир - DIYDI (сделайте это самостоятельно).

Также: вы собираетесь использовать для генерации кода или анализа времени выполнения?

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

Во втором случае вы можете использовать Aspect Oriented Programming и/или Reflection для проверки классов и выяснения, какие методы у них есть.

Answer 2

Пожалуйста, ознакомьтесь с this text от Grady Booch и др., Чтобы начать работу в Objected Oriented Design.

Answer 3

Если ваше приложение не используется многократно (что подразумевается в «настольном приложении»), вы можете решить проблему детализации ваших объектов.

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

Если вы ищете принципы для OO (объектно-ориентированный дизайн), доступно множество литературы и веб-ссылок.

Answer 4

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

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Надеется, что это помогает

Answer 5

В простом утверждении - Если у вас есть данные о том, какие операции должны выполняться, тогда вам нужен класс. Хорошим примером для этого являются контейнеры данных, такие как linklist, vector, .... Это называется программирование на основе объектов и является первым шагом в разработке классов.

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