Шаблоны, лучшие практики и чистый код - PullRequest
7 голосов
/ 10 октября 2009

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

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

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

Ответы [ 8 ]

16 голосов
/ 10 октября 2009

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

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

Я думаю, что это тоже "сложность". Шаблоны дают вам кадр, с которого нужно начинать, когда вы сталкиваетесь с проблемой. Пример: вы действительно хотите выполнить модульное тестирование своего кода, но просто не можете, потому что это зависит от логики пользовательского интерфейса или слишком сильно связано. Это ваша проблема, поэтому вы можете прийти к решению, зная о шаблоне MVC и концепции внедрения зависимостей и IOC. Они могут дать вам отправную точку, так как, например, MVC объясняет вам концепции высокого уровня: представление Observer, Observable, Controller и т. Д. И ... как они связаны друг с другом. Тогда ваша задача, как хорошего программиста, выбрать правильный подход и в какой степени вы считаете разумным применять этот шаблон. Не просто применяйте это, потому что образец говорит вам. Помните, что это просто рамка, вы можете изменить и адаптировать ее s.t. это подходит для ваших конкретных обстоятельств.

5 голосов
/ 10 октября 2009

Мой совет: сохраняйте свой дизайн простым так долго, как это практически возможно - без ущерба для удобства обслуживания Хороший объектно-ориентированный дизайн на основе шаблонов имеет множество небольших, очень специализированных классов. Самые простые из функциональных возможностей могут коснуться многих классов. Что требует много времени, чтобы изучить / понять дизайн. Преимущество такой «корректности» заключается в том, что код можно обслуживать - небольшое изменение требований обычно требует небольшого изменения локализованного кода.

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

2 голосов
/ 11 октября 2009

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

Когда вы пишете книгу или статью, вам нужно несколько примеров, чтобы представить свою идею. Обычно примеры должны быть простыми. Однако для простого примера «шаблон» может не иметь особого смысла.

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

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

2 голосов
/ 11 октября 2009

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

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

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

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

«Теория хороша. Теория напоминает нам что люди имели дело с этими вопросы раньше. Но разве это закон? Мы обязаны это себе думать и понять для себя. " - Роб Конери

1 голос
/ 11 октября 2009

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

0 голосов
/ 23 июня 2014

Большую часть времени я обнаружил, что код, который работает хорошо, уже следует соответствующим шаблонам. Я видел два паттерна со сложными вещами - синглтон и декоратор. ИМХО Синглтон - это просто более подробная версия класса статических методов. Шаблон Decorator также не очень хорош, поскольку вынуждает каждого декоратора повторно реализовывать нагрузку котельной плиты, нарушающей DRY, а также зная, что украшение нарушает SRP. В целом, шаблоны в основном являются хорошими инструментами, но если у концепции есть название «Шаблон», это еще не значит, что она хороша.

0 голосов
/ 10 октября 2009

на самом деле, совсем недавно у меня был спор в Twitter. Я пригласил некоторых программистов на «Дизайн шаблонов Barcamp». но один парень начал говорить, что в таком баркемпе нет никакого смысла, так как вы знаете шаблоны или нет. это как достижение нирваны, сказал он. но я не согласен мы все инженеры. и изучение того, как писать хорошее программное обеспечение, частично происходит из абстракций. Но опять же, этого недостаточно. изучайте другие языки программирования, парадигмы, расширяйте свои знания об используемом вами инструменте, читайте код программного обеспечения с открытым исходным кодом, написанный на вашем любимом языке, и вы станете лучшим программистом (если вам повезет, да)

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

0 голосов
/ 10 октября 2009

IIABDFI. Если это не сломалось, не исправляйте это.

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...