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

AVK>Ну какой вопрос такой и ответ. Еще раз повторюсь — за шашечками не ко мне. Меня как то ни разу в жизни не волновал вопрос — а что есть ООП в высшем смысле этого слова.
Хм. Вопрос (возможно в процессе обсуждения его просто забыли =)) был такой: где взять то нечто, которое, по Вашим словам, все по-разному реализуют. Это Вы утверждали, что оно существует, а не я, поэтому и спрашиваю лично у Вас.

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

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

Честно говоря, не нравится мне Ваша аналогия с картиной — на ее основе можно извратить, все что я написал чуть выше в этом же посте. Но с картинами — там другой разговор, это все таки искусство. Его конечная цель не выполнение некоторых заранее заданных действий. От программы требуется, чтобы она работала, а не чтобы ее исходный код нравился окружающим. =)

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

>>>Т.е. кто сказал, что это — классика. Просьба не приводить примеры с Толстым — то классика субъективная, а >>программирование — вещь объективная.
A>>проектирование программ в чем-то сродни художественному творчеству
A>>ведь нет же в природе стандарта "как написать картину"
R>Зато в резюме часто пишут, что знакомы с ООП.

А еще можно написать в резюме "пишу картины маслом и сочиняю хойку". И что?

R>Как же тогда понимать такого рода фразы?

А так и понимать — человек считает, что он знаком с ООП.

R>Более того существуют различные книги по ООП, сродни той, о которой Вы говорили выше. В них тогда что описывается?

А взять и прочитать слабо?

R>Честно говоря, не нравится мне Ваша аналогия с картиной — на ее основе можно извратить, все что я написал чуть выше в этом же посте. Но с картинами — там другой разговор, это все таки искусство.

Бывает и ремесло.

R>Его конечная цель не выполнение некоторых заранее заданных действий.

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

R>От программы требуется, чтобы она работала, а не чтобы ее исходный код нравился окружающим. =)

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

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

R>От программы требуется, чтобы она работала, а не чтобы ее исходный код нравился окружающим. =)
И да и нет. Дело в том что существует такое поняте поддержка называется...

S>А еще можно написать в резюме "пишу картины маслом и сочиняю хойку". И что?
Именно поэтому я и отметил, что эта аналогия мне не оень нравится. Действительно так можно написать, но имхо здесь имеются в виду разные вещи. См. ниже.

R>>Как же тогда понимать такого рода фразы?
S>А так и понимать — человек считает, что он знаком с ООП.
Как определить, что человек знаком с ООП, если не известно, что такое ООП?

R>>Более того существуют различные книги по ООП, сродни той, о которой Вы говорили выше. В них тогда что описывается?
S>А взять и прочитать слабо?
Я читал. Страуструпа (то, что касается ООП), различные книги, посвященные OOD, лекции С.С.Гайсаряна, и т.п. Именно поэтому вопрос и возник. Нигде я так и не увидел ничего, кроме довольно общих слов и неких ссылок на тех самых теоретиков, которые "существуют в природе". Более того, иногда книги расходились в определениях.

R>>Честно говоря, не нравится мне Ваша аналогия с картиной — на ее основе можно извратить, все что я написал чуть выше в этом же посте. Но с картинами — там другой разговор, это все таки искусство.
S>Бывает и ремесло.
Бывает. Но для него существуют некоторые всем понятные рамки. Кто-то может рисовать портреты, а кто-то не может. При этом, что такое портрет — всем понятно.

R>>Его конечная цель не выполнение некоторых заранее заданных действий.
S>Т.е., ты считаешь, что написание программ — это выполнение некоторых заранее заданных действий? Тогда почему программирование до сих пор не автоматизировали, как, например, металлообработку?
Почему не автоматизировали? Не автоматизирован пока только процес построения математической модели того, что должно получиться в результате работы программы. При наличии модели дальнейшие действия вполне укладываются в общие схемы. RUP, например. Т.е. собственно при наличии идеи написание самого кода, пусть даже и ОО становится не такой уж сложной задачей.

R>>От программы требуется, чтобы она работала, а не чтобы ее исходный код нравился окружающим. =)
S>Не только. Во первых, от программы иногда требуется также чтобы ее исходный код нравился окружающим, или, по крайней мере, не был им противен Можно вспомнить еще сопровождаемость, расширяемость и т.д.
Что реализуется на уровне интерфейсов, предоставляемых полученым модулем, код которого в общем случае никому не интересен. Но это уже оффтопик. К первоначальному обсуждению отношения не имеет.

