ООП гораздо полезнее в теории, чем на самом деле

>Я наблюдал множество студней, кто изучал программирование с Джавы и выпускался быдлокодером, не понимавшим половины того, что сам написал.

Какое мнение об этом http://deitel.com/Books/Java/JavaHowtoProgram7e/tabid/1191/Default.aspx курсе ?

>А также мог сравнить их с людьми, чье образование начиналось с чистого С и Лиспа или Хаскелла. Поверьте, дистанция огромного размера...

Ну и не надо тут нам передергивать, не надо. Дистанция в стоимости подготовки между этими людьми тоже как между космонавтом и соседом-таджиком-таксистом. Не каждый, кому можно объяснить как в спринге надо разделять зоны ответственности объектов, сможет осилить типизации в Хаскеле. Да и нужно ли это каждому?

>Второй - ООП в популярных 'ООП' языках(С++, Java, C#) - говно, а не ООП.

Специалист, епт.

>А если Вы, батенько, не понимаете, что в Вашей программе к чему, то польза от Вашей программы отрицательная... :)

Батенько - вы когда-нибуть участвовали в проекте, где код пишет хотя бы 5 человек ?

> Батенько - вы когда-нибуть участвовали в проекте, где код пишет хотя бы 5 человек ?

В таком, где бы ни один из них не понимал, для чего этот код нужен, -- к счастью, ни разу. :)

Че-то я все прощаюсь, а никак уйти не могу... Хм. :)

Хук. Я все сказал.

Ушел.

>В таком, где бы ни один из них не понимал, для чего этот код нужен, -- к счастью, ни разу. :)

Для чего он нужен даже уборщица знает, а вот вникать в чужой код - это нафик не надо никому.

тогда можно и на APL пописать.. а чо, нормальный WRITE ONLY код :)

ООП, само по себе - одна из методологий организации программы. Далеко не универсальная, конечно же. Но, как говорят про грибы, "условно съедобная".

С++ - это способ сделать ООП методолгию вредной. Видимо, в Java - тоже, хотя на Java я практически не работал и утверждать не стану.

ООП в мозгах тех, кто ему поклоняется - опасная для жизни предприятия религия. Даже здесь можно видеть, что апологеты ООП как религии приводят бредовые аргументы, типичные для религий. Например, аргумент про наличие библиотек классов. Типичное для догматических религий повреждение сознания - ложная убеждённость в превосходстве своей веры над всеми остальными, которая легко опровергается на самых простых фактах типа 2*2=4.

Всё это было бы смешно, но на самом деле, почему-то люди в целом неглупые не могут осознать наличие у себя этого повреждения. Что приводит к управленческим решениям... И к финансовым результам...

Ужос сплошной! ) Школьнеги, разве уже не первое сентября? Брысь отседова, я сказал! :()

> А четырехлетняя начинается с Сей или Лиспа и втыкает студня в теорию программирования, деревья всякие, парсеры и прочие вкусности. А на закусь идет Джаба. По крайней мере, в приличных местах так.

Это всё выглядит даже лучше чем ООП, но только в теории. В реале в университете эту программу обучения превращают в такой Пиздец (да простят меня модераторы), что ИМХО лучше бы ООП вообще не преподавали.

>Ужос сплошной! ) Школьнеги, разве уже не первое сентября? Брысь отседова, я сказал! :()

не грози лору, сидя в кресле и смотря в зеркало

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

Вот и выходит, что программисты не нужны, а нужны физики, биологи, статистики, бухгалтеры со знанием языков программирования. А также те, кто эти языки для них пишет.

И зачем же тогда учить студентов на CS?

> Вот и выходит, что программисты не нужны, а нужны физики, биологи, статистики, бухгалтеры со знанием языков программирования. А также те, кто эти языки для них пишет.

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

Проще биолога научить программировать, чем такому вот оналитеку объяснить генно-структурный анализ.

