Автор оригинала: Long
иметь большой водительский стаж и участвовать в какой-нибудь формуле-3000 два разных случая. вот fixxxer, ты можешь поручится за то, что через n-е время ты не посмотришь на текущую реализацию и не скажешь что она так же плоха как и предыдущие? если текущий работодатель по какой-то причине согласен оплачивать эксперименты - почему бы и нет. а что будет, если реальные нагрузки нагнут железо так, что потребуется не 53 фронта, а 103?
Удивительно будет, если ты, оглянувшись на свой прошлый код будешь кайфовать. Это будет значить, что ты достиг своего лимита. Пока ты не достиг лимита, почти любой код из прошлого будет со временем казаться окаменевшим дерьмом.
----
Навязываться не должно ничто - всё должно приходить естественно. Важны проблемы подачи и маркетинга - но они как-то вяло решаются (поясняю, маркетинг - это о том, что все пытаются поднять бабла на том, что рассказывают вам то, что вы уже знаете). Также есть ещё проблема мозгов, но она настолько общая, что ей здесь не место.
Проблем у ООП-подхода достаточно - как и у процедурного. Но вот однозначно утверждать, что какой-то из них лучше - невозможно. Опять же научить процедурному подходу любого школьника можно, но хорошо ему научить - не всякий сможет. То же самое верно для ООП - ищущий да найдёт адептов обучения детей с помощью Squeak.
Лично мой опыт заключался в том, что после определённого уровня процедурности, когда избавляешься от дублирования и концентрируешь каждую функцию на своей задаче, вдруг возникает острое желание перейти к объектам, как к пакету функций обработки определённых данных. И переходишь. И поначалу всё хорошо. Потом, с добавлением точек гибкости (архитектура, мать её) за счёт полиморфизма и остальной компании, начинаются проблемы. Проблемы возникают из-за того, что объекты суть не только реальные объекты реального мира, но и некоторое количество мета-концепций. Отсюда, зачастую мы и видим говнокод - когда мета-концепция хочет вырваться наружу, но никто её не видит - или не хочет замечать. Потом, энтропия неистребима. Часть проблем решается постоянной поддержкой порядка - для этого уже придумали слово, не буду произносить. Часть проблем - тем, что мы должны бы думать не реализациями, а контрактами. Есть ещё несколько известных вещей, но вот воспринимаются они только со временем - и все, как на зло, непросто.
Про математику я молчу - там всё сложно. Вообще же интересно, как обычно все обтекают мимо существующие функциональные языки. Хотя это уже о другом.
Если уж определять хороший ООП, то есть одна книжка, которую почему-то незаслуженно затмевают в человеческих мозгах GOF и прочие фаулеры. Я о Object-Oriented Software Construction Мейера. Она огромна, но она хорошо проходится по многим вещам.
Про абстрактные типы данных (а они, кажется, связаны с ООП) есть небольшой кусочек из Кея (I was in the Air Force in 1961...) -
http://blog.moryton.net/2007/12/computer-revolution-hasnt-happened-yet.html
Ну и да, Code Complete никто не отменял.
Ну вот. Наверное не совсем по теме, ну да ладно - я гляжу здесь всё равно не вышло того, что планировалось.
ps. Насяльника, работаю я )
)
