Ответ на »сообщение 3706« (al_mt)
___________________________
Разрабатывать чего-то безусловно можно и без ООП, с этим ни кто не спорит. Но может вспомните кризис программизма 70-х? Причина - порог сложности, который удалось преодолеть именно с помощью идей ООП.
Опаньки, я чего-то пропустил... Таки порог преодолён уже?!!! :о) И в каких же отраслях программирования, подскажите! А я пока загадаю, а потом сравним... :о))))))))))

Здесь часто приводятся примеры, как можно сделать то или иное и думаю Вы сами легко придумаете пример задачи, когда ООП, скажем так - оптимально. Но не надо забывать и о другой стороне ООП - эта технология даёт коллосальные преимущества именно в индустриальной разработке ПО. "Чистые" программисты это не всегда могут понимать, а кто по-моложе еще и серной кислотой плеваться начинають :) Ничего-ничего, вот назначат начальниками, вы все еще попрыгаете ;)))))))))))
Поясняю на счёт разделения. Вы не можете начать "параллельную разработку", пока у вас не будет нормально проработанной проанализированной предметной области и плана системы. Параллельно можно разрабатывать и подсистемы (там критичность к определениям дисциплины связей ниже, чем на микроуровне, опятьтаки из-за степени абстрактности характера этих связей). Термин "индустриальная разработка" очень часто применяется не к месту. В наших, постсоветских условиях, его чаще всего применяют молодые, да ранние мальчики-миньеджеры и тим-лидеры в конторах, штампующих ПО для западных заказчиков "в области веб-программирования и информационных систем". Обычно эти "управленцы", "проскочившие" через очень кратковременный период своего "девелоперства" на Дельфи, ВижуалБэйсике или HTML+скриптования... Именно у них с понятием ООП связан прежде всего "конкретно-разработческий" аспект с уклоном на "сопровождение". Когда начинаешь разговаривать с такими товарищами, в конце приходишь к выводу, что, как раз знание нанимаемыми программистами ООП, как средства проектирования и на фиг не нужно в таких конторах, а нужно, что бы человек "умел программировать на ... или в ...", то есть был взаимозаменяемым винтиком в условиях постоянной текучки кадров в таких проектах. Естественно, что, по характеру задач, каких-то запредельных проблем они не решают, они – потребители и юзеры тулзовин и библиотек, в изобилии имеющихся на рынке для решения установившегося, "устаканившегося" набора задач. Эти наборы давно формализованы и вылиты в системы классов или настраиваемые компоненты. Ни овладение ими, ни, как я уже сказал, сложность задач, решаемых с помощью них, ни в коей мере не заставят этих "миньеджеров" усомниться, что "кризис уже преодалён"... Отработанность подходов и наличие (полу)готовых решений, естественным образом выдвигает на первый план организационный аспект. А пересади этого "товарища" в кресло управленца проектом для встраиваемых систем, космоса, аэронавтики, систем управления реакторами или ещё какой АСУТП, вот тогда я на него и посмотрю. И на его уверенность в "уже преодолении кризиса"... :о)

Кстати, а откуда взялся термин "кошачий пастух"?

Дополнение насчёт "скрытости".
Жил был такой Древний Египет.
Уже интересно! Так вы в сказки верите?! :о) Учтите, эта – из разряда той "о преодалении"... :о)

И был у них, как и положено ДревнеЕгипетский письменный.
Это при расшифровке которого, в некоторых пирамидах, тексты НОВОГО Завета получаются? ;о))))
В котором, ну Вы помните. Гласные были "скрыты". И что? Ни кто же от гласных не отказался из-за этого :)
А там они и не нужны были. Почти все они (по реконструкции) были неопределённо звучащими. А смысл как раз из окружающего текста был понятен (контест сформирован!) ... :о)

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

Ответ на »сообщение 3707« (al_mt)
___________________________

То что Вы называете "скрытостью" - это не проблема ООП, а недостаток средств разработки (редакторов в конце-концов), каковой впрочем постепенно правится, хотя и медленне чем хотелось бы.

Ну конечно, какая проблема может быть в ООП-парадигме? Никакой. Она хорошая! Замечательная! Самая-самая!

Занятно, однако... Элементарные, казалось бы вещи. "Плоские" модули на уровне "тупых" разъемов (да еще без наследования и полиморфизма) супротив "объемных" классов со всеми мыслимыми и немыслимыми средствами самого что ни на есть передового программирования.

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

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

Потрясающе!

Ответ на »сообщение 3708« (Владимир Лось)
___________________________
Если Вы работаете с готовой библиотекой классов, то у Вас УЖЕ скомпонован глобальный контекст, в котором Вы УЖЕ можете работать со всеми включенными типами, и разумеется видимости УЖЕ на месте.

