Как перейти от плохого к хорошему ООП-дизайну?

Question

Я много читаю о хороших и плохих практиках в дизайне ООП. Приятно знать, что ваш дизайн плохой или хороший. Но как перейти от плохого к хорошему дизайну? Я отделил интерфейс (xaml) и код от основного класса businesslogic. Этот последний класс становится большим. Я пытался разделить его на более мелкие классы, но я застрял сейчас. Любые идеи о том, как разделить большие классы? Основной класс имеет 1 список данных разных типов. Я делаю расчеты по сумме, а также по отдельным типам. У меня есть методы для выполнения этих вычислений, которые вызываются из событий, обработанных в коде. Любые идеи, куда идти отсюда?

Дополнительная информация:

Мы уже около 6 месяцев в этом проекте. Я работал с объектно-ориентированными языками в течение многих лет (сначала c ++, java, а теперь c #), но никогда не работал над таким большим проектом, как этот. Я полагаю, что мы сделали некоторые неправильные повороты в начале, и я думаю, что мы должны исправить это. Я не могу указать какие-либо подробности этого проекта в данный момент. Я собираюсь заказать одну или две книги о дизайне. Если я разделю все классы, как мне их соединить? Может быть, еще лучше перейти к первому выпуску и перестроить части для второго выпуска?

Answer 1

Практикуйтесь и читайте. Повторить :)

Некоторые рекомендуемые книги:

• Чистый код Роберта С. Мартина
• Шаблоны дизайна GoF
• Рефакторинг Мартина Фаулера

Лично мне также понравились шаблоны проектирования Head First, но стиль может быть не для всех. Есть похожая книга под названием C # 3.0 Design Patterns (см. Ora.com). У этого есть много того же самого материала, но в более традиционной манере.

Answer 2

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

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

Редактировать: Возьмите это мышление и до уровня "метода" - сделайте ваши методы ответственными за одно и только одно. Помогает быстро разбить большие (более 50 строк) методы на куски кода многократного использования.

Answer 3

В дополнение к рекомендации Брайана о Чистый код от Роберта С. Мартина , вы можете прочитать о "Дядя Боб" ТВЕРДЫЕ Принципы объектно-ориентированного проектирования .

Вы можете услышать, как он говорит о принципах SOLID на Hanselminutes Podcast 145 и чистом коде на .NET Rocks! Шоу # 388 . С ним также больше на .NET Rocks! Покажите # 410 , но то, о чем он говорит, на самом деле не имеет отношения к вашему вопросу, я просто включил его на тот случай, если вам понравились первые два.

Из трех подкастов я предпочел Hanselminutes.

Answer 4

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

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

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

Каждый раз, когда вы создаете класс, создайте тест для этого класса. Он не только проверяет ваш код, но и заставляет вас использовать свой собственный дизайн. Всегда думайте о своем классе из этого «внешнего вида». Убедитесь, что вы не спрашиваете слишком много о человеке, использующем ваш класс, и все, что вы спрашиваете о нем, должно быть задокументировано в интерфейсе. Часто я просто добавляю быстрый класс в класс, если нет доступной среды тестирования - он помещает пример использования вашего кода прямо в тот же файл.

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

Дизайн первый может быть трудным. Считайте, что кодирование похоже на спортивное умение. Большинство из нас играют на подъездных дорожках, некоторые играют в местных спортивных командах. Сделать хороший предварительный дизайн для сложного проекта - задача игрока национальной лиги, они - один на миллион. Примите это и планируйте изменения - итерации - ваш друг. (Кстати, большинство из нас ДУМАЮ, что мы на государственном уровне легко. Мы не).

Answer 5

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

Отличное место для начала: прочитайте Объектное мышление Дэвида Веста .

Answer 6

Основной класс имеет 1 список данных Различные типы. я делаю расчеты по итогу, но и по отдельные типы. У меня есть методы выполнить эти расчеты, которые вызываются из событий, обработанных в отделенный код. Любые идеи, куда идти здесь

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

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

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

Answer 7

Рефакторинг Мартина Фаулера - отличная книга о том, как изменить дизайн вашего программного обеспечения, не нарушая его.

Шаблоны проектирования работает аналогично алгоритмам, но рассказывает, как комбинировать объекты для выполнения различных полезных задач.

Наконец Мартин Фаулер имеет множество полезных шаблонов проектирования для приложений. Например Пассивный просмотр

Answer 8

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

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

Answer 9

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *} * 1002 ”* прекрасно

То же самое касается " рефакторинга в паттерны. "

Answer 10

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