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

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

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

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

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

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

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

Обновлено: перенесите это мышление на уровень «метода» - сделайте свои методы ответственными за одно и только за одно. Помогает очень быстро разбивать большие (> 50 строк) методы на многократно используемые фрагменты кода.

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

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

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

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

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

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

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

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

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

The main class has 1 list of data of different types. I'm doing calculations on the total, but also on the individual types. I've got methods to perform these calculations which are called from events handled in the codebehind. Any ideas where to go from here?

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

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

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

Это просто дополнение к некоторым прекрасным книжным предложениям.

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

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

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

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

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

В дополнение к рекомендации Брайана о Чистый код Роберта Мартина, вы можете прочитать о «Твердые принципы объектно-ориентированного дизайна дяди Боба».

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

Из трех подкастов я предпочел «Гензельминуты».

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

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

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

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

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

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

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

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

Просто моя приманка против ...

Я рекомендую Feather's Эффективная работа с устаревшим кодом, доступный и доступный для поиска на Сафари, а не на Рефакторинг. Он полон полезных и чутких глав, таких как У меня мало времени, и я должен его изменить и Мое приложение не имеет структуры..

Перспективы для рассмотрения:

1. Автоматизация тестирования качества дизайна - ищите инструменты, которые предоставляют показатели качества дизайна в качестве перекрестной проверки ваших проектных решений.
2. Возможность тестирования кода - помогает ли какой-либо из ваших рефакторингов или мешает разработке через тестирование, написанию модульных тестов или написанию функциональных тестов? Насколько сложно будет тестировать большие части архитектуры после интеграции?
3. Обоснование - как вы защищаете эти решения, как от циничного CYA до руководства, так и, что более важно, чтобы ваша команда поверила в редизайн. Можете ли вы легко и последовательно объяснить Зачем, что изменение было внесено, и будет ли это объяснение легко найти через 6 месяцев?

Личные предпочтения в дизайне, особенно рефакторинге:

1. Занятия по концепциям - в случае сомнений, если есть единственная четкая концепция, ее следует заключить в класс, а не подразумевать как поведение в одном из методов.
2. Много общения по мелочам с обязанностями легче думать и проверять. Если вы сомневаетесь в том, как дизайн соотносится с реальным миром, вернитесь к старому подходу Ответственный подход, который записывал обязанности каждого класса. Если вам это сложно, ваши представления о том, что делает каждый класс, могут быть запутанными или они делают слишком много.
3. Не бойтесь больших вещей, если они регулярные. Иногда, например, при большом количестве обработчиков событий в графическом интерфейсе пользователя, у вас законно будут классы с гораздо большим количеством методов или свойств, чем рекомендуют показатели.

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