Я с вами согласен. Еще мне кажется, что то понятие "прототипа", которое часто используется в разработке программ, не совсем удачное. Так как при написании программ, в отличие от проектирования физических объектов, накладные расходы на внесение изменений значительно меньше, и поэтому выделять отдельный этап прототипирования, результат которого будет в дальнейшем выброшен, не всегда имеет смысл. Прототипироваванием можно заниматься по ходу разработки.
Мы говорим о модели физического мира (комнатах и коридорах), а как оно у нас в голове -- это отдельная история.
По моему мнению, ваша проблема с ООП подходом имеет прямое отношение к этому.
Вопрос в том, что в процессе моделирования пошло не так, и почему мы в принципе столкнулись с такой неприятностью.
Имеются комнаты. Комнате соответствуют выходы. Выходы ведут в другие комнаты. Что не так с этим описанием? Почему на естественном языке всё в порядке, а в коде уже нет?
Здесь, я вижу то, что вы пытаетесь моделировать не реальные объекты, а именно ваше представление о реальных объектах.
Например, почему изначально вы решили, что в реальности "выход", это отдельная сущность, которая должна принадлежать комнате? Во первых в реальности "выход/проход" находится между комнатами и соответственно принадлежит им обоим. Но так же можно посмотреть на задачу с другой стороны и во главу поставить не комнаты, а "выходы". Тогда у каждого выхода будут несколько комнат. Какой из этих подходов верен с точки зрения физического мира?
Забавно, что вы думаете, что умеете читать чужие мысли :)
Если серьезно, то Хинтон сам это признавал и я не считаю себя умнее его. Вообще Хинтон, из всех звезд DL, мне нравился больше всех, так как создавал впечатление человека, который действительно хочет разобраться в теме, а не побыстрее хайпануть на новой технологии.
Добавлю несколько мыслей (так как тема мне мне близка):
В данном случае, однако, эксперимент получается довольно чистым, т.к. эти концепции очень хорошо друг на друга ложатся.
Мне кажется, что здесь мы попадаем в некую ловушку, создающую иллюзию понятности. Например я не уверен, что понимаю, как мой мозг строит модель реальности - как мы представляем себе объекты и концепции реального мира, чтобы можно было легко переложить их на программу. То есть, мне кажется, что я понимаю, но это ровно до тех пор, пока я об этом хорошо не задумываюсь.
Приведу аналогию со зрением - мы просто открываем глаза и видим. Это происходит автоматически, не прилагая никаких усилий. Это создает иллюзию понятности данного процесса. Даже сейчас, если спросить неподготовленного программиста "как работает зрение?" или распознавание объектов, то он может придумать разные на первый взгляд правдоподобные модели для этого.
Но люди, которые реально работали над проблемой компьютерного зрения понимают, насколько это нетривиальная задача и насколько мы ее изначально недооценивали.
Так что для меня вопрос представления концепций реального мира в программе остается открытым, ну или как минимум имеющим множество разных решений.
Смущает то, что вот когда задача маленькая, мы можем прикинуть себе хорошую архитектуру (т.к. всё в голове помещается). А вот если в системе много элементов, не исключено, что гипотетическое оптимальное решение уже и не увидеть.
Я не уверен, что на 100% уловил вашу мысль, но мне кажется, что это имеет вполне разумное объяснение, так как мы можем оперировать лишь ограниченным числом элементов, а тем более не можем представить их все в деталях. Из этого следует, что прийти к оптимальному решению очень сложно. Я подозреваю, что в общем случае, это вообще относится к NP-hard или даже более сложному классу задач (да простят меня CS специалисты, если я ошибаюсь).
Было бы интересно услышать мнения большего количества людей.
Здравствуйте, спасибо за статью. Хочу сказать, что я тоже много размышлял над подобной темой на основании разных проектов, над которыми я работал. Вывод, к которому я на данный момент пришел неутешительный, и заключается в том, что в конечном успехе того или иного решения, значительную роль может играть случайность. Это чем-то напоминает мне ошибку выжившего или всякие книги/cтатьи об успешных людях, где приводятся их качества/привычки и выдвигается тезис о том, что только это сделало их богатыми и успешными, а стечение обстоятельст не принимается в расчет. В анализе успешных архитектур и решений, я наблюдал подобные ситуации, когда определенное архитектурное решение было очень удачным, в виду того, что развитие проекта шло именно тем путем, который максимально ему соответсвует. И задним числом рассказывалось о том, как автор все четко продумал.
Но я так же был свидетелем ситуаций, когда требования бизнеса менялись таким образом, что выбранная архитектура наоборот, очень сильно все усложняла, хотя изначально она казалась очень удачной. Это приводит к банальному выводу, что универсальных архитектур нет, а прогнозировать будущее очень трудно. Например, ваше первое решение, где вы используете наиболее простой подход и как выражаетесь пользуетесь случайностью выбранных структур данных, может быть отличным и до определенной степени расширяемым решением, если последующие требования не будут упираться в его естественные ограничения (локальный оптимум). Но кардинальное переписывание может быть неизбежным, в случае сильного отклонения требований от изначальных. Пытаться с самого начала идти вторым путем, мне кажется еще хуже, так как правильное моделирование концепций реального мира с возможностью расширения по разным фронтам, задача намного более сложная и скорее всего получится Франкенштейн. Для себя на данный момент я избрал такой метод:
Сперва написать самую простую реализацию, без попытки моделирования предметной области.
Посмотреть на результат и сделать рефакторинг на основе реализации. То есть конечное выделение структур данных и объектов происходит на основе структуры программы, а не концепций реального мира.
Это конечно же не панацея и есть ситуации, в которых это не лучшее решение, но по моему опыту намного чаще дает лучший результат, чем альтернативный подход.
По поводу вышесказанного и несоответствия заголовка, я в каком-то плане могу с вами согласиться. Но, как я уже указывал не раз в комментариях и обновленнии статьи, моим мотивом было не рассказать о том "как правильно" (я и сам не знаю как привильно), а высказать критику принципа, который постулирует о том, чтовсегда нужно пытаться спроектировать интерфейсы еще до написания реализации. По моему убеждению, необдуманное следования ему, создает гораздо больше проблем, чем пользы.
Я бы еще добавил, что в InnoDB используется отдельный Undo log, так как до коммита транзакции остальные запросы должны видеть старые версии записей для обеспечения MVCC.
Я полагаю, что вы опытный и принципы вам не нужны, так откуда у вас опыт их применения? Часто опытным программистам сложнее адаптироваться к изменениям технологий, концепций, принципов. И на мой взгляд, опытные должны больше тратить усилий что бы принять что-то новое и полезное, так как их опыт им мешает. SOLID – это не новое конечно.
Я пытался следовать SOLID и тп. на протяжении многих лет (о чем сейчас жалею).
Я не хочу никого ни в чем переубеждать. Если вы считаете, что данные принципы помогают вам писать лучший код, то я искренне рад. Моя статья скорее рассчитана на людей, которые заметили, что эти принципы часто не приводят к обещанным результатам, но все вокруг говорят, что такого не бывает и отступать от принципов ни в коем случае нельзя.
В 2017-2018 годах я очень активно увлекался DL, даже делал коммиты в первую версию библиотеки fast.ai, ну а параллельно слушал много интервью и читал статьи Хинтона, Лекуна и прочих. Так вот тогда много обсуждалась тема о том, является ли backprop биологически обоснованным и имеет ли смысл изначально вкладывать в сеть какую-то архитектуру или можно обучить рандомную fully connected сеть имея достаточно данных. Джефри Хинтон пытался отстаивать позицию, что наш мозг тоже использует бэкпроп, но там было слишком много спекуляций. Что самое странное, Ян Лекун, один из создателей сверточных сетей, отстаивал позицию, что архитектура не нужна, а нужно просто больше данных, что противоречит тому, что мы видим в биологии, так как множество организмов изначально рождаются с хорошо сформированной нервной системой (еще до всякого обучения).
Вообщем, как мне кажется, DL и его модели нейронов имеют очень мало общего с биологией и пока мы видим лишь аналогии и спекуляции. И вообще не понятно зачем пытаться эмулировать то, что мы еще не понимаем, так как для эмуляции нужно понимать принцип работы того, что эмулируется.
Но только программирование через интерфейсы обеспечит слабую связанность. И только она позволит писать модульные тесты. И еще много плюшек: простой и надежный код, минимальное количество усилий на поддержку и внесение изменений, параллельная работа множества разработчиков или даже множества команд над одним функционалом.
То, что оно обещает все эти преимущества, это я слышал и читал сотни раз, но на практике получение данных преимуществ я видел очень редко.
Сначала резать все инициативы, а потом кидать джуна на легаси и удивляться, что он уволился? Объясните, зачем джуну сегодня сидеть и ковырять старое говно, которое не котируется на рынке труда?
Когда я в 2013 году "вошел вайти" и устроился на свою первую работу в вебстудию, то меня тоже сразу кинули на один из легаси проектов (рибейт-сервис) на php 4 и mysql. Там были километровые sql запросы с которыми никто не хотел разбираться. Тогда еще как раз был дикий хайп по поводу nosql и все новые проекты у них писались на mongodb. Вообщем мне все сочувствовали, так как в компании ходили разговоры, что mysql может скоро загнется и все перейдет на монго (наивные). Но так как это была моя первая работа программистом, и я был дико рад, что меня вообще туда взяли, то работал по 12-14 часов в день и по выходным. Короче за пол года я очень сильно поднял свой уровень и потом смотрел на новые проекты, как на игрушечные.
Это я к тому, что на легаси проектах можно прокачаться так, как ни на одном новом, потому что после легаси, которое писали разные люди на протяжении многих лет, тебя уже мало чем можно будет удивить.
А по поводу статьи, то нельзя ничего сказать выслушав лишь одну сторону. Возможно этот джун узнает себя и выдаст статью со своим взглядом на ситуацию :)
Вообщем, хотел бы поблагодарить Вас и остальных людей за критические комментарии, так как еще раз размышляя над ними, я более четко прояснил для себя, в чем заключается моя главная неприязнь к различным "принципам программирования", а точнее тому, как они пропагандируются их адептами.
Постараюсь обобщить примером:
От адептов разных методологий, мы слышим советы в стиле "просто используйте принцип Х" и вы получите быстрый, надежный и расширяемый код. Но я по своему опыту знаю, к каким последствиям приводит "просто используйте принцип Х", и эти последствия чаще всего хуже, чем если бы этот принцип вообще не использовался.
Когда я начинаю приводить конкретные примеры таких ситуаций, то в ответ слышу "вы просто неправильно поняли этот принцип", после чего идет ссылка на 100501-ю статью "Что такое X на САМОМ ДЕЛЕ", в которой приводится очередной кастрированный пример, не имеющий ничего общего с реальными ситуациями в проектах.
Или звучит фраза - "Ну естественно он не всегда применим, просто нужно знать, когда его применять".
Стоп, но в вашем принципе нигде не сказано о ситуациях, когда он применим, а когда нет. Я не собирался спорить с тезисом, что применительно к определенным ситуациям, этот принцип помогает. Главная проблема заключается в том, как эти ситуации определить программисту не имеющему достаточного опыта. Вообщем в подобных дискуссиях я видел яркий пример "Истинного шотландца".
То есть полезность принципа никак нельзя опровергнуть, так как любой контрпример парировался подобным образом.
Когда вам дают советы "просто используйте принцип Х", то пытаются продать “серебряную пулю”, но чтобы воспользоваться этой “серебряной пулей”, вам нужно нечто, как минимум равнозначное ей (опыт).
Прочтите лучше "Почему насилия в мире стало меньше" - там автор вместо натягивания одной выдумки на другую хотя бы какую-то статистику приводит.
Эта книга напоминает мне об одном известном афоризме - "Существуют три вида лжи: ложь, наглая ложь и хорошо подобранные цифры и факты, убедительно свидетельствующие в пользу выдвигаемого тезиса" :)
Пожалуйста. Конечно, если нет жестких внешних требований, то все должно подвергаться изменению. В ваших терминах, я бы еще сказал, что чем позже вы начнете выстраивать макроуровень, тем лучше. Так как у вас побудет лучшее понимание задачи и функционирования вашей программы, что даст более подходящую и оптимальную структуру для постоения этого макроуровня.
Нравятся ли мне цели декларируемые данным принципом? (уменьшение связанности и сложности, увеличение надежности и производительности) - Да, конечно.
Стал бы я использовать данный принцип, если бы он приводил к этим целям? Да, конечно.Зачем же мне отказываться от такого замечательного инструмента?
Приводит ли следование данному принципу к обещанным целям? - По моему опыту и наблюдениям, в большинстве случаев нет.
О причинах этого (в моем представлении), я попытался указать в статье и комментариях выше.
Еще, я бы добавил общий пассаж на счет того, что подобные принципы (SOLID в том числе), на практике мало полезны - так как, все согласны, что бездумно применять принципы нельзя, а для того, чтобы знать где их можно и нужно применять, да и вообще границы применения, нужет опыт, но опытным программистам принципы не нужны, так как у них есть опыт, который намного обширнее и полезнее принципов, а у начинающих программистов опыта нет, и они не знают когда можно, а когда нельзя применять принципы, но когда этот опыт появляется, то потребность в принципах уже отпадает :)
На это можно возразить, что следование принципам начинающими программистами всегда дает лучший результат, чем если бы они писали без них. Но это тоже не всегда так. Я встречал примеры решения задач, по которым можно было бы изучать все паттерны проектирования :) И тогда думаеш - лучше бы они их не знали и писали просто.
Ок, остановимся на том, что мотивацией статьи (как я указал в обновлении), было представление альтернативной точки зрения, догматическому принципу "всегда программируйте на уровне интерфейсов", который часто можно услышать от разных "гуру" в мире разработки. Ну и услышать мнение других :)
Спасибо за уточнение.
Да, с такой формулировкой я полностью согласен.
Я с вами согласен. Еще мне кажется, что то понятие "прототипа", которое часто используется в разработке программ, не совсем удачное. Так как при написании программ, в отличие от проектирования физических объектов, накладные расходы на внесение изменений значительно меньше, и поэтому выделять отдельный этап прототипирования, результат которого будет в дальнейшем выброшен, не всегда имеет смысл. Прототипироваванием можно заниматься по ходу разработки.
По моему мнению, ваша проблема с ООП подходом имеет прямое отношение к этому.
Здесь, я вижу то, что вы пытаетесь моделировать не реальные объекты, а именно ваше представление о реальных объектах.
Например, почему изначально вы решили, что в реальности "выход", это отдельная сущность, которая должна принадлежать комнате? Во первых в реальности "выход/проход" находится между комнатами и соответственно принадлежит им обоим. Но так же можно посмотреть на задачу с другой стороны и во главу поставить не комнаты, а "выходы". Тогда у каждого выхода будут несколько комнат. Какой из этих подходов верен с точки зрения физического мира?
Надеюсь, я понятно сформулировал свою мысль.
Забавно, что вы думаете, что умеете читать чужие мысли :)
Если серьезно, то Хинтон сам это признавал и я не считаю себя умнее его. Вообще Хинтон, из всех звезд DL, мне нравился больше всех, так как создавал впечатление человека, который действительно хочет разобраться в теме, а не побыстрее хайпануть на новой технологии.
Добавлю несколько мыслей (так как тема мне мне близка):
Мне кажется, что здесь мы попадаем в некую ловушку, создающую иллюзию понятности. Например я не уверен, что понимаю, как мой мозг строит модель реальности - как мы представляем себе объекты и концепции реального мира, чтобы можно было легко переложить их на программу. То есть, мне кажется, что я понимаю, но это ровно до тех пор, пока я об этом хорошо не задумываюсь.
Приведу аналогию со зрением - мы просто открываем глаза и видим. Это происходит автоматически, не прилагая никаких усилий. Это создает иллюзию понятности данного процесса. Даже сейчас, если спросить неподготовленного программиста "как работает зрение?" или распознавание объектов, то он может придумать разные на первый взгляд правдоподобные модели для этого.
Но люди, которые реально работали над проблемой компьютерного зрения понимают, насколько это нетривиальная задача и насколько мы ее изначально недооценивали.
Так что для меня вопрос представления концепций реального мира в программе остается открытым, ну или как минимум имеющим множество разных решений.
Я не уверен, что на 100% уловил вашу мысль, но мне кажется, что это имеет вполне разумное объяснение, так как мы можем оперировать лишь ограниченным числом элементов, а тем более не можем представить их все в деталях. Из этого следует, что прийти к оптимальному решению очень сложно. Я подозреваю, что в общем случае, это вообще относится к NP-hard или даже более сложному классу задач (да простят меня CS специалисты, если я ошибаюсь).
Было бы интересно услышать мнения большего количества людей.
Совершенно согласен.
Подобное не раз приходилось встречать :)
Здравствуйте, спасибо за статью. Хочу сказать, что я тоже много размышлял над подобной темой на основании разных проектов, над которыми я работал. Вывод, к которому я на данный момент пришел неутешительный, и заключается в том, что в конечном успехе того или иного решения, значительную роль может играть случайность. Это чем-то напоминает мне ошибку выжившего или всякие книги/cтатьи об успешных людях, где приводятся их качества/привычки и выдвигается тезис о том, что только это сделало их богатыми и успешными, а стечение обстоятельст не принимается в расчет. В анализе успешных архитектур и решений, я наблюдал подобные ситуации, когда определенное архитектурное решение было очень удачным, в виду того, что развитие проекта шло именно тем путем, который максимально ему соответсвует. И задним числом рассказывалось о том, как автор все четко продумал.
Но я так же был свидетелем ситуаций, когда требования бизнеса менялись таким образом, что выбранная архитектура наоборот, очень сильно все усложняла, хотя изначально она казалась очень удачной. Это приводит к банальному выводу, что универсальных архитектур нет, а прогнозировать будущее очень трудно. Например, ваше первое решение, где вы используете наиболее простой подход и как выражаетесь пользуетесь случайностью выбранных структур данных, может быть отличным и до определенной степени расширяемым решением, если последующие требования не будут упираться в его естественные ограничения (локальный оптимум). Но кардинальное переписывание может быть неизбежным, в случае сильного отклонения требований от изначальных. Пытаться с самого начала идти вторым путем, мне кажется еще хуже, так как правильное моделирование концепций реального мира с возможностью расширения по разным фронтам, задача намного более сложная и скорее всего получится Франкенштейн. Для себя на данный момент я избрал такой метод:
Сперва написать самую простую реализацию, без попытки моделирования предметной области.
Посмотреть на результат и сделать рефакторинг на основе реализации. То есть конечное выделение структур данных и объектов происходит на основе структуры программы, а не концепций реального мира.
Это конечно же не панацея и есть ситуации, в которых это не лучшее решение, но по моему опыту намного чаще дает лучший результат, чем альтернативный подход.
По поводу вышесказанного и несоответствия заголовка, я в каком-то плане могу с вами согласиться. Но, как я уже указывал не раз в комментариях и обновленнии статьи, моим мотивом было не рассказать о том "как правильно" (я и сам не знаю как привильно), а высказать критику принципа, который постулирует о том, что всегда нужно пытаться спроектировать интерфейсы еще до написания реализации. По моему убеждению, необдуманное следования ему, создает гораздо больше проблем, чем пользы.
Я бы еще добавил, что в InnoDB используется отдельный Undo log, так как до коммита транзакции остальные запросы должны видеть старые версии записей для обеспечения MVCC.
Я пытался следовать SOLID и тп. на протяжении многих лет (о чем сейчас жалею).
Я не хочу никого ни в чем переубеждать. Если вы считаете, что данные принципы помогают вам писать лучший код, то я искренне рад. Моя статья скорее рассчитана на людей, которые заметили, что эти принципы часто не приводят к обещанным результатам, но все вокруг говорят, что такого не бывает и отступать от принципов ни в коем случае нельзя.
Аргументы и выводы статьи могут быть спорными, но с посылом я согласен - нужно быть более честными и перестать мучить сову.
В 2017-2018 годах я очень активно увлекался DL, даже делал коммиты в первую версию библиотеки fast.ai, ну а параллельно слушал много интервью и читал статьи Хинтона, Лекуна и прочих. Так вот тогда много обсуждалась тема о том, является ли backprop биологически обоснованным и имеет ли смысл изначально вкладывать в сеть какую-то архитектуру или можно обучить рандомную fully connected сеть имея достаточно данных. Джефри Хинтон пытался отстаивать позицию, что наш мозг тоже использует бэкпроп, но там было слишком много спекуляций. Что самое странное, Ян Лекун, один из создателей сверточных сетей, отстаивал позицию, что архитектура не нужна, а нужно просто больше данных, что противоречит тому, что мы видим в биологии, так как множество организмов изначально рождаются с хорошо сформированной нервной системой (еще до всякого обучения).
Вообщем, как мне кажется, DL и его модели нейронов имеют очень мало общего с биологией и пока мы видим лишь аналогии и спекуляции. И вообще не понятно зачем пытаться эмулировать то, что мы еще не понимаем, так как для эмуляции нужно понимать принцип работы того, что эмулируется.
Хорошая шутка :)
То, что оно обещает все эти преимущества, это я слышал и читал сотни раз, но на практике получение данных преимуществ я видел очень редко.
Подобная позиция уже обсуждалась в https://habr.com/ru/post/581824/comments/#comment_23567168
Когда я в 2013 году "вошел вайти" и устроился на свою первую работу в вебстудию, то меня тоже сразу кинули на один из легаси проектов (рибейт-сервис) на php 4 и mysql. Там были километровые sql запросы с которыми никто не хотел разбираться. Тогда еще как раз был дикий хайп по поводу nosql и все новые проекты у них писались на mongodb. Вообщем мне все сочувствовали, так как в компании ходили разговоры, что mysql может скоро загнется и все перейдет на монго (наивные). Но так как это была моя первая работа программистом, и я был дико рад, что меня вообще туда взяли, то работал по 12-14 часов в день и по выходным. Короче за пол года я очень сильно поднял свой уровень и потом смотрел на новые проекты, как на игрушечные.
Это я к тому, что на легаси проектах можно прокачаться так, как ни на одном новом, потому что после легаси, которое писали разные люди на протяжении многих лет, тебя уже мало чем можно будет удивить.
А по поводу статьи, то нельзя ничего сказать выслушав лишь одну сторону. Возможно этот джун узнает себя и выдаст статью со своим взглядом на ситуацию :)
Мне больше нечего добавить.
Вообщем, хотел бы поблагодарить Вас и остальных людей за критические комментарии, так как еще раз размышляя над ними, я более четко прояснил для себя, в чем заключается моя главная неприязнь к различным "принципам программирования", а точнее тому, как они пропагандируются их адептами.
Постараюсь обобщить примером:
От адептов разных методологий, мы слышим советы в стиле "просто используйте принцип Х" и вы получите быстрый, надежный и расширяемый код. Но я по своему опыту знаю, к каким последствиям приводит "просто используйте принцип Х", и эти последствия чаще всего хуже, чем если бы этот принцип вообще не использовался.
Когда я начинаю приводить конкретные примеры таких ситуаций, то в ответ слышу "вы просто неправильно поняли этот принцип", после чего идет ссылка на 100501-ю статью "Что такое X на САМОМ ДЕЛЕ", в которой приводится очередной кастрированный пример, не имеющий ничего общего с реальными ситуациями в проектах.
Или звучит фраза - "Ну естественно он не всегда применим, просто нужно знать, когда его применять".
Стоп, но в вашем принципе нигде не сказано о ситуациях, когда он применим, а когда нет. Я не собирался спорить с тезисом, что применительно к определенным ситуациям, этот принцип помогает. Главная проблема заключается в том, как эти ситуации определить программисту не имеющему достаточного опыта. Вообщем в подобных дискуссиях я видел яркий пример "Истинного шотландца".
То есть полезность принципа никак нельзя опровергнуть, так как любой контрпример парировался подобным образом.
Когда вам дают советы "просто используйте принцип Х", то пытаются продать “серебряную пулю”, но чтобы воспользоваться этой “серебряной пулей”, вам нужно нечто, как минимум равнозначное ей (опыт).
Эта книга напоминает мне об одном известном афоризме - "Существуют три вида лжи: ложь, наглая ложь и хорошо подобранные цифры и факты, убедительно свидетельствующие в пользу выдвигаемого тезиса" :)
Пожалуйста. Конечно, если нет жестких внешних требований, то все должно подвергаться изменению. В ваших терминах, я бы еще сказал, что чем позже вы начнете выстраивать макроуровень, тем лучше. Так как у вас побудет лучшее понимание задачи и функционирования вашей программы, что даст более подходящую и оптимальную структуру для постоения этого макроуровня.
С вашей формулировкой тяжело спорить :)
Но я попробую ответить так:
Нравятся ли мне цели декларируемые данным принципом? (уменьшение связанности и сложности, увеличение надежности и производительности) - Да, конечно.
Стал бы я использовать данный принцип, если бы он приводил к этим целям? Да, конечно. Зачем же мне отказываться от такого замечательного инструмента?
Приводит ли следование данному принципу к обещанным целям? - По моему опыту и наблюдениям, в большинстве случаев нет.
О причинах этого (в моем представлении), я попытался указать в статье и комментариях выше.
Еще, я бы добавил общий пассаж на счет того, что подобные принципы (SOLID в том числе), на практике мало полезны - так как, все согласны, что бездумно применять принципы нельзя, а для того, чтобы знать где их можно и нужно применять, да и вообще границы применения, нужет опыт, но опытным программистам принципы не нужны, так как у них есть опыт, который намного обширнее и полезнее принципов, а у начинающих программистов опыта нет, и они не знают когда можно, а когда нельзя применять принципы, но когда этот опыт появляется, то потребность в принципах уже отпадает :)
На это можно возразить, что следование принципам начинающими программистами всегда дает лучший результат, чем если бы они писали без них. Но это тоже не всегда так. Я встречал примеры решения задач, по которым можно было бы изучать все паттерны проектирования :) И тогда думаеш - лучше бы они их не знали и писали просто.
Ок, остановимся на том, что мотивацией статьи (как я указал в обновлении), было представление альтернативной точки зрения, догматическому принципу "всегда программируйте на уровне интерфейсов", который часто можно услышать от разных "гуру" в мире разработки. Ну и услышать мнение других :)