WH>И да и нет. Дело в том что существует такое поняте поддержка называется...
Да. Существует. Извините, но, к сожалению, я не понял Вашего многоточия после этой фразы.

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

WH>>И да и нет. Дело в том что существует такое поняте поддержка называется...
R>Да. Существует. Извините, но, к сожалению, я не понял Вашего многоточия после этой фразы.
Это означает что красивость кода тоже важна.

ЗЫ RSDN древовидный форум по этому пожалуйста не отвичай одним письмом нескольким людям.

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

WH>>>И да и нет. Дело в том что существует такое поняте поддержка называется...
R>>Да. Существует. Извините, но, к сожалению, я не понял Вашего многоточия после этой фразы.
WH>Это означает что красивость кода тоже важна.
Э-э-э ну а я собственно говорю, что красивость хоть и приятна, но не так уж важна по большому счету. Вы, как я понял, возразили, но как возразили — не понял (при чем здесь поддержка).

WH>ЗЫ RSDN древовидный форум по этому пожалуйста не отвичай одним письмом нескольким людям.
Хорошо. Просто у меня он плоский, поэтому я и не задумывался об этом никогда =))

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

R>>Вот например, всем известно, что бывают у объектов эл-ты public, private и protected. А почему только 3? Почему нет какого-нибудь четвертого?

WF>Кто тебе такую глупость сказал?

WF>public, private, protected — это уже косвенное следствие инкапсуляции.
Пардон, совсем пропустил это замечание.
Ну дык именно, что косвенное. Кто-то решил, что их должно быть 3, т.к. это "следует из инкапсуляции". Но, т.к. понятие самой инкапсуляции, как я понимаю, само четко не сформулированно, следствия из него имхо строить довольно опасно.

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

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

Очень даже при том.
Вот например работаем мы вместе на бухгалтеской системой. Ты пишешь клиента, я сервер. Всё хорошо. потом я уехал на 3 недели в отпуск. Тебя зовёт начальник и говорит, что при обработке команды ENUM_TAXES, если налогов больше 18 у нас вылетает сервер. Так мол огорчённый пользователь сообщил. Ты смотришь — и правда вылетает. А потом открываешь мой проект и видишь что весь код червера это один cpp файл без отступов. Как ты думаешь сколько времени уйдёт на исправление? А теперь подумай, когда я приеду через 3 недели, я сам в этом хоть что-то буду понимать? Наверное нет!

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

R>Сразу просьба: не кидайте тухлыми овощами. =)
Вот уж нет! Вопрос поставлен совершенно правильно. Менее 5% программистов ООП понимают, на чем они собственно программируют.
R>Пару месяцев назад задался целью узнать, что такое ООП. Максимум, что получилось — вышел на omg. Но там тоже толком ничего нет. Может быть all сможет показать мне четкую формулировку, что же такое этот самый ООП =)
вот в сообщении Re: Статья про развитие идей ООП. Жду комментариев.

Автор: Sinclair
Дата: 14.05.03

я привел список статей по теории ООП. Пока что это — самое лучшее из того, что я встречал. Еще можно поикать материалы по ключевому слову "F-logic", это более детальное развитие одного из подходов к математической формализации ООП.

Здравствуйте, Rumata, Вы писали:
R>Вот только опять не понятно, являются ли приведенные там документы какими-либо стандартами. неужели за более чем 10 лет развития, под ООП не подвели никаких признаных стандартов вообще?
В каком смысле стандартов? Стандартов математизации? А такие вообще есть? У нас хоть одна область математики оборудована каким-то стандартом? Или физика там? "Комитет ISO постановил пользоваться Гейзенберговским представлением квантовых операторов, так как оно наилучшим образом удовлетворяет потребности всех заинтересованных сторон". Все. Обновляем все учебники со Шредингеровским представлением. Ха-ха-ха.
Нет, на эту область стандартов нет и не будет. Если достаточное количество народу будет задумываться что и почему они делают, а не как добиться конкретной фичи, то есть шанс сформировать более-менее общепринятую терминологию. Пока что ООП находится примерно в той же стадии исследования, что и экономика — каждый автор свободно использует термины в своем смысле, и зачастую не в одном.

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

S>>А еще можно написать в резюме "пишу картины маслом и сочиняю хойку". И что?
R>Именно поэтому я и отметил, что эта аналогия мне не оень нравится. Действительно так можно написать, но имхо здесь имеются в виду разные вещи. См. ниже.

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

