Сообщение от x-yuri
|
вот потому так и живем  такие что ли? 
|
С привет миру это классический развод.
Помнится был аналогичный пример. Жаба там проигрывала всем, так много надо было писать для простой фразы "Здравствуй мир", зато бейсик был на высоте, одна строка! Но пример не корректен, так как с ростом программы, бейсик растет в объеме кода, куда как больше жабы.
|
Сообщение от x-yuri
|
|
ну что значит должен? Мне интересно, что ты подразумеваешь под архитектурой. И чем она отличается от дизайна
|
Смотря что понимать от дизайна, можно сказать что это синонимы.
Архитектура приложения это структура взаимосвязей различных его частей. Так нормально, не знаю как еще написать.
|
Сообщение от x-yuri
|
ну скажем так наследование реализации не очень правильно, но бывает удобно. Но дело не в этом. Если функциональность используется только внутри объектов, есть агрегация. Если нужно предоставить функциональность во внешнюю среду, есть... назовем это миксинами, что-то типа
mixin(Obj, Observable);
а наследование провоцирует спихивание общей функциональности вверх по иерархии, в результате чего, чтобы узнать, что делает метод надо лазить по этой иерархии вверх-вниз и обратно. При агрегации это не так актуально, так как наследование - более тесная связь, т.е. оно увеличивает связанность (coupling), что есть не хорошо, особенно для "больших стационарных приложений"
|
Наследование подталкивает спихивание ОБЩЕГО (общей модели поведения объектов с одним предком) кода в верх по иерархии, что есть хорошо как это повторное использование кода. Более того один и тот же код написан единожды и если необходимо изменить модель поведения, то делается это в одном месте. Если же для какого из наследников модель поведения отличается, то применяется перегрузка метода, остальное же наследуется от родителя. А то что надо смотреть код предка, так это вопрос документации и правильности построения иерархии и не более. Миксы тоже вариант, однако я предпочитаю модель которую описал Страуструп (ох счаз начнется) так как она (на мой взгляд) наибольшей степени отражает физические сущности мира (а не физическое устройство языка). Разработчик не париться что там у объекта и как а просто использует его модель поведения.
|
Сообщение от x-yuri
|
|
пока что сложностей с синтаксисом не видно...
|
Синтаксис может быть разным. Есть извращения типа Фортран. Ужасная запись однако, но программы можно писать! Отвечу что писал выше, мне модель Страуструпа наиболее интуитивно понятна.
|
Сообщение от x-yuri
|
что имеется в виду?
что имеется в виду?
|
В основном наследование и перегрузка методов.
|
Сообщение от x-yuri
|
ну к чему этот довод, наталкивающий на мысли о религиозности собеседника?
Можно еще Александра Степанова вспомнить (разработчик STL если чё)
|
Спор данный вообще бесполезен ибо мы с тобой представляем представителей 2х различных ветвей развития систем программирования. Не помню где, писал статью на эту тему.
В действительности можно отнести это к вопросам теологии.
Я отстаиваю ООП как систему которая на практике помогла создать большие приложение без потери управляемости кодом. А уж утиная там или гусиная типизация ;-) мне если честно наплевать. Весь вопрос в том что бы система написания кода позволяла делать качественный код без превращения разработки в хаос с ростом объема.
За 15 лет работы я неоднократно убеждался что подход ООП правильный и верный.