Разбираем AjaxOOP

[eai]

вот потому так и живем такие что ли?

С привет миру это классический развод.
Помнится был аналогичный пример. Жаба там проигрывала всем, так много надо было писать для простой фразы "Здравствуй мир", зато бейсик был на высоте, одна строка! Но пример не корректен, так как с ростом программы, бейсик растет в объеме кода, куда как больше жабы.

ну что значит должен? Мне интересно, что ты подразумеваешь под архитектурой. И чем она отличается от дизайна

Смотря что понимать от дизайна, можно сказать что это синонимы.
Архитектура приложения это структура взаимосвязей различных его частей. Так нормально, не знаю как еще написать.

mixin(Obj, Observable);

Наследование подталкивает спихивание ОБЩЕГО (общей модели поведения объектов с одним предком) кода в верх по иерархии, что есть хорошо как это повторное использование кода. Более того один и тот же код написан единожды и если необходимо изменить модель поведения, то делается это в одном месте. Если же для какого из наследников модель поведения отличается, то применяется перегрузка метода, остальное же наследуется от родителя. А то что надо смотреть код предка, так это вопрос документации и правильности построения иерархии и не более. Миксы тоже вариант, однако я предпочитаю модель которую описал Страуструп (ох счаз начнется) так как она (на мой взгляд) наибольшей степени отражает физические сущности мира (а не физическое устройство языка). Разработчик не париться что там у объекта и как а просто использует его модель поведения.

пока что сложностей с синтаксисом не видно...

Синтаксис может быть разным. Есть извращения типа Фортран. Ужасная запись однако, но программы можно писать! Отвечу что писал выше, мне модель Страуструпа наиболее интуитивно понятна.

что имеется в виду?
что имеется в виду?

В основном наследование и перегрузка методов.

ну к чему этот довод, наталкивающий на мысли о религиозности собеседника?
Можно еще Александра Степанова вспомнить (разработчик STL если чё)

Спор данный вообще бесполезен ибо мы с тобой представляем представителей 2х различных ветвей развития систем программирования. Не помню где, писал статью на эту тему.
В действительности можно отнести это к вопросам теологии.
Я отстаиваю ООП как систему которая на практике помогла создать большие приложение без потери управляемости кодом. А уж утиная там или гусиная типизация ;-) мне если честно наплевать. Весь вопрос в том что бы система написания кода позволяла делать качественный код без превращения разработки в хаос с ростом объема.
За 15 лет работы я неоднократно убеждался что подход ООП правильный и верный.

[x-yuri]

С привет миру это классический развод.
Помнится был аналогичный пример. Жаба там проигрывала всем, так много надо было писать для простой фразы "Здравствуй мир", зато бейсик был на высоте, одна строка! Но пример не корректен, так как с ростом программы, бейсик растет в объеме кода, куда как больше жабы.

нет, это совсем другое. Я говорю, о чем-то типа Don't Let Architecture Astronauts Scare You (Are the Groove Designers Architecture Astronauts?, Architecture astronauts take over, Architecture Astronauts Are Back), только на другом уровне

Архитектура приложения это структура взаимосвязей различных его частей. Так нормально, не знаю как еще написать.

а дизайн - как эти части реализованы, т.е. ООП к архитектуре не имеет отношения. Хотя это вопрос терминологии

Наследование подталкивает спихивание ОБЩЕГО (общей модели поведения объектов с одним предком) кода в верх по иерархии, что есть хорошо как это повторное использование кода.

однако не является единственным видом повторного использования

Более того один и тот же код написан единожды и если необходимо изменить модель поведения, то делается это в одном месте.

как и при любом другом виде повторного использования кода. Только больше вероятность что-то поломать, так как связь родитель-потомок - более сильная (они больше друг о друге знают)

Если же для какого из наследников модель поведения отличается, то применяется перегрузка метода, остальное же наследуется от родителя.

при этом композиция позволяет более гибко влиять на поведение объекта

однако я предпочитаю модель которую описал Страуструп (ох счаз начнется) так как она (на мой взгляд) наибольшей степени отражает физические сущности мира (а не физическое устройство языка). Разработчик не париться что там у объекта и как а просто использует его модель поведения.

не вижу здесь отражения сущностей физического мира, а вижу лишь один из вариантов повторного использования кода и абстракции. И в чем заключается подход Страуструпа? Prefer Inheritance over Composition? Я ж на самом деле не хочу отменить наследование. Просто люди бывает бросаются в крайности или привыкли делать так как привыкли... или большую часть времени занимались разработкой GUI-интерфейсов Разумнее знать положительные и отрицательные стороны. Например, наследование проще (прямолинейнее), но композиция - гибче и расширяемее. И еще часто иерархии наследования - огромные монолитные штуки с кучей классов типа "чтобы повторно заюзать код", где не понятно, кто за что отвечает

Я отстаиваю ООП...

будешь смеятся, но я тоже

За 15 лет работы

как бы не аргумент

p.s. а вообще это все довольно абстрактно. Можешь привести пример качественных "многослойных городушек"?

p.p.s.

просуммирую:
минус в том, что может не хватить мозгов

Сообщение от iceman

минус в том - что большинство делают в ООП стиле ради ООП

+ много.

Сообщение от fixxxer

просуммирую: минус в том, что может не хватить мозгов

Все, конечно, всегда себя считают самыми умными с большим количеством мозгов, а на остальных смотрят как на говно, но если смотреть на вещи абстрактно вообще со стороны - то указанное тобой - это таки серьезнейший минус.

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

Сообщение от Доктор

но если смотреть на вещи абстрактно вообще со стороны - то указанное тобой - это таки серьезнейший минус

рад, что ты понял вложенный мной смысл.

с одной стороны написать говенный псевдо-ооп код, который создаст кучу проблем с саппортом, намного проще, чем говенный процедурный (просто потому что в сумме говна будет меньше).

с другой стороны правильная объектная архитектура требует достаточного опыта, и тут получается что человеку в этих делах неопытному более чем реализовывать уже спроектированный интерфейс с постоянными код ревью ничего доверить нельзя (хотя может это и не плохо

с третьей стороны ООП код, несмотря на все XP/TDD и прочее, может оказаться в итоге менее гибким, просто потому что постановка задачи вся на хрен поменялась к чертям. всегда требуется баланс между уровнем гибкости и объемом кода (и сроками), и его найти не всегда просто, а абстрагировать все что можно, - ну девелоперам это конечно понравится но заказчик это оплачивать не будет. баланс тут вообще ключевой момент и самый сложный.

но все равно лучше ничего не придумано так что деваться некуда

HraKK
ок, давай тогда начнем с системы координат - по-моему мы в разных. смотри, у тебя ценности такие, похоже - это всё проблемы не ооп, а проблема бестолковых дураков. а когда берём _умных_ людей, _годные_ инструменты и _спокойно_ так и чтобы бизнес-аналитика была толковая - то всё-всё сможем. а мои ценности другие - надо взлететь с той херней, что есть, здесь и сейчас, без шаровых коней. поэтому ты написал "не проблемы ооп" на то, что проблемами как раз является. так что я считаю, что твои ценности ложные. невозможно спорить, находясь в разных системах координат. в моей системе реальную ценность представляет неидеальность людей и инструментов. я кстати сам пишу довольно посредственный объектный (редко- объектно-ориентированный) код, а не процедурный.

HraKK
трололо! сам-то понял, чего написал? хочешь поговорить про проблемы ООП в идеальном мире? ну... тогда надо начать с того, что в идеальном мире ни тебя ни твоего вопроса просто не существует.

ну и вообще тему можно почитать, правда не везде интересно

p.p.p.s.
tenshi, эволюция ЯП