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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

То же самое касается "Рефакторинг по шаблонам".

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

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

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

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

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

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

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

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

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

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

Просто мой минус-приманка...

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

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

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

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

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

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