R>>>Как же тогда понимать такого рода фразы?
S>>А так и понимать — человек считает, что он знаком с ООП.
R>Как определить, что человек знаком с ООП, если не известно, что такое ООП?

А как определить, что он пишет картины маслом, а не мажет "сеятелей", как О. Бендер? Наверно, надо дать тестовое задание и посмотреть на результат. Или просто с ним побеседовать про ООП. Или попросить показать куски кода, им написанные.

R>>>Более того существуют различные книги по ООП, сродни той, о которой Вы говорили выше. В них тогда что описывается?
S>>А взять и прочитать слабо?
R>Я читал. Страуструпа (то, что касается ООП), различные книги, посвященные OOD, лекции С.С.Гайсаряна, и т.п. Именно поэтому вопрос и возник. Нигде я так и не увидел ничего, кроме довольно общих слов и неких ссылок на тех самых теоретиков, которые "существуют в природе". Более того, иногда книги расходились в определениях.

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

R>Бывает. Но для него существуют некоторые всем понятные рамки. Кто-то может рисовать портреты, а кто-то не может. При этом, что такое портрет — всем понятно.

Ага, только критерии оценки портретов у всех разные. Что такое качественный код всем (достаточно квалифицированным) программистам тоже понятно, однако критерии его оценки тоже у всех разные.

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

А как предполагается записывать эту самую математическую модель? Уж не на языке ли программирования каком-нибудь? Это я к тому, что программист эту математическую модель сам придумывает.

R>>>От программы требуется, чтобы она работала, а не чтобы ее исходный код нравился окружающим. =)
S>>Не только. Во первых, от программы иногда требуется также чтобы ее исходный код нравился окружающим, или, по крайней мере, не был им противен Можно вспомнить еще сопровождаемость, расширяемость и т.д.
R>Что реализуется на уровне интерфейсов, предоставляемых полученым модулем, код которого в общем случае никому не интересен.

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

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

R>Зато в резюме часто пишут, что знакомы с ООП.

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

R>Как же тогда понимать такого рода фразы?

В меру своей испорченности. Чаще всего это означает что автор знаком с каким либо ОО или близком к ОО средством.

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

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

Важна, еще как важна. Красота кода это оборотная сторона утилитарности. Код это не дом или автомобиль, в процессе своей жизни код непрерывно эволюционирует. И если он написан некрасиво то жизнь такого кода будет тяжелой и недолгой.

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

R>Хм. Вопрос (возможно в процессе обсуждения его просто забыли =)) был такой: где взять то нечто, которое, по Вашим словам, все по-разному реализуют. Это Вы утверждали, что оно существует, а не я, поэтому и спрашиваю лично у Вас.

Это нечто есть целый комплекс фактов и идей, сформированных на основании различных книг, научных работ, реализаций в конкретных языках. Говорить об ООП вобще собственно можно не очень долго и интересно. Базовыми свойствами принято считать те три свойства, о которых я писал. Все остальное зависит от конкретики.
Вот к примеру спецификация xml несколько страничек, насколько я помню. Однако xml related технологий море. А ведь что такое сам xml? Всего навсего несколько несложных правил построения структурированного текстового файла. Так и с ООП — в основу положено несколько простых идей, все остальное это их развитие.

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

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

O>>Посмотри на Cetus Links — Object-Orientation, может найдёшь подходящее
R>Большое спасибо! То, что доктор прописал!

R>Вот только опять не понятно, являются ли приведенные там документы какими-либо стандартами. неужели за более чем 10 лет развития, под ООП не подвели никаких признаных стандартов вообще?

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

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

O>Посмотри на Cetus Links — Object-Orientation, может найдёшь подходящее
R>Большое спасибо! То, что доктор прописал!
Пожалуйста