>Второй - ООП в популярных 'ООП' языках(С++, Java, C#) - говно, а не ООП.

Именно! Из-за этих языков у большинства программистов выработалась острая, доходящая до презрения и тошноты неприязнь к ООП в целом. Добавьте сюда еще толпу быдлокодоров, которые набирают спагетти-код на Яве, и картина восприятия ООП становится полной.

> Даже здесь можно видеть, что апологеты ООП как религии приводят бредовые аргументы, типичные для религий. Например, аргумент про наличие библиотек классов. Типичное для догматических религий повреждение сознания - ложная убеждённость в превосходстве своей веры над всеми остальными, которая легко опровергается на самых простых фактах типа 2*2=4

Браво! Уже неплохо, а если теперь вы попытаетесь обобщить сказанное, то можно получить что-то типа: "Даже здесь можно видеть, что апологеты ООП как нормальные люди приводят бредовые аргументы, типичные для нормальных людей"

И конечно же:

> Всё это было бы смешно, но на самом деле, почему-то люди в целом неглупые не могут осознать наличие у себя этого повреждения. Что приводит к управленческим решениям... И к финансовым результам...

И финансовые результаты - далеко не самая веселая сторона данного безобразия.

Расскажу про себя. Поскольку мне еще не посчастливилось работать в большой команде, то я использую ООП в очень и очень малых дозах, и исключительно там, где это необходимо, поскольку иначе просто не вижу смысла его использовать. Фактически, я понимаю его ограниченность, поэтому не хочу заковывать себя в эти кандалы.

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

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

Чтобы понять, зачем нужен ООП и как его использовать, нужно самому его изобрести. Единственное, что требуется в данном случае от учителя - ускорить данный процесс.

> Браво! Уже неплохо, а если теперь вы попытаетесь обобщить сказанное, то можно получить что-то типа: "Даже здесь можно видеть, что апологеты ООП как нормальные люди приводят бредовые аргументы, типичные для нормальных людей"

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

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

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

просто интересно услышать, как можно " работать в большой команде"
(под большой командой я понимаю коллектив > 2человек) без ООП?
и так, чтобы твой код/либу (не программу) пользовали хотя бы 2-3 юзера.

Все остальное, как в той цитате и оригинала
Certainly for the great majority of programmers—amateurs working alone to create programs such as ...

> Переведите мне, пожалуйста, в термины ООП парадигмы процесс испития кофе из данной кружки.

Вообще-то, это классический пример неправильного подхода :-)

Кофейник.Подготовить;
Кружка.Подготовить;
Кофейник.Перелить(Кружка,Количество);
Конечности.Рука.Взять(Кружка);
Конечности.Рука.Перместить(Местоположения.Ближе_Ко_рту);
Конечности.Рука.Наклонить(УголНаклона.СколькоНужно);

То есть пьешь ты из кружки, вот только действуешь ты рукой а не кружкой :-)

> Вон, сокеты в операционных системах - казалось бы, объектная модель, а написаны на си, без всяких кривых классов, но и работают нормально, и пользоваться ими удобно.

Посмотри реализацию сокетов (придется заодно углубиться в VFS). Когда поймешь что там написано, попробуй найти отличия (кроме синтаксических) в следующем примере:

socket s = socket(...);
sendto(s,buffer,bufferlen,addr);
recvfrom(s,buffer,bufferlen,addr);
close(s);

и

socket s = new socket(...);
s.sendto(buffer,bufferlen,addr);
s.recvfrom(buffer,bufferlen,addr);
delete s;

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

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

P.S.: в линуксовом ядре устройства являются объектами. И файловые дескрипторы. И сокеты в том числе. Просто ООП-парадигма "одета" на синтаксис голого C, а не на C++. То же самое и в GTK.

> Сколько раз мне студни сдавали проги на Джабе, в которых конструкторы были public static и void

Ну вообще-то, конструктор является методом класса, со всеми вытекающими... :-)

Вот ищо один http://winterkoninkje.livejournal.com/58607.html критик \"чистого разума\".

Гневная отповедь http://stephan.reposita.org/archives/2008/09/01/direct-access-300-times-faste... здесь

Предлагают на вводных лекциях по программированию разбирать эти статьи

s/Предлагают на вводных лекциях по программированию разбирать эти статьи/Предлагаю на вводных лекциях по программированию разбирать эти статьи

fixed

Некогда, конечно, флудить.

Но вот давайте подойдём с другой стороны. Почему в бизнес-программировании так развит SQL? Почему при этом никто не делает шума, не пишет статей? Почему люди просто работают, делают полезные вещи и зарабатывают деньги без особого пафоса? Почему никто не кричит "SQL-остой"?

Потому что SQL-сервера, в отличие от ООП - это реально полезная вещь, которую не нужно никому впаривать. Здесь нет места для сектантства - и так всем всё понятно. Никого факт существования SQL не раздражает и я почти никогда не слышал, чтобы кого-то тошнило от SQL.

Любой мало-мальски нормальный SQL сервер предоставляет:

- механизм постоянного хранения данных

- высокую надёжность (никаких сегфолтов при попытке сложить две строки) и достаточно высокую производительность

- декларативный язык программирования (ты пишешь, ЧТО ты хочешь получить, а SQL сервер думает, КАК этого добиться)

- многозадачность с механизмами синхронизации (транзакции и блокировки)

- сетевая среда исполнения - сразу можно писать распределённые приложения

- эффективные и труднопреодолимые способы ограничения доступа

- простой и надёжный интерфейс для подключения клиентов

Сравните это с тем, что предоставляет ООП? Что он даёт?

- просто ещё один способ записи и структурирования программ. Заметим, далеко не единственный! Никто ещё не отменял возможность структурирования программы другими способами, с помощью префиксов имён, пространств имён, разбиения на модули, разбиения на отдельные приложения да и даже просто документирования! Т.е., ООП здесь приходит на уже занятое поле и начинает работать локтями.

- ООП расширения языков вводят примитивнейшие понятия, такие, как конструктор, наследование, полиморфизм, виртуальные методы. Фактически, это - просто дисциплина. Основа ООП расширения для С пишется на самом С за несколько часов. ООП не заставляет компьютер делять что-то за тебя. Она лишь служит (искусственным) ограничением для формы выражения твоих мыслей. Максимум, что может быть существенного в ООП расширениях - это очереди сообщений и метаклассы. Но сравните очередь сообщений и, к примеру, компилятор SQL-запросов. Очередь сообщений - это элемент среды времени исполнения, который прост как валенок. Любой нормальный программист на С мог бы реализовать такую очередь. Но далеко не любой программист на SQL мог бы реализовать компилятор SQL. Метаклассы же вообще не имеют отношения к ООП, если разобраться. Метаинформация есть и в SQL, и в том же лиспе, к примеру, хотя эти среды не относятся к ООП.

Итак, SQL - море существенных, сложных, продуманных, взаимно согласованных возможностей.

ООП - просто дисциплина, криво реализованная в наиболее популярных примерах.

Поэтому, SQL не вызывает возражений и споров, а просто используется (с выгодой) везде, где он уместен.

ООП вызывает споры, служит основой для сектанства и его использование полезно далеко не всегда.

И далее, касаемо кружки. Как минимум, тут не хватает понятия мультиметодов (а ведь мультиметоды - это тоже ООП).

Взять(рукой, кружку)

и

Взять(ногой, нож) - это же разные действия.

Да, шаблон визитор или как там пишут в ваших псевдо-умных сектантских библиях. На самом деле, это - костыль. Представьте себе, что Русский язык был бы настолько убог, что у него не было бы достаточной степени полиморфизма. Мы бы не получали удоволствие от флуда, а скрежетали бы зубами при попытки хоть что-то сказать.

Но, слава Богам, Русский язык разработан на небе, а не в кабинете Страуструпа. И поэтому мы можем написать (уже после компиляции синтаксиса) просто вот так:

Подготовить(кофейник)

Подготовить(кружка) (а кстати, методом чего в быдлоООП является подготовить? Кружки или человека? И почему я должен останавливаться и думать об этом?)

Перелить(из=кофейник,в=кружка,количество=количество) /* не просто мультеметод, а ещё и сигнатура с полиморфными keyword аргументами, можно ведь ещё представить себе опасность=горячее и скорость=неспешно */

Взять(чем=рука,что=кружка) /* при чём тут конечности? */

и т.п.

Вернёмся на землю. В CLOS мультиметоды есть (хотя я бы не сказал, что я считаю CLOS образом совершенства).

В Java их нет. Вот Вы, no-dashi, защищаете ООП, а ведь Вы не знаете ООП. Вы приводите пример из быдлоООП (без мультиметодов). Вот как Вам изуродовали сознание! И если 90% кодеров начать спрашивать про кружку, они напишут, по сути, то же, что и Вы.

Это значит, что невежество торжествует в мировом масштабе. Что и вызывает такую бурную реакцию у тех, кто хотя бы что-то понимает.

Короче, фанатам быдлоязыков (да, и С++ тоже), я бы советовал сходить в библиотеку и хоть что-нибудь почитать. Или можете почитать правильный код. Тогда вы поймёте, чем отличается то, что есть, от того, что должно быть. И заплачете.

Засим пока что всё.

> Взять(рукой, кружку) и Взять(ногой, нож) - это же разные действия.

Это как раз одно и то же действие, причем базового класса "конечность". Инструкция "взять" является неотъемлемым действием "хваталки", и конечным итогом имеет конечность, удерживающую объект. А вы опять таки ушли в процедурную логику, создав процедуру, а не метод класса.

"Взять плоскогубцами"? Да легко. И плоскогубцы, и конечность - представители абстрактного класса "хваталка", у которого есть "захваченные предметы".

Хваталка.Взять(Предмет[,Предосторожности]) {
Установить политику Предосторожности
Если не определен захваченный_объект - захватить объект и выйти
Если захваченный предмет представитель хваталки - захватить объект с указанными предосторожностями в ранее захваченный предмет и выйти
Неопределенная ветка, вернуть ошибку
}

Это всего лишь небольшое изменение на основании переработки предметной области.

> Почему в бизнес-программировании так развит SQL?

SQL это язык манипуляции данными, используется только там, где надо перелопачивать объемы данных. Реализовывать на SQL _логику_ - преступление. У меня сейчас на сопровождении под руками две системы, где разработчики пошли таким путем, обе убоги и ублюдочны. Одна худо-бедно расширяема, вторая вообще практически неконфигурируема.

ООП позволяет реализовать логику в терминах объектов и действий над этими объектами. Никто не говорит, что для одной и той же предметной области можно создать только одну объектную модель. Я мог ввести например отдельный класс, реализующий действия над объектами, и реализовать в нем несколько методов с различными наборами аргументов - но зачем? Я моделирую конкретно взятый процесс.

> а кстати, методом чего в быдлоООП является подготовить?

Всего. Подготовить кофейник? Вымыть, сварить кофе. Кружка? Вымыть, протереть. Человек? Вымыть руки. Будет ли "подготовка" методом человека, методом кофейника или вообще отдельным классом, который управляет взаимодействием "исполнителя" и "подготавливаемого пердмета" - это только вопрос реализации. Вопрос иерархии классов, если угодно.

>> Взять(рукой, кружку) и Взять(ногой, нож) - это же разные действия.

>Это как раз одно и то же действие, причем базового класса "конечность". Инструкция "взять" является неотъемлемым действием "хваталки", и конечным итогом имеет конечность, удерживающую объект. А вы опять таки ушли в процедурную логику, создав процедуру, а не метод класса.

Хорошо, перейдем к книжному примеру Александреску где надо заштриховать две пересекающиеся фигуры. Для двух прямоугольников процедура тривиальна, для остальных сложнее, однако если подходить специфически к каждому конкретному случаю то можно достичь приемлемого перформанса.

>SQL это язык манипуляции данными, используется только там, где надо перелопачивать объемы данных. Реализовывать на SQL _логику_ - преступление. У меня сейчас на сопровождении под руками две системы, где разработчики пошли таким путем, обе убоги и ублюдочны.

У опыт диаметрально противополжен: с хранимыми процедурами проблем нет как правило никаких, от разных ынтерпрайзных ООП-угробищ - проблем куча.

>Но вот давайте подойдём с другой стороны. Почему в бизнес-программировании так развит SQL? Почему при этом никто не делает шума, не пишет статей? Почему люди просто работают, делают полезные вещи и зарабатывают деньги без особого пафоса? Почему никто не кричит \"SQL-остой\"?

Кричат \"SQL-отстой\", еще как кричат. Просто у тебя интернета нет, и ты не в курсе тенденций: blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx http://ru.wikipedia.org/wiki/ORM http://phd.pp.ru/Russian/Software/orm.html И SQL не парадигма программирования и в программировании никак не помогает, это язык манипулирования хранящимися данными основанный на реляционной алгебре. Всё. Программировать он НЕ ПОМОЖЕТ.

Вот еще цитата http://www.rsdn.ru/forum/message/1576180.1.aspx \"А Вы пробовали сложную логику на сиквеле реализовывать? У нас были как-то фанаты сиквела... Пришлост все равно еще один уровень вводить и туда переводить логиук. Хотел бы я посмотреть на RTGS систему без бизнес-слоя\" Вместе с \"Реализовывать на SQL _логику_ - преступление. У меня сейчас на сопровождении под руками две системы, где разработчики пошли таким путем, обе убоги и ублюдочны. Одна худо-бедно расширяема, вторая вообще практически неконфигурируема.\" уже тенденция.

А насчет \"Почему в бизнес-программировании так развит SQL?\" потому что колхозники которых набрали по плану индустриализации^Wинформатизации поднимать IT-отрасль, ни о чем другом кроме SQL и 1Сы понятия не имеют.

> конечность - представители абстрактного класса "хваталка". Я извиняюсь перед модераторами. ХYI - это конечность? Раз так, то он тоже является "хваталкой"? Было бы интересно на это взглянуть...

Но даже если оставить этот вопрос, а исходить просто из структуры вещей. Предположим, у меня есть исходник божественного генокода человека. Допустим, он на объектном языке (хотя я бы в это не поверил, чувствуя совершенство тела).

Итак. Рука является одновременно:

хваталкой, стучалкой, подтягивалкой и махалкой-при-ходьбе. Заметим, что если нога является стучалкой, то подтягивалкой её вряд ли можно назвать.

Т.е., не всякая конечность является подтягивалкой, даже если XUI мы не будем относить к конечностям. Итак, по-Вашему, я должен завести 4 абстрактных класса, пронаследовать руку и ногу от разных наборов?

С моей точки зрения, рука является прежде всего рукой. А хваталка, стучалка, подтягивалка и т.п., это - функции руки. В лучшем случае, это - её интерфейсы (в смысле Java). При подключении этих интерфейсов нужно ещё и правильно протянуть нервы. Нервы явно не принадлежат руке, поэтому они не могут быть в базовом классе. Но они относятся к руке. Кстати, интерфейсы я не обязан декларировать сразу. Ведь я могу где-то на втором десятке лет эксплуатации реализовать для руки ещё и интерфейс "дрочилка". Должен ли я в этот момент убить себя об стену, исправить исходники и пересобраться?

Итак, можно видеть (хотя Вы этого видеть, скорее всего, не можете), что, пытаясь уложить реальность в прокрустово ложе быдлоООП, Вы жестоко коверкаете её.

