Помогите мне с моим ООП

[Pigmeich]

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

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

TDD дает уверенность в том что мы делаем то, что отвечает требованиям и в том что мы ничего не сломали. Методики вроде CRC-карточек он не заменяет и заменить не может.

Может мы по разному понимаем что такое дизайн, но вообще TDD заставляет правильно проектировать классы: использовать композицию, подводит к использованию паттернов, и т.п.. ИМХО это достаточно тесно связано с дизайном, нет? Я конечно не спорю, что и с TDD можно такого нагородить, что ахнешь. Но все таки это уже не бездумная писанина - что вижу то и пишу.

Как учат классики - ложность выпячивается на крайних случаях.

Берем набор TDD и пишем ровно под него спагетти-код. Со всеми if(a = 1) a = 2. Где паттерны и крутой стиль?

TDD не может в принципе повлиять на качество кода, посколько является внешним средством и смотрит на код через компилятор. А как сказал один очень изместный Мартин: "написать код который поймет компьютер может любой идиот".

PS. Знакомиться с TDD однозначно нужно каждому уважающему себя разработчику. Преимуществ огромное множество. Все минусы и "страшилки" с лихвой компенсируются результатом.

Да ну? Почему тогда все не перешли на TDD? Почему ребята пишушие в VBA TDD обычно не используют?

Лично я пробовал писать на TDD. Мне очень понравилось. Но не из-за того, что у меня поднялось качество кода. А из-за чувства безопастности за код написанный под TDD. А еще от поисков "кто виноват" удобно тестами отмахиватся.

 

[StUV]

и вообще, мне кто-нить может показать где в аббревиатуре TDD/TFD/etc есть что-то от OOP/OOD ?.. =)

кто такой умный придумал, что тестирование кода появилось после появления oop как парадигмы вообще?

 

[Gas]

Думаю логика ассоциативности tdd <-> oop, где-то такая:

1. Test-Driven Development began to receive publicity in the early twenty-first century as an aspect of Extreme Programming

2. Extreme Programming was created by Kent Beck

3. Beck has pioneered software patterns

 

[StUV]

http://iteso.mx/~pgutierrez/calidad/Estandares/IEEE 1008.pdf

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

зы:
а тдд в том виде, в котором "мы его сейчас знаем" - это да, конечно, кент бек создатель-основатель

ззы:
тесты к процедурному коду писались еще под фортран66

-~{}~ 07.12.07 18:16:

++
по последней ссылке - обрати внимание на статью
Using Pattern Languages for Object-Oriented Programs. With Ward Cunningham. OOPSLA'87.
ключевой момент "Using ... FOR O-O P"
никакие мысли в голову не приходят?

 

[Gas]

ключевое что я имел ввиду "receive publicity".
XP и патерны GoF наделали много шума, укрепив в сознании многих что tdd важная часто именно объектного подхода.
Так-же запрос данных без перезагрузки страницы применяли ещё до ajax'о-мании, но популярность пришла после PR'а.

А то, что тесты писались всегда и Бек не родоначальник unit тестов это естественно.

 

[StUV]

ну я именно это и хотел сказать

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

 

[Pigmeich]

Gas
StUV
+1 обоим )

 

[whirlwind]

Эммм... Не кажется, что вы господа ударились в философию? Тут не оффтопик и я отвечал ващето по теме. Юнит-тесты, лично меня, заставляют проектировать классы таким образом, что бы их было легко тестировать. Уверен, что щас кто то скажет: TDD ради TDD. Может это какая-то параллельная реальность, но нет, не ради TDD. Трудно тестировать -> делаем рефакторинг -> уменьшаем зависимости -> создаем юниты, которые можно использовать повторно все чаще. В итоге получаем узкоспециализированные классы вместо "Big ball of mud", "XXX bloat" и т.д. и т.п.

PS. Казалось бы, при чем в теме об ООП процедурный подход? А не причем, абсолютно. ПП не позволяет заменять реализацию -> тестирование функций, которые вызывают другие функцие превращается в кошмар Test Driven разработки.

 

[Pigmeich]

whirlwind
если тебе чтобы построить хороший интерфейс требуется писать тестовый код, значит тебе надо накачивать опыт и скилл дизайна.

Трудно тестировать -> делаем рефакторинг -> уменьшаем зависимости -> создаем юниты, которые можно использовать повторно все чаще.

Главные теоретики (они же практики) рефакторинга никогда не говорили "трудно тестировать" и даже "трудно использовать" не говорили. Они говорили "код плохо пахнет", "код выглядит некрасиво". Опять таки, если ты не ощущаешь запаха кода визуально - качай опыт.

ПП не позволяет заменять реализацию -> тестирование функций, которые вызывают другие функцие превращается в кошмар Test Driven разработки.

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

 

[Gas]

Эммм... Не кажется, что вы господа ударились в философию?

ага

Pigmeich

Трудно тестировать -> делаем рефакторинг -> уменьшаем зависимости -> создаем юниты, которые можно использовать повторно все чаще.

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

Почему тогда все не перешли на TDD?

почему все не занимаются спортом, ведь это же полезно?

TDD не может в принципе повлиять на качество кода, поскольку является внешним средством

про качество кода спорить не буду, но tdd влияет на дизайн системы и не является внешним средством (но доказывать этого не буду .

 

[whirlwind]

могу сказать абсолютно обратное.

Давайте не будем голословными. Как избавиться от зависимости bar при тестировании foo?

function foo($a){
   return $a + bar();
}

function bar(){
   return 1;
}

Это элементарный пример, а что будет при тестировании процедурного фасада?

и вообще, мне кто-нить может показать где в аббревиатуре TDD/TFD/etc есть что-то от OOP/OOD ?.. =)

Нет, в аббревиатуре ничего нет. Но я знаю только один язык, где можно заменить реализацию функции - это perl (пардон, еще javascript).
Просто в ООП это уже заложено - вы можете делегировать ближайшую зависимость другому коду без изменения существующего кода или реализации тестируемого кода с учетом того что он будет тестироваться. Последнее это как раз случай TDD ради TDD.

если тебе чтобы построить хороший интерфейс требуется писать тестовый код

Опа, у нас на форуме появился гений, который пишет идеальный T?FD. Грац тебя

PS. И это, pigmeich, не надо тут папского тона и выражений "качай скил". Ну ты понял, не первый день в бизнесе и все такое.

 

[phpdev2007]

Pigmeich
Почему люди всегда уверены в том что они правы ?
Упс не увидел что столько написали,
интересно те кто против tdd могут назвать более правильный подход к программированию?

 

[Pigmeich]

whirlwind
ну тогда желаю тебе и дальше экспериментировать с TDD.

 

[boombick]

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

-~{}~ 08.12.07 23:23:

интересно те кто против tdd могут назвать более правильный подход к программированию?

Ну конечно. Открыли редактор и погнали. А потом "Start new topic" -> "Поможите люди добрые, нифига не работает"