Здравствуйте, LaPerouse, Вы писали:

LP>Можно, но если ты завяжешься на сам объект, а не его интерфейс, у тебя будет гнилой монолитный дизайн, не подлежащий рефакторингу — раз, замене одних модулей другими без правки и пересборки — два.

Что-то ты масло маслянное порешь, извини. Разве публичный АПИ объекта не есть его интерфейс в терминах ООП? Разве у объектов не бывает виртуальных и абстрактных методов? Разве нет технологии множественного наследования и разве нет вырожденного полностью абстрактного объекта, все методы которого совпадают с его интерфейсом, и названным для простоты этим же словом?

LP>Работа с объектами сводится к двум операциям:
LP>1. Создание объекта
LP>2. Работа с ним через его интерфейс

Мы всегда работаем с объектом через его интерфейс, по другому — это хаки и рефлекшн.

LP>Первое — это тонкий момент, если ты создаешь объект явно, ты завязываешься на реализацию. По факту создание объекта нужно перепоручать фабрикам и DI-контейнерам.

Единственная разумная мысль, но к обсуждаемому слабо относится. Да, посредством фабрик улучшается инкапсуляция, уменьшается связанность, но фабрика одинаково хороша как для объектов, так и для твоих "интерфейсов".

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

Опять каша в голове. Объект и так — черный ящик. Ты не можешь точно сказать (кроме случаев, когда сам создал объект), с чем ты работаешь — с самим объектом, или его наследником. И тут пофиг, через твои "интерфейсы" ты с ним работаешь, или через некий публичный АПИ. Разница есть только для сред, типа .Net, где методы "интерфейсов" и объектов по разному компилятся в байт-код, но с т.з. исходника и тем паче программиста — никакой разницы. А в том же С++ так вообще никакой разницы нет м/у интерфейсом и обычным типом, есть просто множественное наследование, т.е. в случае наличия несколько публичных баз, объект располагает их несколькими публичными АПИ. Ну то бишь "интерфейсами" в твоей терминологии. В моей кстати тоже, за что я С++ и люблю, ибо он куда как более правильный ООП, чем все джавы и дотнеты вместе взятые (которые скорее компонентны, ибо нессиметричны в дизайне, относительно баз объекта).

LP>Мы абстрагированы от объекта средой, которая за нас создает и биндит объекты в наш объект (компоненту). Мы лишь описываем декларативно (в xml-файле например), от каких сервисов зависит наш объект. Вся система представляет из себя ориентированный граф, в котором вершинами являются компоненты (модули), исходящие из модуля стрелки определяют сервисы, реализуемые данным модулем, а входящие в модуль стрелки — сервисы, потребляемые данным модулем для реализации своих сервисов.

Хороши были грибы... Только к ООП тут ничего не относится из озвученного. Вернее относится, но лишь к миниатюрному его подмножеству, называемому — компонентное программирование, и то, ты его неплохо грибами приправил. КОП — хорошее такое подмножество для систем верхнего уровня, и большая такая гиря на ногах при реализации прикладной логики. Тот самый "abstraction penalty" бъет по КОП, как ни по чему другому, поэтому надо понимать, где он хорош, а где — лишь дань фанатизму или ангажированности, например ввиду влияния какой-нить наполненной громкими высказываниями книжки на неокрепший мозг.

LP>Смотри например устройство декларативных сервисов OSGi 4.2 (http://www.osgi.org/Release4/Download) или Spring.

А это уже надстройка над языком. Работая вне системы типов языка, мы получаем такую же бодягу, как в случае скриптовых слаботипизированных языков. По сути, эти XML — и есть кривая разновидность скриптинга. Кривая, потому как XML — не самый удобный язык для требуемого декларативного скриптинга, есть куча куда как более удобных. ИМХО, просто на момент разработки Spring еще не было достаточно хорошего скриптинга на платформе Java, взяли что было. Ну или от непонимания происходящего.

Здравствуйте, LaPerouse, Вы писали:

LP>Забудьте про объекты. Это неверное представление об ООП.

Дожили.

Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind.

Это сказал Алан Кей. В определении ООП по Кею пункт "все есть объект" — это первый пункт. Ырлщдщеф.

Здравствуйте, heavyweapondude, Вы писали:

H>Просто ему предложили работу сделать что-то для плюсов. Причем у плюсов даже не было подходящего инстумента для этого в то время...
H>...
Ему, как гуру, предложили сделать качественную либу для нового языка.

H>Перед этим он делал уже большие библиотеки, используя, как он говорит, high order and generic programming, на Scheme и Ada.

Там же в интервью: отказ от ФЯ был осознанным решением (а не просто пришлось)! И там же причины!

Зы: Некоторым местным любителям ФЯ, похоже, еще долго прогрессировать до аналогичных выводов