> А вы опять таки ушли в процедурную логику, создав процедуру, а не метод класса

Это не процедуры, а мультиметоды. ООП, только более продвинутое.

> SQL это язык манипуляции данными, используется только там, где надо перелопачивать объемы данных. Реализовывать на SQL _логику_ - преступление. У меня сейчас на сопровождении под руками две системы, где разработчики пошли таким путем, обе убоги и ублюдочны. Одна худо-бедно расширяема, вторая вообще практически неконфигурируема.

Я являюсь автором и майнтейнером (в течение семи лет) программы, которая в основном написана на SQL (в том числе, самая сложная логика вся написана на SQL). Я не думаю, что меня за это привлекут к уголовной ответственности, напротив, мне до сих пор за это иногда платят деньги. Мне приятно этим заниматься, программу легко поддерживать. В другом месте я пытался участвовать в развитии программы, написанной на С++. Меня тошнило от работы. Теперь я там не работаю. Насколько я знаю, у этой фирмы сейчас финансовые проблемы, проведены сокращения. Конечно, дело не только в языке...

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

Кстати, касаемо ORM. Я не практиковал никаких чужих систем ORM, но, было дело, пробовал написать свою. Дело остановилось на этапе постановки задачи. При любом подходе было ясно, что теряю больше, чем получаю.

Иметь право на существование ORM система может только в одном случае, если она транслируется на скриптовое расширение SQL, типа PL-SQL. И, соответственно, транслирует методы в SQL-скрипты, оптимизируя обращения к БД. При этом, написать такой транслятор будет очень сложно. В противном случае, потери эффективности будут катастрофичны. Даже и в этом случае, смысл её сомнителен. Реляционный подход гораздо более гибок, чем объектный. Зачем городить лишний этаж, чтобы сказать сложно о том, о чём можно сказать просто?

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

>Её очень сложно так изуродовать,

поэтому и денег больших на книжках не наваришь

>бизнес-программировании

это что такое?

>Реализовывать на SQL _логику_ - преступление

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

>бизнес-слоя

это что такое?

>потому что колхозники которых набрали по плану индустриализации^Wинформатизации поднимать IT-отрасль, ни о чем другом кроме SQL и 1Сы понятия не имеют.

хуже них только менеджеры, они сами прилезли, ибо без руководящей роли партии никуда

> Иметь право на существование ORM система может только в одном случае, если она транслируется на скриптовое расширение SQL, типа PL-SQL. И, соответственно, транслирует методы в SQL-скрипты, оптимизируя обращения к БД. При этом, написать такой транслятор будет очень сложно. В противном случае, потери эффективности будут катастрофичны. Даже и в этом случае, смысл её сомнителен.

Почему? Фактически "модульная генерация" сложных SQL-запросов - не так уж и плохо. Многие и так клепают тот или иной код для построения сложных запросов. У меня такой код был "неудобоварим" ибо я отталкивался от задачи "упрощение генерации запроса как текста", а не "создание системы отображения совокупности структуры БД и набора параметров в SQL-запрос". Велосипед?

>Фактически "модульная генерация" сложных SQL-запросов - не так уж и плохо.

Может все же думать в теминах потребляемых ресурсов и сначала разработать нормальную табличную структуру под предметную область и написать критические запросы с примелемым планом, а уже потом на них навешивать всякое прочее барахло? Я конечно понимаю мотивацию ынтерпрайза - наклепать десять слоев чтобы потом заказчик был завязан на индоаутсорсере и его быдлокодерах навечно так как никто другой это барахло поддерживать не будет, но все же?

> Поэтому, SQL не вызывает возражений и споров
> ООП вызывает споры

http://download.oracle.com/docs/cd/B10500_01/appdev.920/a96594/adobjint.htm

"
objects make it easier to model complex, real-world business entities and logic, and the reusability of objects makes it possible to develop database applications faster and more efficiently. By natively supporting object types in the database, Oracle enables application developers to directly access the data structures used by their applications.
"


