Когда звонить в банду из четырех человек? [Когда использовать шаблоны дизайна?]

Я думаю, что когда вы определяете String, вы определяете объект. Поэтому вам нужно использовать .equals(). Когда вы используете примитивные типы данных, вы используете ==, но с String (и любым объектом) вы должны использовать .equals().

13
задан BalusC 2 June 2010 в 20:37
поделиться

7 ответов

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

  • , Когда простой подход достаточен? всегда достаточно использовать самый простой подход, чтобы заставить следующий тест передавать. Но знание, когда/как осуществить рефакторинг, является реальным видом искусства.
  • , Каков минимальный размер части программного обеспечения, которое выравнивает по ширине использование шаблонов GoF? эмпирическое правило А, которое я когда-то считал, - то, что, когда Вы кодируете что-то однажды, прекрасный, когда Вы копируете тот код где-нибудь во второй раз, записать и идут дальше. При нахождении потребности в том же коде третьим разом, когда пора осуществить рефакторинг, чтобы удалить дублирование и упростить, и часто который включает перемещение в шаблон разработки.
  • , Когда осуществить рефакторинг от бесхитростного до GoF? мне нравится, какой сказанный @anopres - время, когда Вы чувствуете боль не имения в распоряжении шаблона разработки. Боль (или код "запах") может проявиться несколькими способами. Дублирование кода является самым очевидным. При рефакторинге книг как Fowler Рефакторинг или Kerievsky Рефакторинг к Шаблонам список много таких болей указывают/кодируют на зловоние.
  • этот [рефакторинг] может быть сделан разумным способом? прием к рефакторингу должен иметь комплект модульных тестов на месте, которые Вы уверены в, и затем осуществлять рефакторинг, не заставляя ни одного из тех тестов перестать работать. Рефакторинг, по определению, не изменяет функциональность Вашего кода. Поэтому, если Ваши тесты продолжают передавать, у Вас может быть довольно хорошее чувство, что Вы ничего не повредили. Хотя это может быть трудно, я на самом деле наслаждаюсь этой частью TDD, это почти похоже на игру для внесения изменений, не повреждая тестов.

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

18
ответ дан Scott Bale 2 June 2010 в 20:37
поделиться
  • 1
    Разъясниться: в Вашем проекте может быть больше чем один Web.config. Добавьте информацию о блоках выше к конфигурации, расположенной на уровне проекта, не том в Вашей папке Views. don' t забывают удалять "/" закрывающий тэг в первом закрывающемся автоматически теге компиляции – JM. 10 December 2012 в 21:18

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

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

10
ответ дан John Nilsson 2 June 2010 в 20:37
поделиться

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

2
ответ дан Bill the Lizard 2 June 2010 в 20:37
поделиться

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

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

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

<час>

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

11
ответ дан Peter Wone 2 June 2010 в 20:37
поделиться

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

Другое хорошее место для запуска с Главными Первыми Шаблонами разработки. Упражнения, которые иллюстрируют использование различных шаблонов разработки, достаточно тщательно продуманы для предложения хорошего полезного опыта. Кроме того, упражнения также основываются в сценариях реального мира, таким образом, это никогда не фрагмент для наблюдения когда подходящее время для применения шаблонов разработки.

0
ответ дан David Robbins 2 June 2010 в 20:37
поделиться

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

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

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

3
ответ дан Jeromy Irvine 2 June 2010 в 20:37
поделиться

Это подобно любому другому проектному решению. В конечном счете это зависит. Необходимо изучить те шаблоны, которые полезны на языке (много шаблонов GoF не необходимы в Lisp, или Smalltalk, например), изучите их преимущества и недостатки, поймите ограничения системы и сделайте выбор что лучшие соответствия потребности.

лучший совет, который я могу дать, состоит в том, чтобы учиться, учиться, учиться.

7
ответ дан Andru Luvisi 2 June 2010 в 20:37
поделиться
Другие вопросы по тегам:

Похожие вопросы: