У меня возникло подозрение, что TDD противоречит использованию паттернов.
TDD гласит что кода должно быть ровно столько, сколько необходимо для выполнения тестов, ни больше ни меньше.
Паттерны применяются для того, чтобы уменьшить трудозатрыты на адаптацию кода к изменившимся требованиям. Поэтому применение паттернов нарушает принцип ни больше, так как кроме кода необходимого и достаточного для выполнения тестов, появляется код, необходимый для адаптации кода к изменившимся требованиям. Естественно протестировать приспособленность кода к изменяющимся требованиям нельзя, поэтому получается, что не весь код, использующий паттерны, покрыт тестами.
Здравствуйте, igor-booch, Вы писали:
IB>У меня возникло подозрение, что TDD противоречит использованию паттернов. IB>TDD гласит что кода должно быть ровно столько, сколько необходимо для выполнения тестов, ни больше ни меньше. IB>Паттерны применяются для того, чтобы уменьшить трудозатрыты на адаптацию кода к изменившимся требованиям. Поэтому применение паттернов нарушает принцип ни больше, так как кроме кода необходимого и достаточного для выполнения тестов, появляется код, необходимый для адаптации кода к изменившимся требованиям. Естественно протестировать приспособленность кода к изменяющимся требованиям нельзя, поэтому получается, что не весь код, использующий паттерны, покрыт тестами.
получается, что YAGNI тоже "противоречит использованию паттернов".
да и DRY тоже — накопипастил, и выполняй тесты.
IB>TDD гласит что кода должно быть ровно столько, сколько необходимо для выполнения тестов, ни больше ни меньше.
Да, но только до того момента (порядка нескольких минут), пока тест красный. Как только он стал зеленым, ты делаешь рефакторинг (в том числе, и даже в первую очередь, — самих тестов). Всегда. Вот тут то и рождается дизайн со всеми его драйами и паттернами. Вот эта часть и есть то самое в TDD, которое driving дизайн. Суть TDD — выделять структуру из той каши, которая возникает после прохождения очередного теста. Постоянно.
Здравствуйте, igor-booch, Вы писали:
IB>У меня возникло подозрение, что TDD противоречит использованию паттернов.
Несколько ошибок в рассуждениях.
IB>TDD гласит что кода должно быть ровно столько, сколько необходимо для выполнения тестов, ни больше ни меньше.
TDD — это не догмат, "гласить" он, конечно, может... Но, по-правде говоря, голосить у его адептов получается гораздо лучше.
IB>Паттерны применяются для того, чтобы уменьшить трудозатрыты на адаптацию кода к изменившимся требованиям.
Паттерны нельзя применять.
Паттерны нельзя применять.
Паттерны нельзя применять.
IB>Поэтому применение паттернов нарушает принцип ни больше, так как кроме кода необходимого и достаточного для выполнения тестов, появляется код, необходимый для адаптации кода к изменившимся требованиям. Естественно протестировать приспособленность кода к изменяющимся требованиям нельзя, поэтому получается, что не весь код, использующий паттерны, покрыт тестами.
TDD — не догма.
Паттерны нельзя применять.
На выходе обе конфликтующие посылки являются чистопородными заблуждениями. И что тебе проку выяснять, почему одно заблуждение конфликтует с другим?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Nuseraro, Вы писали:
N>Здравствуйте, igor-booch, Вы писали:
IB>>Паттерны применяются для того, чтобы уменьшить трудозатрыты на адаптацию кода к изменившимся требованиям.
N>Это что-то новенькое.
Здравствуйте, Alex.a777, Вы писали:
AA>Здравствуйте, Nuseraro, Вы писали:
IB>>>Паттерны применяются для того, чтобы уменьшить трудозатрыты на адаптацию кода к изменившимся требованиям.
AA>Поясните, плз, что нового?
В том, что постулируются такие необычные цели паттернов.
Цели паттернов проектирования — экономия времени на принятие решений в проектировании и передаче информации об этих решениях. Это достигается за счет:
1) использования типовых подходов для выполнения типовых целей
2) единых наименований этим подходам
Связь паттернов с изменяющимися требованиями достаточно косвенная, через сам процесс проектирования, который в свою очередь определяется требованиями и их динамикой.
Итак, использование паттернов в проектировании — это всегда благо, в не зависимости от того, в каких условиях происходит проектирование. Вот использованием я подразумеваю, не "натяжку" имеющейся задачи под паттерны, знакомые принимающему решение, а широкое рассмотрение конкретной ситуации, как общей задачи, решение общей задачи и спецификацию решения общей задачи под конкретную ситуацию. Паттерны — это всего-навсего научный подход к словам "не изобретать велосипед". (А ведь не хотел троллей кормить)
Есть этап "Почистить код" — это значит, убрать дублирование кода, облегчить возможность дальнейших модификаций, оптимизировать производительность. Проблема в том, что между этапами "Написать код" и "Почистить код" нет четкой границы как на схеме и в теории TDD: иногда проще сразу написать чистый код.
Здравствуйте, igor-booch, Вы писали:
N>>Цели паттернов проектирования — экономия времени на принятие решений в проектировании
IB>А у решений этих какие цели?
Создать качественный дизайн, реализация которого приведёт к выполнению заданных целей разработки.
Применение паттернов приводит к увеличению _только декларативной_ части кода, с объявлениями интерфейсов. Что до императивной его части с последовательностями операторов, то и с паттернами соблюдается принцип отсутствия лишнего кода.
Кстати, паттерны дают прекрасную возможность создать места втыкания тест-драйверов и моков.
