Здравствуйте, Tilir, Вы писали:
T>Представьте, что перед вами стоит задача. Вы сначала попытаетесь воплотить её на самом простом и эффективном из доступных вам средств/языков (грубо говоря: написать на C, хотя и не обязательно, я сейчас не о конкретных языках а о принципе) и только если станет ясно, что запутываетесь и реально нужны более сложные средства (скажем очевидно, что ООП сильно помогло бы или вообще без сборки мусора явно плохо), примените их или наоборот сначала быстро решите её пусть даже с большим оверхедом на самом навороченном из доступных средств? Для чистоты эксперимента предположим что у вас идеальные условия -- время не давит, начальство всем довольно, заказчики с кровавыми топорами к двери кабинета не подкрадываются. Лично я встречал людей, которые эффективно пишут хороший код и по первому и по второму принципам. И я видел откровенно никчёмный код написанный и так и так.
В идеальном случае все равно как писать. Собственно неидеальность мира и приводит к прогрессу, в том числе и в сфере разработки ПО.
В реальном случае все зависит от задачи.
Как-то раз я писал патчер для бинарников на ассемблере вместе с UI. Если требуется работа с БД, то лучше использовать .NET.
Как всегда эффективность решения зависит от сочетания задачи, языка и программиста.
T>Но в защиту первого принципа у меня есть очень как мне кажется веский аргумент и имя ему -- повторное использование. Модуль написанный на чистом C вы сможете использовать на любом проекте. Модуль написанный на C++ с исключениями и STL вы сможете использовать повторно только если у вас на проекте есть STL и разрешены исключения. Модуль, написанный на C++/CLI вы сможете использовать только если в проекте разрешен .Net (хотя бы в виде CLR-хостинга) и т.д. То есть чем более мощные и удобные средства вы использовали при написании кода, тем ниже шансы его повторно использовать.
Но для .NET можно писать на куче языков и выбирать тот, что наиболее подходит.
Немного переформулирую тезис: "написать на .NET языке повторно используемый модуль гораздо легче".
T>Ещё хуже -- *иллюзия* возможности реюза, которую дают классы. Вы наследуетесь от кого-то, первый месяц всё идёт хорошо, а потом вы упираетесь в нечто неожиданное внутри этого класса и приходится писать убогие подставки и костыли. Лично я уже очень давно и основательно боюсь излишнего наследования -- простое использование хорошо написанного чужого класса кажется более безопасным и то только если покрыть юнит-тестами вдоль и поперёк.
Это касается любого чужого кода вообще. И использовать наследование везде — не лучшая практика.
T>Отдельная песня -- повторное использование на бинарном уровне. Unmanaged-DLL в которой наружу выставляются функции C-интерфейса (а лучше если ещё и stdcall) может быть использована в пределах Win32 кем угодно и мне даже из managed-кода не возникало никогда проблем такие задействовать. Сложнее если наружу торчат классы. Ещё сложнее если это внутрипроцессный COM-сервер. Я скромно молчу про Java и .Net в этом отношении -- там наличие чего-то, что вы хотите повтрно использовать написанного на данном фреймворке *и уже собранного* по сути привязывает вас к фреймворку.
У COM повтораная используемость выше. Можно написать COM объект на javascript и использовать его на C. Причем объект будет находиться на другом машине.
Учитывая что на .NET можно писать COM объекты, то возможностей повторно использовать .NET библиотеку горазо больше.
