Секрет для достижения хорошего дизайна OO

Ответ 1

• (очень) Простой, но не упрощенный дизайн (достаточно простой дизайн, если вы предпочитаете): K.I.S.S.
• Предпочитайте плоские иерархии, избегайте глубоких иерархий.
• Разделение проблем имеет важное значение.
• Рассмотрите другие "парадигмы", чем OO, когда это не кажется простым или достаточно элегантным.
• В более общем плане: DRY и YAGNI поможет вам достичь 1.

Ответ 2

Не секрет. Это пот, а не магия.

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

Первое правило, которое я сформулировал, следующее:

1. Нет абсолютов Выполняется непосредственно из "многих вещей, чтобы сбалансировать". D.R.Y., Y.A.G.N.I. и т.д. Являются руководящими принципами, строго следуя за ними, не может гарантировать хороший дизайн, если за ним следует письмо, которое может привести к отказу вашего проекта.

Пример: D.R.Y. Один из самых основополагающих принципов, однако исследования показывают, что сложность небольших фрагментов кода увеличивается в 3 раза или более, когда они изолируются из-за проверки до/после состояния, обработки ошибок и обобщения на несколько связанных случаев. Таким образом, принцип должен быть ослаблен до "D.R.Y. (по крайней мере, не так много)" - когда и когда это не тяжелая часть.

Второе правило не очень распространенное:

2. Интерфейс должен быть проще реализации

Звучит тривиально, чтобы быть броским. Тем не менее, есть что сказать об этом:

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

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

3-N Здесь, где я помещаю большинство других упоминаний, это было объяснено уже очень хорошо.

Разделение проблем, K.I.S.S, SOLID, D.R.Y., примерно в этом порядке.

Как создать программное обеспечение в соответствии с этими рекомендациями?

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

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

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

Если у вас есть общее представление о всей системе, не стоит начинать с одной из этих частей в качестве семени и превращать их в "ядро". Сверху вниз и снизу вверх не являются антиподами.

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

Постпроектные обзоры - старайтесь привыкнуть к ним даже для ваших личных проектов. После того, как он запечатан, сделайте, оцените, что было хорошо, что было плохо. Считайте, что исходный код был выброшен - т.е. Не видите, что sessison как "что нужно исправлять?"

Conway Law говорит, что "система отражает структуру организатора, которая его построила". Это относится к наиболее сложному программному обеспечению, которое я видел, и официальные исследования, похоже, подтверждают это. Мы можем получить несколько бит информации из этого:

• Если структура важна, то и люди, с которыми вы работаете.
• Или, может быть, структура не так важна. Существует не одна правильная структура (только многие неправильные, которых следует избегать).

Ответ 3

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

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

Там вы столкнетесь с трудностями, вы научитесь их решать, иногда, возможно, с плохим решением: но вы все равно узнаете. И если в любое время что-то вас беспокоит, и вы не можете найти, как его решить, мы будем здесь, чтобы помочь вам!:)

Ответ 4

Я собираюсь процитировать Маркуса Бейкера, говорящего о том, как добиться хорошего дизайна OO на форуме здесь: http://www.sitepoint.com/forums/showpost.php?p=4671598&postcount=24 p >

1) Возьмите один поток в прецеденте.

2) Реализуйте его как можно раньше.

3) Возьмите другой поток.

4) Реализуйте его как можно раньше.

5) Ищите общность.

6) Кодировать код так, чтобы общность собиралась в функции. Цель для ясности кода. Нет глобалов, пропустите все.

7) Любой блок кода, который неясен, также группируется в функцию.

8) Реализуйте другой поток любым старым способом, но используйте свои существующие функции, если они являются мгновенными надписями.

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

10) Внесите еще один поток, когда ваш код будет идеальным.

11) Рефакторинг, чтобы избежать дублирования до скуки.

Теперь бит OO...

12) К настоящему времени должны появиться некоторые кандидаты на более высокие роли. Группируйте эти функции в роли по классам.

13) Рефакторинг снова с целью ясности. Нет класса, большего, чем пара страниц кода, но не более 5 строк. Нет наследования, если вариация - всего несколько строк кода.

С этого момента вы можете немного поиграть...

14) Реализуйте поток используемого прецедента любым старым способом.

15) Рефактор, как указано выше. Рефакторинг включает в себя переименование объектов и классов по мере их значения.

16) Повторяйте до нурения.

Теперь паттерны!

Как только у вас будет несколько десятков классов, и у вас будет много функциональности, вы можете заметить, что некоторые классы имеют очень похожий код, но без очевидного разделения (нет, не используйте наследование). На этом этапе проконсультируйтесь с книгами моделей для опций по удалению дублирования. Подсказка: вы, вероятно, хотите "Стратегия".