- Objects Can Encapsulate Operations Along with Data
- Objects Can Represent Part-Whole Relationships
- Objects Are Organic

и тд. и тп.


"

Чего-то не видел чтобы кто-то использовал оракловое ООП. Ну оракловцы фичу реализовали и пеарят, это понятно.

Нечитавшие СИКП жестко палятся в этом топике...

> просто интересно услышать, как можно " работать в большой команде"
(под большой командой я понимаю коллектив > 2человек) без ООП?
и так, чтобы твой код/либу (не программу) пользовали хотя бы 2-3 юзера.

Ну вообщем-то да, в некотором смысле я все-таки использую ООП. Главным образов в виде неформального объединения кода и данных и реализации интерфейсов.

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

>Итак. Рука является одновременно:
>...далее страничка рассуждений о конечностях

Не вижу постановки задачи, одна филология. Конечно, философствовать на божественные темы на языке С++ довольно затруднительно (как и на любом другом языке), но объясните мне, как божественный генокод человека связан с ООП?

> Может все же думать в теминах потребляемых ресурсов и сначала разработать нормальную табличную структуру под предметную область

+1

> и написать критические запросы с примелемым планом

+1

> а уже потом на них навешивать всякое прочее барахло?

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

> Я конечно понимаю мотивацию ынтерпрайза - наклепать десять слоев чтобы потом заказчик был завязан на индоаутсорсере и его быдлокодерах навечно так как никто другой это барахло поддерживать не будет, но все же?

А сейчас при отсутствии этих 10 слоёв кто-то другой прямо за пару дней "въедет" в развесистую структуру БД и мигом сообразит где и что надо поменять в связи с "новыми правилами"?

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

И не надо мне 10 слоёв и даже ORM не нужен - не знаю где вы это нашли в моих словах =)

>Нечитавшие СИКП...

что-то на лоре зачастили с упоминанием SICP. Это местный святой грааль?

Это один из универсальных ответов наряду с еврейской шапочкой, GNU Emacs и Battletoads.

> что-то на лоре зачастили с упоминанием SICP. Это местный святой грааль?

Это букварь, но очень многие, как и положено, "прогуливали школу" :)

букварь Схемы. На большее не тянет.

>А сейчас при отсутствии этих 10 слоёв кто-то другой прямо за пару дней "въедет" в развесистую структуру БД и мигом сообразит где и что надо поменять в связи с "новыми правилами"?

Подправить хранимую процедурку / добавить constraint все же проще чем ковыряться в тпипчной помойке ынтерпрайзного кода.

> Подправить хранимую процедурку / добавить constraint все же проще чем ковыряться в тпипчной помойке ынтерпрайзного кода.

А кому вы это объясняете? Я не этого хотел...

> букварь Схемы. На большее не тянет.

Твоё ИМХО было понятно и без этой твоей фразы.

>букварь Схемы. На большее не тянет.

ЛОЛшто? Ты хоть СИКП в глаза видел?

>Ты хоть СИКП в глаза видел?

читал

> Особенно мне противны библиотеки со "стройной" иерархией, которая потом при попытке расширения функционала порой оказывается тяжелым грузом, потому что базовые классы оказываются "погребенными" под иерархией.

ты не одинок. "Стройная иерархия" часто не нужна, нужно наследование поведения а не родословной в стиле "Авраам родил Исаака родил Object который родил ..."

http://insidecpp.ru/art/8/ (можно там ещё и про антипаттерны почитать. Хотя лучше про Антипаттерны читать в соотв. англоязычной книжке, там более цельно: программирование, методика программирования, менеджмент, стратегические соображения)

В этом смысле больше нравится не "иерархия в стиле С++", а тулкиты в стиле Смоллтока или Objective C. Или CLOS/MOP в CL.
Объекты и классы более ортогональны, что ли, новая сущность задаёт новое поведение, и не надо для простого расширения лепить новый класс.