Как пойти от плохо до хорошего дизайна ООП?
Как насчет того, чтобы вместо того, чтобы использовать поля (я не уверен, что вы используете поля, но единственное, что я могу сделать без дополнительного кода, это предположить) для хранения компонентов в массивах? Я сделал пример с JLabels, вы можете сделать то же самое с текстовыми полями.
private static int idsCount = 6; //The number of ids. Let's say 6
private JLabel[] labels = new JLabel[8]; // Keep the array as a field. (8 = max capacity)
private void initIDLabels {
for (int i = 0; i < labels.length; i++) {
labels[i] = new JLabel();
// add this font to all labels.
labels[i].setFont(new Font("Tahoma", Font.BOLD, 12));
}
changeLabelsVisibility();
}
private void changeLabelsVisibility() {
// Hide all labels.
for (JLabel label : labels) {
label.setVisible(false);
}
// Show all labels that supposed to be visible
for (int i = 0; i < idsCount; i++) {
labels[i].setVisible(true);
}
}
12 ответов
Основной класс имеет 1 список данных различных типов. Я делаю вычисления на общем количестве, но также и на отдельных типах. У меня есть методы для выполнения этих вычислений, которые называют от событий, обработанных в codebehind. Какие-либо идеи, куда пойти отсюда?
Если существует много вычислений на основе содержания списка, начинают Вас рассмотренный движущимися операциями в специализированный класс списка? То же идет для операций на определенных типах, возможно, они могли жить в типах?
С точки зрения выполнения подобных все же различных операций на различных типах рассматривают использование шаблона состояния (см. это как замену для операторов переключения), который позволяет Вам рассматривать объекты универсальным способом.
Много ООП является о выбрасывании "вершины вниз" / подходом микроуправления и рассмотрением, что "восходящее"/self-sufficient приближается. Стоит помнить, что никакой подход не "корректен" в изоляции. Создание удобного в сопровождении кода о нахождении разумного баланса, который требует длительного размышления и обычно разрабатывает через опыт.
Практика и читала. Повториться :)
Некоторые рекомендуемые книги:
- Чистый код Robert C Martin
- Шаблоны разработки GoF
- Рефакторинг Martin Fowler
Лично мне также понравились Главные Первые Шаблоны разработки, но стиль не может быть для всех. Существует подобная книга под названием шаблоны разработки C# 3.0 (см. ora.com). Это имеет большую часть того же материала, но более традиционным способом.
Я настоятельно рекомендую берущий Завершенный Код. Это - замечательная книга, которая предлагает тонны хорошего совета относительно вопросов как Ваши.
Чтобы дать Вам быстрый ответ на Ваш вопрос о том, как разделить большие классы, вот, хорошее эмпирическое правило: сделайте свой класс ответственным, с одной стороны, и одна вещь только. Когда Вы начинаете думать как этот, быстро можно определить код, который не принадлежит. Если что-то не принадлежит, факторизует его в новый класс и использует его от Вашего исходного класса.
Править: Удалите те взгляды уровню "метода", также - делают Ваши методы ответственными, с одной стороны, и одна вещь только. Помогает повредиться большой (> 50 строк) методы вниз очень быстро в допускающие повторное использование блоки кода.
Измените способ, которым Вы думаете об объектах. Каждый объект должен нести одну очень определенную ответственность. При наличии класса что-то универсальное как "MainBusinessLogic" Вы, вероятно, делаете что-то не так.
Великолепное место для запуска: Объектные Взгляды Read David West.
В дополнение к рекомендации Brian Чистого Кода Robert C Martin, можно хотеть читать на ТВЕРДЫХ Принципах "Дяди Bob" Объектно-ориентированного проектирования.
Можно услышать, что он говорит о ТВЕРДЫХ Принципах на Подкасте Hanselminutes 145, и убрать код Скал.NET! Покажите № 388. Существует также больше с ним на Скалах.NET! Покажите № 410, но о чем он говорит, действительно не связан с Вашим вопросом, я просто включал его в случае, если Вы наслаждались первыми двумя.
Из этих трех подкастов я предпочел Hanselminute.
Это - просто приложение к некоторым прекрасным книжным предложениям здесь.
Чем лучше я достигаю OO, тем больше я, кажется, уменьшаю размер объекта. Это не похоже, я иду для небольшого размера объекта или чего-либо, но это, кажется, происходит.
Хранение их маленькая, единственная ответственность, простая использовать и понять - все очень важные. Каждый объект должен быть максимально близко к пуленепробиваемому, проверить Ваши параметры и никогда не позволять Ваш объект в недопустимое состояние. Определите все допустимые состояния ясно в документации.
Любое время Вы создаете класс, создают тест для того класса. Это не только тестирует Ваш код, но и вынуждает Вас использовать свой собственный дизайн. Всегда думайте о своем классе от тот "Вне представления". Удостоверьтесь, что Вы не спрашиваете слишком много человека, использующего Ваш класс и что-либо, что Вы спрашиваете его, должен быть зарегистрирован в интерфейс. Часто я просто бросаю быстрое основное в класс, если нет никакой доступной среды тестирования - это помещает пример того, как использовать Ваш код тут же в том же файле.
В кодировании почти все мое время проведено, пытаясь выяснить то, что кто-то еще сделал. Если бы я смог просто произвести известное использование кода или хорошо зарегистрировать API, то мое задание было бы тривиально и запланировало бы значительно короче.
Дизайн сначала может быть трудным. Рассмотрите способность к кодированию как подобную спортивной способности. Большинство из нас играет на наших подъездных дорогах, некоторые играют на локальных спортивных командах. Чтобы сделать хороший первичный дизайн на сложном проекте является задачей плеера национальной лиги, они - каждое миллионное. Примите это и запланируйте изменение - повторения являются Вашим другом. (Между прочим, большинство из нас ДУМАЕТ, что мы на государственном уровне легко. Мы не).
Рефакторинг Martin Fowler является превосходной книгой о том, как изменить дизайн Вашего программного обеспечения, не повреждая его.
Шаблоны разработки работают так же к algorithims, но говорят Вам, как объединить объекты выполнить различные полезные задачи.
Наконец у Martin Fowler есть разнообразие полезного шаблона разработки для приложений. Например, Пассивное Представление
Michael Feathers, "Работающий Эффективно с Унаследованным кодом", как предполагается, очень хорош, но я признаюсь, что не считал его сам.
То же переходит для "Рефакторинга к Шаблонам".
Я нашел, что, работая над сложным 'присвоением' без справки и затем видя, как кто-то еще, это был большой полезный опыт для меня.
Одно присвоение в особенности создавало подобную банковскому программу, где мы должны были отследить транзакции и смочь вычислить полученные проценты и подобные вещи. Это действительно была моя первая программа ООП и действительно большая из-за его сложности. Это становится слишком сбивающим с толку (для новичка), чтобы сделать это в линейном стиле, не совершая ошибки.
Попытайтесь писать больше тестируемого кода, это одно вынудило меня исследовать и реализовать улучшенные методы/концепции проекта ООП.
Я могу только сказать, какие работы для меня, и я действительно не нашел никем, кто работает тот же путь, таким образом, я не уверен, поможет ли он Вам очень.
В основном мой подход должен иметь как можно меньше классов, но не меньше.
Во-первых, единственное время, необходимо сохранить информацию, - то, если Вы получаете ее во время A и нуждаетесь в ней в более позднее время B. Если Вы получаете его и работа над ним одновременно, может случиться так, что нет никакой потребности сохранить его.
Во-вторых, что Вы делаете с ним? Если Вы собираетесь быть итерацией через него определенными упрощенными способами, можно думать о нем как о системе команд и программе, которая воздействует на него как интерпретатор системы команд. В этом случае Вы могли бы хотеть на самом деле разработать систему команд байт-кода с интерпретатором, и закодировать Вашу информацию в той системе команд.
В-третьих, как часто информация изменяется? Если часть информации изменяется только очень нечасто, Вы смогли использовать частичную оценку (т.е. генерация кода). Таким образом, Вы берете нечасто изменяющуюся информацию и используете ее для генерации специальной программы, которая делает то, что полная программа сделала бы с той информацией, но намного быстрее. Генератор кода легко записать, потому что он только имеет дело с частью информации о входе, часть, которая медленно изменяется.
Большая часть структуры данных, которую я вижу в эти дни, существует для поддержки UI. Это ясно не содержит объекты, о которых заботится пользователь, и идеально Вам не придется заботиться также. Таким образом, я создал DSL для UIs, который скрывает все это ого-го-haw.
Держитесь подальше от событий и уведомлений, если Вы возможно можете, потому что они происходят в моментах времени и поэтому представляют возрастающие изменения в состоянии. Вы должны будете быть сильно взволнованы по поводу того, что они возможно были отброшенными, дублированные, или misordered. Часто они используются на теории, что простой стиль опроса был бы "менее эффективным", когда на самом деле часто противоположное происходит.
Таким образом, когда я вижу, что люди все обернуты в технологии классов и так далее, это обычно, потому что они заключают слишком большую сделку структуры данных.
Просто моя downvote-приманка...
Я рекомендую Растушевку, Рабочую Эффективно с Унаследованным кодом, доступным и доступным для поиска на Safari, по Рефакторингу. Это полно полезных и чутких глав как, у меня нет Большого количества Времени, и я должен Изменить Его, и Мое Приложение Не Имеет Никакой Структуры.
Перспективы для рассмотрения:
- Автоматизация качественного тестирования дизайна - ищет инструменты, которые обеспечивают метрики на качестве дизайна как двойная проверка к Вашим проектным решениям.
- Тестируемость кода - какой-либо из Ваших рефакторингов помогает или препятствует разработке через тестирование, пишущий модульные тесты или пишущий функциональные испытания? Как трудно это должно будет протестировать большие части архитектуры, однажды интегрированной?
- Выравнивание - как Вы защищаете эти решения, и от циничного CYA до управления и, что еще более важно, таким образом, Ваши команды верят в модернизацию. Можете Вы легко и последовательно объяснять, почему изменение было внесено, и то объяснение будет легко найти через 6 месяцев?
Персональные предпочтения в дизайне, особенно осуществляя рефакторинг:
- Классы для Понятий - когда в сомнении, если существует единственное ясное понятие, это должно переноситься в класс, а не подразумеваться как поведение в одном или методах.
- Большая передача небольших вещей с обязанностями легче думать об и аудит. Когда в сомнении относительно того, как дизайн отображается на реальный мир, вернитесь к старому подходу Responsibility-Driven-Design записи обязанностей каждого класса. Если Вы находите это трудно, Ваше понятие того, что делает каждый класс может быть запутан, или они делают слишком много.
- Не бойтесь вещами, являющимися большим, если они являются регулярными. Иногда, например: много обработчиков событий на графический интерфейсах пользователя, у Вас законно будут классы с намного большим количеством методов или свойств, чем метрики рекомендуют.