Подтвердить что ты не робот

ООП: хороший дизайн класса

Мой вопрос связан с этим: Инструмент Python, который строит диаграмму зависимостей для методов класса.

После того, как я не нашел никаких инструментов, я написал быстрый взлом: я использовал модуль компилятора, я проанализировал исходный код в абстрактном исходном дереве, и я прошел его, чтобы собрать зависимости между методами класса. Мой script сгенерировал входной файл для graphviz, который использовался для генерации графика зависимости, который выглядит как this.

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

4b9b3361

Ответ 1

При проектировании классов мы следуем следующим принципам:

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

Ответ 2

Часто бывает невозможно сказать, что "правильно" или "неправильно", когда дело касается дизайна классов. В этой теме есть много рекомендаций, шаблонов, рекомендаций и т.д., Но в конце дня имхо, это много о опыте прошлых проектов. Мой опыт в том, что лучше не беспокоиться об этом и постепенно улучшать свой код/​​структуру небольшими шагами. Поэкспериментируйте и посмотрите, как выглядят/выглядят некоторые идеи/изменения. И это, конечно, всегда хорошая идея учиться у других. прочитайте много кода и проанализируйте его, попробуйте понять:).

Если вы хотите прочитать о теории, я могу порекомендовать Крейг Ларманнс "Применение UML и шаблонов: введение в объектно-ориентированный анализ и дизайн и итерационное развитие" Amazon. Он охватывает несколько частей вашего вопроса, дает некоторые приблизительные ориентиры и показывает их, используя пример приложения. Мне понравилась книга.

Не могли бы вы загрузить приложение? Возможно, на github или так, возможно, вы могли бы попросить конкретные советы.

Ответ 3

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

Рефакторинг - это инструмент, который вы использовали бы для выполнения этих радикальных изменений. Хорошая среда IDE поможет вам реорганизовать.

Ответ 4

Попробуйте сделать каждый метод легко тестируемым. Я считаю, что это всегда приводит мои проекты в сторону большей удобочитаемости/понятности. Существует множество правил OOAD - SRP, DRY и т.д. Старайтесь помнить об этом в рефакторе.

Ответ 5

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