Как вы получили хорошие практики для ваших проектов ООП? [закрыто]

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

Например, это сообщение, которое имеет несколько дней: /codereview/8041/how-to-improve-my-factory-design

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

Как ты научился создавать хорошие дизайны? Некоторые книги, которые вы можете мне порекомендовать?

Проектирование систем - это одна из тех вещей, в которой вы можете добиться только большего. Конечно, это немного помогает прочитать о хорошем дизайне - рекомендуемая книга об объектно-ориентированном дизайне - это « Шаблоны проектирования Gang of Four : элементы многоразового объектно-ориентированного программного обеспечения» . Существуют также другие книги по шаблонам и принципам проектирования для различных типов систем и в разных областях.

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

Хотя я обычно нахожу, что лучше сесть с другими людьми лицом к лицу, конкретные вопросы о дизайне могут быть заданы здесь на программистов. Есть также сайты Stack Exchange для обзоров кода и вопросов реализации .

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

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

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

Во-первых, чтение шаблонов проектирования - плохое начало ИМХО. Лучше читать о принципах проектирования ОО, таких как SOLID и GRASP . После ознакомления с ними хорошей идеей будет изучение общих шаблонов проектирования, потому что вы увидите, как эти принципы можно применять для формирования конкретных идиом.

Утверждается, что, когда в использовании языка появляются шаблоны, у языка фактически отсутствует особенность. Хотя это утверждение очень радикально, в нем много правды. Поэтому я бы посоветовал вам взглянуть и поиграть с другими языками, чтобы лучше понять концепции, которые вы хотите использовать, а также узнать о новых концепциях. Шорт-лист будет Squeak, Ruby и Lisp.
Что касается Листа, моя личная рекомендация - « Структура и интерпретация компьютерных программ» , которая многому научила меня в дизайне, показав мне, как легко можно создавать надежные решения сложных проблем, с чуть более чем чистой абстракцией и (де) композицией в нисходящая манера.

Итак, вот что я предлагаю:

1. написать код (и попытаться понять, что делает его плохим)
2. читать код (и пытаться понять, что делает его хорошим)
3. обмениваться знаниями с другими людьми. Проверь свои идеи.

Как уже упоминали другие, вы только поправитесь с практикой и опытом. Там на самом деле не так много ярлык вы можете взять.

Тот факт, что вы оглядываетесь на свои вещи и вам не нравится то, что вы написали, уже ставит вас на шаг впереди, сравнивая многих других людей в нашей профессии. Пока вы пытаетесь улучшить себя, остальные из нас работают с людьми, которые пишут 500-строчную функцию с 20 параметрами, причем все передаются по ссылке, 15 из них - [в / из], и эти люди думают, что они бомба. потому что они получили этот беспорядок на работу.

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

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

Для начала я бы порекомендовал эти книги:

• Agile Принципы, Шаблоны и Практики в C # - я сам на 3/4 этой книги. Один из основных моментов, на которые автор обращает внимание, и я полностью согласен с этим, не следует начинать с решения проблемы с поиска шаблона для применения. Делайте вещи максимально простыми и превращайте код в шаблон, если альтернатива начинает усложняться.
• Образцы дизайна Head First - я не читал эту книгу, и в IMO многие серии Head First предназначены специально для новичков в этой области. Так что они, как правило, на более простой стороне, но я слышал / читал много хороших отзывов от других об этой книге

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