R>Вот только опять не понятно, являются ли приведенные там документы какими-либо стандартами. неужели за более чем 10 лет развития, под ООП не подвели никаких признаных стандартов вообще?
Что ты понимаешь под словом "стандарт"?
В некотором роде ООП — это некая философическая субстанция, которую разные люди понимают по своему. Собственно, существующие описания ООП (тот же Буч, например) — это всего лишь точки зрения людей, которые занимаются этой философией достаточно долго, некоторые их best practices и т.п. Закона Всемирного ООП нет и быть не может, и соответственно нет никакого Ньютона, которому бы на голову свалился класс и он открыл бы этот закон
Вот тебе аналогия:
Играем в большой теннис. В принципе, есть один стандарт — правила игры, и одна цель — выиграть. Дальше хоть сальто делай, играй как хочешь — достигай цели. Однако существует ряд наблюдений опытных игроков, что удар надо наносить так, что двигаться надо так и т.п. Это — рекомендации, которые имеют свои достоинства и недостатки. Есть школы игры, где своя интерпретация этого мирового опыта. И в школах преподают свой стиль.
Точно так же и в программировании. Есть один стандарт — чтоб работало. Дальше пиши хоть на ассемблере самомодифицирующийся код Но есть определенная практика, опыт, что в случае больших систем выгодно разделять логику программы на сущности, выгодно уменьшать зависимости между ними (см. также закон Деметры), выгодно переиспользовать код. Есть и определенные недостатки. Есть и школы (и их много, см A Survey of Object-Oriented Methods), которые исповедуют разные толкования этого философского и в некотором роде чисто абстрактного понятия. Поэтому найти стандарт на ООП в целом — невозможно. Хорошей иллюстрацией к вышесказанному будет концепция паттернов проектирования. Изначально — это часто повторяющаяся проблема, имеющаяся некоторое простое и эффективное, а главное хорошо описанное решение. Можно считать, что GOF — это стандарт, но это скорее просто сборник наиболее частых общих паттернов. Есть еще сетевые паттерны, см. Schmidt и его ACE Framework.

Вобщем, мой тебе совет Не ищи абсолютной истины, разберись с первоосновами, изучи разные точки зрения и составь свою.

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

R>Сразу просьба: не кидайте тухлыми овощами. =)

R>Пару месяцев назад задался целью узнать, что такое ООП. Максимум, что получилось — вышел на omg. Но там тоже толком ничего нет. Может быть all сможет показать мне четкую формулировку, что же такое этот самый ООП =)

К сожалению, так получилось, что термин ООП стал жертвой исторических обстоятельств.
Теперь по порядку...

Автором концепии ООП является Алан Кей. Мотивацией создания ООП послужили два основных источника — SketchPad и Simula.

SketchPad — абсолютно новая и непривычная (на то время — 1966) графическая система. Основные идеи — интерактивная компьютерная графика, наличие master и instance рисунков (похоже на класс-объект), наличие динамических constraints, задающие форму и отношение частей рисунка.

Simula — system-oriented language. Имелись activities и processes (аналогично masters и instances в SketchPad). Simula был процедурным языком, имеющим средства создания и контролирования объектов.

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

После этого Алан Кей сформулировал три базовых принципа объектного подхода:
1. Объект — базовая единица системы.
2. Объекты обладают состоянием.
3. Единственным способом взаимодействия между объектами является посылка сообщения. Объекты сами определяют как обрабатывать сообщения.

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

Но почему-то так вышло, что все обратились к модели Simula, т.е. навесили ООП ярлык ИНКАПСУЛЯЦИЯ, ПОЛИМОРФИЗМ, НАСЛЕДОВАНИЕ. И главными ценностями были провозглашены модульность и повторное использование.

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

Кое-что на эту тему можно прочитать здесь.

Поэтому ООП можно условно поделить на две категории — OBJECT-oriented и object-ORIENTED.
В первом случае имеем полноценную динамическую систему (Smalltalk, Self, отчасти Objective-C, Ruby), во втором — процедуры, завернутые в классы (Simula, C++, Java, C#).

--

Владимир.

AVK>>В книжках. Названия и фамилии не спрашивай, уже не вспомню.

A>классика ООП — Гради Буч "Объектно-ориентированный анализ и проектирование"
A>в оригинале "Object-Oriented Analysis and Design with Applications"

R>Иэ-э-эх. Опять туда же — чья классика? Т.е. кто сказал, что это — классика.

Предлагаю подвергнуть наглеца рефакторингу. А будет сопротивляться — и бак-инжинирингу.

R>Вот только опять не понятно, являются ли приведенные там документы какими-либо стандартами. неужели за более чем 10 лет развития, под ООП не подвели никаких признаных стандартов вообще?

А что, есть какие-то стандарты "реляционности" баз данных?

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

P.S. Хотя, на сегодняшний день, самым классическим и строгим стандартным языком ООП-программирования можно считать Java. Его всякая научная общественность в институтах массово изучает, и на его основе всякое ООП проходят. Имеются ввиду, конечно, западные институты. Наши пока в программировании не авторитет.