Следующие повторы...

17) Реализуйте еще один поток прецедента любым старым способом.

18) Методы рефакторирования до пяти строк или менее, классы до 2 страниц или меньше (желательно намного меньше), ищите шаблоны, чтобы удалить дублирование более высокого уровня, если оно действительно делает код более чистым.

19) Повторяйте до тех пор, пока у конструкторов верхнего уровня не будет много параметров, или вы слишком много используете для создания объектов внутри других объектов (это плохо).

Теперь нам нужно очистить зависимости. Любой класс, который работает, не должен использовать "новое" для создания вещей внутри себя. Передайте эти вспомогательные объекты сбоку. Классам, которые не выполняют механических работ, разрешено использовать "новый" оператор. Они просто собирают вещи - мы будем называть их фабриками. A factory - это сама по себе роль. Класс должен иметь только одну роль, поэтому заводы должны быть отдельными классами.

20) Фактор из заводов.

Теперь мы снова повторяем...

21) Реализуйте другой поток прецедента любым старым способом.

22) Методы рефакторирования до пяти строк или менее, классы до 2 страниц или меньше (желательно намного меньше), ищите шаблоны для удаления дублирования более высокого уровня, если это действительно делает код более чистым, убедитесь, что вы используете отдельные классы для заводов.

23) Повторяйте до тех пор, пока у классов верхнего уровня не будет избыточного количества параметров (например, 8 +).

Вы, наверное, уже закончили. Если нет, найдите шаблон инъекции зависимостей...

24) Создайте (только) классы верхнего уровня с инжектором зависимости.

Затем вы можете повторить еще раз...

25) Реализуйте еще один поток прецедента любым старым способом.

26) Методы рефакторирования до пяти строк или менее, классы до 2 страниц или меньше (желательно намного меньше), ищите шаблоны для удаления дублирования более высокого уровня, если это действительно делает код более чистым, убедитесь, что вы используете отдельные классы для заводов передайте зависимости верхнего уровня (включая фабрики) через DI.

27) Повторите.

На любом этапе этой эвристики вы, вероятно, захотите взглянуть на развитие, основанное на тестах. По крайней мере, он остановит регрессии, пока вы рефакторинг.

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

Ответ 5

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

Ответ 6

Вкратце: Кодируйте, критикуйте, ищите известное решение, реализуйте его и возвращайтесь к первому шагу, пока вы не удовлетворены (более или менее).

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

Я начинаю кодировать что-то, не слишком просто, не слишком сложно. Затем я смотрю на код, и я думаю: хорошо, что не так? Для этого вы можете использовать первые три "СОВЕРШЕННЫХ принципа":

• Единая ответственность (все ваши классы служат уникальной цели?)
• Принцип Open/Close (если вы хотите добавить службу, ваши классы могут быть расширены с наследованием, но нет необходимости изменять основные функции или ваши текущие классы).
• Liskov Substitution (все в порядке, я не могу просто объяснить, и я бы посоветовал прочитать об этом).

Не пытайтесь овладевать ими и понимать все о них. Просто используйте их в качестве рекомендации, чтобы критиковать ваш код. Подумайте главным образом о том, "что, если я хочу сделать это сейчас?". "Что делать, если я работаю для клиента, и он хочет добавить то или это?". Если ваш код отлично адаптируется к любой ситуации (что практически невозможно), возможно, вы достигли очень хорошего дизайна.

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

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

Ответ 7

• Нет соло-работы. Хорошие проекты редко создаются только одним человеком. Поговорите со своими коллегами. Обсудите свой дизайн с другими. И учитесь.
• Не будь слишком умным. Сложная иерархия с 10 уровнями наследования редко является хорошим дизайном. Убедитесь, что вы можете четко объяснить, как работает ваш дизайн. Если вы не можете объяснить основные принципы за 5 минут, ваш дизайн, вероятно, слишком сложный.
• Изучите трюки от мастеров: Александреску, Мейерс, Саттер, GoF.
• Предпочитайте расширяемость над совершенством. Исходный код, написанный сегодня, будет недостаточным через 3 года. Если вы сейчас напишете свой код, чтобы он был совершенным, но он был нерациональным, у вас возникнет проблема позже. Если вы напишете свой код как расширяемый (но не идеальный), вы все равно сможете его адаптировать позже.

Ответ 8

Основные понятия в моем сознании:

• Инкапсуляция. Храните как можно больше объектов, скрытых как от посторонних глаз, так и от липких пальцев внешнего мира.
• Абстракция - скрыть как можно больше внутренних действий, которые вы делаете, от простых умов кода, который должен использовать ваши объекты.

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