TDD: Trauma Driven Design

... Или Tool Driven Design, кому как больше нравится...

Как-то вдруг внезапно осознал, что всё что стоит за концепцией, например, "инкапсуляции" (как это понимается обычно в современном ООП) — всего лишь чья-то боль по поводу невозможности быстро найти и заменить все вхождения паттерна А на паттерн Б.

Ну, то есть, натурально, какой-нибудь восемьдесят восьмой год, сидит бородач в свитере перед монитором и кодовой базой в 100K-200K SLOC и понимает, что вместо "foo->bar = 640" надо бы писать какое-нибудь "updateGeometry(&foo, 640, 480)". И с инструментарием уровня турбо си восемьдесят восьмого года это — ЖОПА. Ну, каждый кто с подобным встречался поймёт. Все мы знаем, что прижилось решение просто запретить программерам писать "foo->bar = 640".

И вот сейчас в исторической перспективе становится понятно, что возникшую проблему можно было решить миллионом разных способов. Во всяком там энтерпрайзе куда более злобные изменения прокатывают под названием "рефакторинга", а возникающая при этом боль сглаживается контролем версий, разными там автотестами, итд итп. Чего в восемьдесят восьмом году просто не было, или было в рудиментарном виде. И если бы что-то из этого успело чуть пораньше, то никакой "парадигмы" ООП могло бы и не быть, а просто была бы рекомендация уровня best practices делать всё на ADT. А если не догадались сразу — ну чтож, бывает, линтер со статическим анализатором в помощь.

Интересно, сколько там, внизу, еще живет поспешных, неуклюжих, ad hoc решений заматеревших со временем в "концепции"?