Вы же не будете утверждать, что предпочли бы для каждого проекта начинать разработку с проектирования процессора?

Ответ на »сообщение 3705« (al_mt)
___________________________
y:=sin(x);Ву компре?
Звычайно, а як же?!
Просто у вас УЖЕ компилятором скомпонован глобальный контекст в котором вы можете УЖЕ работать с переменными численных типов. Классы этих переменных УЖЕ видимы. Вы как бы УЖЕ находитесь в областях видимости, в которых можете вызывать нужные функции.

Или в области видимости класса CPU... :о)
А что, вполне могу допустить, что (отвлекаясь от библиотеки Си), можно представить данную функцию, как метод класса TCPU,

double TCPU::sin(double);

от которого унаследован Tx86CPU, от которого - T286CPU, от которого - T386CPU, от которого - T486CPU, от которого - T586CPU, от которого - T586ProCPU, от которого - T586MMXCPU... :o)
Это, канечна, маразм, но в рамках парадигмы... :о)

Ответ на »сообщение 3703« (Руслан Богатырев)
___________________________
Дополнение насчёт "скрытости".
Жил был такой Древний Египет. И был у них, как и положено ДревнеЕгипетский письменный. В котором, ну Вы помните. Гласные были "скрыты". И что? Ни кто же от гласных не отказался из-за этого :)

То что Вы называете "скрытостью" - это не проблема ООП, а недостаток средств разработки (редакторов в конце-концов), каковой впрочем постепенно правится, хотя и медленне чем хотелось бы.

Ответ на »сообщение 3704« (Владимир Лось)
___________________________
Разрабатывать чего-то безусловно можно и без ООП, с этим ни кто не спорит. Но может вспомните кризис программизма 70-х? Причина - порог сложности, который удалось преодолеть именно с помощью идей ООП.

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

Здесь часто приводятся примеры, как можно сделать то или иное и думаю Вы сами легко придумаете пример задачи, когда ООП, скажем так - оптимально. Но не надо забывать и о другой стороне ООП - эта технология даёт коллосальные преимущества именно в индустриальной разработке ПО. "Чистые" программисты это не всегда могут понимать, а кто по-моложе еще и серной кислотой плеваться начинають :) Ничего-ничего, вот назначат начальниками, вы все еще попрыгаете ;)))))))))))

Ответ на »сообщение 3703« (Руслан Богатырев)
___________________________

y:=sin(x);

Ву компре?

Ответ на »сообщение 3702« (al_mt)
___________________________
Откровенно говоря, я еще не видел квалифицированного ООП программиста, который бы оное ООП охаивал в пользу "модульного" или "функционального" программирования. Может просто разобраться надо?
Ой-надо!...
Надо разобраться прежде всего в том ДЛЯ ЧЕГО люди учатся ООП. Именно, для проектирования ПО или просто потому, что большинство инструментальных средств и библиотек спроектированы с его помощью? Понимаете, о чём я? Для использования STL, вы может и не ДОЛЖНЫ знать все нюансы шаблонизации в Си++, но минимальный уровень знаний необходим. То же касается и VCL...

То что называют "скрытыми" реализациями (методами, функциями, структурами) не фига не скрыто, всё элементарно открывается по <Ctrl+Left_Mouse_Buton> :))))
Во-во-во... :о))))

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

Но вот ваш термин разделения процесса создания ПО на параллельно разрабатываемые(!) классы мне не нравится... Вы разделяете РАБОЧИЙ ПРОЦЕСС или проводите анализ предметной области?

Ответ на »сообщение 3702« (al_mt)
___________________________

То что называют "скрытыми" реализациями (методами, функциями, структурами) не фига не скрыто

Скажите, вам понятно, что в ООП исполнение кода ведется в рамках контекста иерархии классов? Что делегируются действия (обработка сообщений)? Что глядя в конкретное место исходного текста нельзя сразу понять, что же делается, пока не выявишь взаимосвязь между классами и привнесенное в ОО-слои доопределение/переопределение функций обработки?

Вам понятно, что это исполнение происходит в контексте, который надо знать? Это и имеется в виду под словами "скрытый"/"неявный".

Сколько? -- Полтора. -- Чего полтора? -- А чего сколько?

Ммм...
Откровенно говоря, я еще не видел квалифицированного ООП программиста, который бы оное ООП охаивал в пользу "модульного" или "функционального" программирования. Может просто разобраться надо?
То что называют "скрытыми" реализациями (методами, функциями, структурами) не фига не скрыто, всё элементарно открывается по <Ctrl+Left_Mouse_Buton> :))))
Возможности же разделения процесса создания ПО на параллельно разрабатываемые(!) классы - это просто манна небесная для любого "кошачьего пастуха". Попробовали бы Вы чего-нить такое разработать командой из двух десятков програмеров без ООП...