Пару месяцев назад задался целью узнать, что такое ООП. Максимум, что получилось — вышел на omg. Но там тоже толком ничего нет. Может быть all сможет показать мне четкую формулировку, что же такое этот самый ООП =)
Здравствуйте, Rumata, Вы писали:
R>Сразу просьба: не кидайте тухлыми овощами. =)
А тухлыми фруктами?
R>Пару месяцев назад задался целью узнать, что такое ООП. Максимум, что получилось — вышел на omg. Но там тоже толком ничего нет. Может быть all сможет показать мне четкую формулировку, что же такое этот самый ООП =)
И не догадываюсь даже... Не, догадываюсь — может, Организация Освобождения Палестины?
Здравствуйте, Flamer, Вы писали:
F>И не догадываюсь даже... Не, догадываюсь — может, Организация Освобождения Палестины?
Нет это из коментариев к Серьезному Сему Огромные Открытые Пространства.
ЗЫ
... << RSDN@Home 1.0 beta 6a >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Rumata, Вы писали:
R>Сразу просьба: не кидайте тухлыми овощами. =)
R>Пару месяцев назад задался целью узнать, что такое ООП. Максимум, что получилось — вышел на omg. Но там тоже толком ничего нет. Может быть all сможет показать мне четкую формулировку, что же такое этот самый ООП =)
Ну и что? Где там написанно, что такое ООП. Т.е. что ООП — объектно ориентированное программирование я понимаю. Вот только например, что такое реляционные базы данных — я понимаю лучше. Для них построенна мат теория, если взять некую структуру, посмотреть на нее — можно опредеелить, реляционная это база данных или нет. Ну и т.д. А вот что такое ООП — так и не понятно. В статьях кидаются умными словами наследование, полиморфизм и т.д. А откуда они взялись?
Вот например, всем известно, что бывают у объектов эл-ты public, private и protected. А почему только 3? Почему нет какого-нибудь четвертого?
Здравствуйте, Rumata, Вы писали:
R>Вот например, всем известно, что бывают у объектов эл-ты public, private и protected. А почему только 3? Почему нет какого-нибудь четвертого?
Кто тебе такую глупость сказал?
public, private, protected — это уже косвенное следствие инкапсуляции.
7. О чем невозможно говорить, о том следует молчать.
Здравствуйте, Rumata, Вы писали:
R>Сразу просьба: не кидайте тухлыми овощами. =)
R>Пару месяцев назад задался целью узнать, что такое ООП. Максимум, что получилось — вышел на omg. Но там тоже толком ничего нет. Может быть all сможет показать мне четкую формулировку, что же такое этот самый ООП =)
Посмотри на Cetus Links — Object-Orientation, может найдёшь подходящее
Здравствуйте, Rumata, Вы писали:
R>Вот например, всем известно, что бывают у объектов эл-ты public, private и protected. А почему только 3? Почему нет какого-нибудь четвертого?
Это уже особенности реализации ООП в конкретных языках. Обычно считают обязательными признаками ООП три вещи: инкапсуляцию, наследование и полиморфизм.
Здравствуйте, AndrewVK, Вы писали:
AVK>Это уже особенности реализации ООП в конкретных языках. Обычно считают обязательными признаками ООП три вещи: инкапсуляцию, наследование и полиморфизм.
Оп-па! ну ка, давайте, во-первых, это как "особенности реализации" — значит есть некое нечто-то которое все по-разному реализуют! Вот про это нечто я и пытаюсь выяснить. Теперь, во-вторых, "Обычно считают" — кто считает? Почему считает именно так, а не как-то иначе? а если я буду считать иначе это будет ооп или нет?
Здравствуйте, orangy, Вы писали:
O>Посмотри на Cetus Links — Object-Orientation, может найдёшь подходящее
Большое спасибо! То, что доктор прописал!
Вот только опять не понятно, являются ли приведенные там документы какими-либо стандартами. неужели за более чем 10 лет развития, под ООП не подвели никаких признаных стандартов вообще?
Здравствуйте, Rumata, Вы писали:
R>Оп-па! ну ка, давайте, во-первых, это как "особенности реализации" — значит есть некое нечто-то которое все по-разному реализуют!
Есть. В некоторых языках вышеприведенные модификаторы не все или по другому трактуются (Object Pascal). В некоторых языках модификаторов больше (internal, FamiliAndAssembly, friend и т.д.)
R>"Обычно считают" — кто считает?
Теоретики ООП. Если ты хочешь стандартов то их нет.
R>Почему считает именно так, а не как-то иначе? а если я буду считать иначе это будет ооп или нет?
Ну как тебе сказать? Ну вот к примеру некоторые php считают ОО-языком, хотя, если честно, это не так. В общем тебе шашечки или ехать? Если шашечки то не знаю, если ехать то можешь принять три ранее приведенных признака за отправную точку, не ошибешься.
Здравствуйте, AndrewVK, Вы писали:
AVK>Есть. [...]
Где есть?
R>>"Обычно считают" — кто считает? AVK>Теоретики ООП. Если ты хочешь стандартов то их нет.
Где взять теоретиков ООП?
R>>Почему считает именно так, а не как-то иначе? а если я буду считать иначе это будет ооп или нет? AVK>Ну как тебе сказать? Ну вот к примеру некоторые php считают ОО-языком, хотя, если честно, это не так. В общем тебе шашечки или ехать? Если шашечки то не знаю, если ехать то можешь принять три ранее приведенных признака за отправную точку, не ошибешься.
Мне бы с шашечками поездить, без шашечек уже наездился
btw "некоторые php считают ОО-языком, хотя, если честно, это не так" видите, что получается как в известном рассказе: "чую бесовщину, а обосновать не могу"
AVK>>В книжках. Названия и фамилии не спрашивай, уже не вспомню. A>классика ООП — Гради Буч "Объектно-ориентированный анализ и проектирование" A>в оригинале "Object-Oriented Analysis and Design with Applications"
Иэ-э-эх. Опять туда же — чья классика? Т.е. кто сказал, что это — классика. Просьба не приводить примеры с Толстым — то классика субъективная, а программирование — вещь объективная.
AVK>>Есть. [...] R>>Где есть? AVK>В природе
Хммм. Имхо не ответ
Здравствуйте, Rumata, Вы писали:
AVK>>Есть. [...] R>>Где есть? AVK>В природе R>Хммм. Имхо не ответ
Ну какой вопрос такой и ответ. Еще раз повторюсь — за шашечками не ко мне. Меня как то ни разу в жизни не волновал вопрос — а что есть ООП в высшем смысле этого слова.
AVK>Ну какой вопрос такой и ответ. Еще раз повторюсь — за шашечками не ко мне. Меня как то ни разу в жизни не >волновал вопрос — а что есть ООП в высшем смысле этого слова
"оно существует независимо от нас, от наших знаний о нем"(с)школьный курс физики
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну какой вопрос такой и ответ. Еще раз повторюсь — за шашечками не ко мне. Меня как то ни разу в жизни не волновал вопрос — а что есть ООП в высшем смысле этого слова.
Хм. Вопрос (возможно в процессе обсуждения его просто забыли =)) был такой: где взять то нечто, которое, по Вашим словам, все по-разному реализуют. Это Вы утверждали, что оно существует, а не я, поэтому и спрашиваю лично у Вас.
Здравствуйте, Awaken, Вы писали:
>>Т.е. кто сказал, что это — классика. Просьба не приводить примеры с Толстым — то классика субъективная, а >>программирование — вещь объективная. A>проектирование программ в чем-то сродни художественному творчеству A>ведь нет же в природе стандарта "как написать картину"
Зато в резюме часто пишут, что знакомы с ООП. Как же тогда понимать такого рода фразы? Более того существуют различные книги по ООП, сродни той, о которой Вы говорили выше. В них тогда что описывается?
Честно говоря, не нравится мне Ваша аналогия с картиной — на ее основе можно извратить, все что я написал чуть выше в этом же посте. Но с картинами — там другой разговор, это все таки искусство. Его конечная цель не выполнение некоторых заранее заданных действий. От программы требуется, чтобы она работала, а не чтобы ее исходный код нравился окружающим. =)
Здравствуйте, Rumata, Вы писали:
>>>Т.е. кто сказал, что это — классика. Просьба не приводить примеры с Толстым — то классика субъективная, а >>программирование — вещь объективная. A>>проектирование программ в чем-то сродни художественному творчеству A>>ведь нет же в природе стандарта "как написать картину" R>Зато в резюме часто пишут, что знакомы с ООП.
А еще можно написать в резюме "пишу картины маслом и сочиняю хойку". И что?
R>Как же тогда понимать такого рода фразы?
А так и понимать — человек считает, что он знаком с ООП.
R>Более того существуют различные книги по ООП, сродни той, о которой Вы говорили выше. В них тогда что описывается?
А взять и прочитать слабо?
R>Честно говоря, не нравится мне Ваша аналогия с картиной — на ее основе можно извратить, все что я написал чуть выше в этом же посте. Но с картинами — там другой разговор, это все таки искусство.
Бывает и ремесло.
R>Его конечная цель не выполнение некоторых заранее заданных действий.
Т.е., ты считаешь, что написание программ — это выполнение некоторых заранее заданных действий? Тогда почему программирование до сих пор не автоматизировали, как, например, металлообработку?
R>От программы требуется, чтобы она работала, а не чтобы ее исходный код нравился окружающим. =)
Не только. Во первых, от программы иногда требуется также чтобы ее исходный код нравился окружающим, или, по крайней мере, не был им противен Можно вспомнить еще сопровождаемость, расширяемость и т.д.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Rumata, Вы писали:
R>От программы требуется, чтобы она работала, а не чтобы ее исходный код нравился окружающим. =)
И да и нет. Дело в том что существует такое поняте поддержка называется...
... << RSDN@Home 1.0 beta 6a >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
S>А еще можно написать в резюме "пишу картины маслом и сочиняю хойку". И что?
Именно поэтому я и отметил, что эта аналогия мне не оень нравится. Действительно так можно написать, но имхо здесь имеются в виду разные вещи. См. ниже.
R>>Как же тогда понимать такого рода фразы? S>А так и понимать — человек считает, что он знаком с ООП.
Как определить, что человек знаком с ООП, если не известно, что такое ООП?
R>>Более того существуют различные книги по ООП, сродни той, о которой Вы говорили выше. В них тогда что описывается? S>А взять и прочитать слабо?
Я читал. Страуструпа (то, что касается ООП), различные книги, посвященные OOD, лекции С.С.Гайсаряна, и т.п. Именно поэтому вопрос и возник. Нигде я так и не увидел ничего, кроме довольно общих слов и неких ссылок на тех самых теоретиков, которые "существуют в природе". Более того, иногда книги расходились в определениях.
R>>Честно говоря, не нравится мне Ваша аналогия с картиной — на ее основе можно извратить, все что я написал чуть выше в этом же посте. Но с картинами — там другой разговор, это все таки искусство. S>Бывает и ремесло.
Бывает. Но для него существуют некоторые всем понятные рамки. Кто-то может рисовать портреты, а кто-то не может. При этом, что такое портрет — всем понятно.
R>>Его конечная цель не выполнение некоторых заранее заданных действий. S>Т.е., ты считаешь, что написание программ — это выполнение некоторых заранее заданных действий? Тогда почему программирование до сих пор не автоматизировали, как, например, металлообработку?
Почему не автоматизировали? Не автоматизирован пока только процес построения математической модели того, что должно получиться в результате работы программы. При наличии модели дальнейшие действия вполне укладываются в общие схемы. RUP, например. Т.е. собственно при наличии идеи написание самого кода, пусть даже и ОО становится не такой уж сложной задачей.
R>>От программы требуется, чтобы она работала, а не чтобы ее исходный код нравился окружающим. =) S>Не только. Во первых, от программы иногда требуется также чтобы ее исходный код нравился окружающим, или, по крайней мере, не был им противен Можно вспомнить еще сопровождаемость, расширяемость и т.д.
Что реализуется на уровне интерфейсов, предоставляемых полученым модулем, код которого в общем случае никому не интересен. Но это уже оффтопик. К первоначальному обсуждению отношения не имеет.
WH>И да и нет. Дело в том что существует такое поняте поддержка называется...
Да. Существует. Извините, но, к сожалению, я не понял Вашего многоточия после этой фразы.
Здравствуйте, Rumata, Вы писали:
WH>>И да и нет. Дело в том что существует такое поняте поддержка называется... R>Да. Существует. Извините, но, к сожалению, я не понял Вашего многоточия после этой фразы.
Это означает что красивость кода тоже важна.
ЗЫ RSDN древовидный форум по этому пожалуйста не отвичай одним письмом нескольким людям.
... << RSDN@Home 1.0 beta 6a >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, 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: Статья про развитие идей ООП. Жду комментариев.
я привел список статей по теории ООП. Пока что это — самое лучшее из того, что я встречал. Еще можно поикать материалы по ключевому слову "F-logic", это более детальное развитие одного из подходов к математической формализации ООП.
... << RSDN@Home 1.0 beta 7a >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Rumata, Вы писали: R>Вот только опять не понятно, являются ли приведенные там документы какими-либо стандартами. неужели за более чем 10 лет развития, под ООП не подвели никаких признаных стандартов вообще?
В каком смысле стандартов? Стандартов математизации? А такие вообще есть? У нас хоть одна область математики оборудована каким-то стандартом? Или физика там? "Комитет ISO постановил пользоваться Гейзенберговским представлением квантовых операторов, так как оно наилучшим образом удовлетворяет потребности всех заинтересованных сторон". Все. Обновляем все учебники со Шредингеровским представлением. Ха-ха-ха.
Нет, на эту область стандартов нет и не будет. Если достаточное количество народу будет задумываться что и почему они делают, а не как добиться конкретной фичи, то есть шанс сформировать более-менее общепринятую терминологию. Пока что ООП находится примерно в той же стадии исследования, что и экономика — каждый автор свободно использует термины в своем смысле, и зачастую не в одном.
... << RSDN@Home 1.0 beta 7a >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Rumata, Вы писали:
S>>А еще можно написать в резюме "пишу картины маслом и сочиняю хойку". И что? R>Именно поэтому я и отметил, что эта аналогия мне не оень нравится. Действительно так можно написать, но имхо здесь имеются в виду разные вещи. См. ниже.
В принципе, одинаковые. Потому что написание чего угодно в резюме подразумевает только то, что человек желает устроится на работу, и ничего больше.
R>>>Как же тогда понимать такого рода фразы? S>>А так и понимать — человек считает, что он знаком с ООП. R>Как определить, что человек знаком с ООП, если не известно, что такое ООП?
А как определить, что он пишет картины маслом, а не мажет "сеятелей", как О. Бендер? Наверно, надо дать тестовое задание и посмотреть на результат. Или просто с ним побеседовать про ООП. Или попросить показать куски кода, им написанные.
R>>>Более того существуют различные книги по ООП, сродни той, о которой Вы говорили выше. В них тогда что описывается? S>>А взять и прочитать слабо? R>Я читал. Страуструпа (то, что касается ООП), различные книги, посвященные OOD, лекции С.С.Гайсаряна, и т.п. Именно поэтому вопрос и возник. Нигде я так и не увидел ничего, кроме довольно общих слов и неких ссылок на тех самых теоретиков, которые "существуют в природе". Более того, иногда книги расходились в определениях.
А в ООП и нет ничего, кроме нескольких довольно простых идей. Вопрос только в том, как их применять на практике. А насчет определений — попробуй найти четкое определение, скажем, джаза. Однако джазмены как то работу находят и вообще друг друга за версту чуют
R>Бывает. Но для него существуют некоторые всем понятные рамки. Кто-то может рисовать портреты, а кто-то не может. При этом, что такое портрет — всем понятно.
Ага, только критерии оценки портретов у всех разные. Что такое качественный код всем (достаточно квалифицированным) программистам тоже понятно, однако критерии его оценки тоже у всех разные.
R>Почему не автоматизировали? Не автоматизирован пока только процес построения математической модели того, что должно получиться в результате работы программы. При наличии модели дальнейшие действия вполне укладываются в общие схемы. RUP, например. Т.е. собственно при наличии идеи написание самого кода, пусть даже и ОО становится не такой уж сложной задачей.
А как предполагается записывать эту самую математическую модель? Уж не на языке ли программирования каком-нибудь? Это я к тому, что программист эту математическую модель сам придумывает.
R>>>От программы требуется, чтобы она работала, а не чтобы ее исходный код нравился окружающим. =) S>>Не только. Во первых, от программы иногда требуется также чтобы ее исходный код нравился окружающим, или, по крайней мере, не был им противен Можно вспомнить еще сопровождаемость, расширяемость и т.д. R>Что реализуется на уровне интерфейсов, предоставляемых полученым модулем, код которого в общем случае никому не интересен.
Насчет общих случаев я не в курсе, а вот частные, когда приходится копаться в чужом коде, приключаются достаточно регулярно.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, 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. Его всякая научная общественность в институтах массово изучает, и на его основе всякое ООП проходят. Имеются ввиду, конечно, западные институты. Наши пока в программировании не авторитет.
Здравствуйте, Rumata, Вы писали:
R>Сразу просьба: не кидайте тухлыми овощами. =)
R>Пару месяцев назад задался целью узнать, что такое ООП. Максимум, что получилось — вышел на omg. Но там тоже толком ничего нет. Может быть all сможет показать мне четкую формулировку, что же такое этот самый ООП =)
Обратимся к гигантам мысли, итак
В 1988 году Бьярн Страуструп, автор Си++ (Bell Lab) говрит следующее:
"Объектно-ориентированное программирование" - это средство, парадигма для
написания "хороших программ".
Тогда-же он объясняет термин "хорошая программа":
Допускает повторное использование для разработки других программ.
Расширяема, т.е. требует минимальных затрат на перепрограммирование при внесении дополнительных свойств или модификации существующих.
Надежна.
Мобильна, т.е. подразумевает минимальные затраты при переносе на другие платформы.
Дешева. Затраты на реализацию проектов бывают столь высоки, что порой от них приходится просто отказываться. Принципы ООП представляют лучший из известных ответов на вопрос "как писать хорошие программы?"
В 1989 году Bertrand Meyer, автор книги Object-Oriented Software Construction(Prentice-Hall) дает определение ООП:
"Объектно-ориентированный дизайн - это построение программных систем как
структурированных наборов реализаций абстрактных типов данных".
Основная мысль заключается в построении (разработке) программы из классов объектов, которыми она манипулирует, а не из функций, которые над ними (объектами) выполняются. Под классом подразумевается реализованный абстрактный тип данных, а под объектом — конкретные данные, т.е. экземпляр данного типа (класса). Что касается функций, то они определяются свои — над каждым типом данных, при этом сами данные (объекты) оказываются доступными только через эти функции, составляющие официальный интерфейс данного класса, другими словами, реализация типа полностью скрыта (инкапсуляция).
Здравствуйте, Sergey, Вы писали:
S>А как предполагается записывать эту самую математическую модель? Уж не на языке ли программирования каком-нибудь? Это я к тому, что программист эту математическую модель сам придумывает.
Ну почему же, я вот верю, что математика в конце концов опишет все =)
Дело в том, что я сначаала начал пользоваться реляционными бд (в т.ч. и нормальными формами), а потом прочитал теорию, почему нормальные форму лучше, чем ненормальные. С тех пор мне кажется, что за любым "rule of thumb", которое на практике облечает программисту жизнь лежит некоторое математическое обоснование =)
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Rumata, Вы писали:
WH>>Это означает что красивость кода тоже важна. R>>Э-э-э ну а я собственно говорю, что красивость хоть и приятна, но не так уж важна по большому счету.
AVK>Важна, еще как важна. Красота кода это оборотная сторона утилитарности. Код это не дом или автомобиль, в процессе своей жизни код непрерывно эволюционирует. И если он написан некрасиво то жизнь такого кода будет тяжелой и недолгой.
Ну здесь на самом деле можно долго спорить, т.к., например, что такое красота кода? Где-то недавно пробегала тема про что-то вроде $f = $f & func(); Кому-то это кажется красивым и удобным, кому-то — некрасивым и неудобным. Но в общем, я с Вами все-таки согласен — мне красивый код тоже нравится больше, чем некрасивый, хотя, если он работает — это не так уж важно. =)
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Rumata, Вы писали: R>>Вот только опять не понятно, являются ли приведенные там документы какими-либо стандартами. неужели за более чем 10 лет развития, под ООП не подвели никаких признаных стандартов вообще? S>В каком смысле стандартов? Стандартов математизации? А такие вообще есть? У нас хоть одна область математики оборудована каким-то стандартом? Или физика там? "Комитет ISO постановил пользоваться Гейзенберговским представлением квантовых операторов, так как оно наилучшим образом удовлетворяет потребности всех заинтересованных сторон". Все. Обновляем все учебники со Шредингеровским представлением. Ха-ха-ха. S>Нет, на эту область стандартов нет и не будет. Если достаточное количество народу будет задумываться что и почему они делают, а не как добиться конкретной фичи, то есть шанс сформировать более-менее общепринятую терминологию. Пока что ООП находится примерно в той же стадии исследования, что и экономика — каждый автор свободно использует термины в своем смысле, и зачастую не в одном.
Тут я ну никак не могу с Вами согласиться. Математика строит модели реальной жизни. Раз есть реальная жизнь, будет и модель. Ту же экономику потихоньку описывают с разной точностью. А программирование все-таки чуть более структурированная штука. Из-за того, хотя бы, что в конце концов программа должна работать на машине фон-Неймана, которая очень даже хорошо описана.
А пока, как я понял, даже с терминологией не договорились. =((
Здравствуйте, Аноним, Вы писали:
А>Стандартов нет, но если нужны теории — то изучайте дискретную математику и абстрактную алгебру, а именно: теорию графов, теорию конечных автоматов, мат. лог, алгебру логики, сложность алгоритмов, А>теорию структур, формальные языки, распознавание образов и т.д.
Изучаю. А вот курса ооп у нас вроде как не намечается. Похоже, что нам покажут c++, скажут, что в нем бывают объекты и на этом все закончится =)
Здравствуйте, Rumata, Вы писали:
R>Тут я ну никак не могу с Вами согласиться. Математика строит модели реальной жизни. Раз есть реальная жизнь, будет и модель. Ту же экономику потихоньку описывают с разной точностью.
А программирование тоже в конечном итоге описывает реальную жизнь, как это не парадоксально.
Здравствуйте, mihailik, Вы писали:
M>P.S. Хотя, на сегодняшний день, самым классическим и строгим стандартным языком ООП-программирования можно считать Java. Его всякая научная общественность в институтах массово изучает, и на его основе всякое ООП проходят. Имеются ввиду, конечно, западные институты. Наши пока в программировании не авторитет.
Я бы не был столь категоричен. В джаве очень много моментов не очень хорошо ложащихся в ОО-парадигму. Ну те же примитивные типы к примеру.
Здравствуйте, Rumata, Вы писали:
R>Ну здесь на самом деле можно долго спорить, т.к., например, что такое красота кода?
Лично я считаю красивым код, который легко понять, который не содержит в себе повторяющихся кусков и который решает задачу путями, близкими к оптимальным.
R>Где-то недавно пробегала тема про что-то вроде $f = $f & func(); Кому-то это кажется красивым и удобным, кому-то — некрасивым и неудобным. Но в общем, я с Вами все-таки согласен — мне красивый код тоже нравится больше, чем некрасивый, хотя, если он работает — это не так уж важно. =)
Все таки настаиваю на том что важно. Потмоу что зачастую проще бывает переписать код заново, нежели модифицировать старый.
Здравствуйте, AndrewVK, Вы писали:
AVK>Я бы не был столь категоричен. В джаве очень много моментов не очень хорошо ложащихся в ОО-парадигму. Ну те же примитивные типы к примеру.
Однако в ней есть оболочки для этих типов, никто не мешает использовать только их, вместо int использовать Integer и т.д.
R>... Кто-то решил, что их должно быть 3, т.к. это "следует из инкапсуляции". Но, т.к. понятие самой инкапсуляции, как я понимаю, само четко не сформулировано, следствия из него имхо строить довольно опасно.
Инкапсуляция — это доступность (или сокрытие) того, что имеет объект, для кого-либо, отличного от самого объекта.
Количество состояний доступности определяется тремя словами "никому", "одному" и "всем". Если ты сможешь найти еще слово, которое не выражается из этих трех, то тебе будет слава и почет.
R>А пока, как я понял, даже с терминологией не договорились.
Интересно, есть ли определение точки, множества и т.п. терминов, краеугольные для математики? Которые вроде всем известны и понятны, но тем не менее...
Здравствуйте, Vi2, Вы писали:
Vi2>Количество состояний доступности определяется тремя словами "никому", "одному" и "всем". Если ты сможешь найти еще слово, которое не выражается из этих трех, то тебе будет слава и почет.
Я знаю! "Двум"! Но это избыточно, так как помимо инкапсуляции у нас есть ещё и наследование. вот если инкапсуляция есть, а наследования нет....
Тогда ЛЮБОЙ экземпляр класса В может обращаться к скрытым(приватным) членам любого экземпляра класса А, но ни один из них не наследуется от другого и они не являються потомками одного и того же класса. Пока же мы пишем Get|Set методы. Я неговорю, что это надо, я говорю, что этого нет.
ИМХО не надо, в том смысле что если и надо то редко и не очень.
Здравствуйте, Dmitry123, Вы писали:
AVK>Я бы не был столь категоричен. В джаве очень много моментов не очень хорошо ложащихся в ОО-парадигму. Ну те же примитивные типы к примеру.
D>Однако в ней есть оболочки для этих типов, никто не мешает использовать только их, вместо int использовать Integer и т.д.
Ты сам то использовал? Мне до сих пор иногда в кошмарных снах снится кое какой код из EJB на эту тему.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Dmitry123, Вы писали:
AVK>>Я бы не был столь категоричен. В джаве очень много моментов не очень хорошо ложащихся в ОО-парадигму. Ну те же примитивные типы к примеру.
D>>Однако в ней есть оболочки для этих типов, никто не мешает использовать только их, вместо int использовать Integer и т.д.
AVK>Ты сам то использовал? Мне до сих пор иногда в кошмарных снах снится кое какой код из EJB на эту тему.
В Jave 1.5 будет boxing/unboxing . Правда, только для примитивных типов.
7. О чем невозможно говорить, о том следует молчать.
A>Ну да, представь себе приблизительно такую запись
A>class B;
A>friend B class A;
A>Тогда ЛЮБОЙ экземпляр класса В может обращаться к скрытым(приватным) членам любого экземпляра класса А, но ни один из них не наследуется от другого и они не являються потомками одного и того же класса. Пока же мы пишем Get|Set методы. Я неговорю, что это надо, я говорю, что этого нет.
A>ИМХО не надо, в том смысле что если и надо то редко и не очень.
Сколько ни вчитывался, никак не мог понять тезиса, против которого или за который ты высказываешься.
Тройственная (триединая) картина встречается достаточно часто, чтобы она стала каноном. Триединый бог, Отрицание отрицания и т.п. (Иногда даже — если в теории нет триединства, то считается, что теория ущербна. )
На практике, например, некая Фирма может заключать договор 1) ни с кем, 2) с определенным лицом, 3) с неопределенным лицом (публичный договор).
Здравствуйте, Vi2, Вы писали:
Vi2>На практике, например, некая Фирма может заключать договор 1) ни с кем, 2) с определенным лицом, 3) с неопределенным лицом (публичный договор).
4) С несколькими определёнными лицами.
Например множественное наследование это канон ООП или фича?
R>А пока, как я понял, даже с терминологией не договорились. =((
А как ты себе представляешь такую договорённость? Договорились разработчик Delphi, VB и C++. Постановили переименовать все record в struct, а friend в internal?
Когда люди хотят друг друга понять, они не сомневаются в смысле слов "полиморфизм", "наследование" и т.п. А если поп*%деть на лекции — тогда конечно. Тогда и в математике договорённости плавающие.
Например, чему равен квадратный корень из четырёх? Думаешь двум? Неверно.
Квадратным корнем по строгому определению называется число, чей квадрат равен данному. То есть и два и минус два. А тот значок, который в школе изучают — это арифметический квадратный корень.
Но эта плывучесть определений на практике никого не заботит, так как всё знают, что имеется ввиду в каждом конкретном случае.
R>>Как же тогда понимать такого рода фразы?
S>А так и понимать — человек считает, что он знаком с ООП.
R>Как определить, что человек знаком с ООП, если не известно, что такое ООП?
Как говорили в одном фильме, "а причём здесь Крымов?"
Причём здесь ООП? Представь, что в резюме написано: "знаком с микробиологией". Такая формулировка тебя не коробит?
А между тем понятие микробиологии не менее расплывчато, чем понятие ООП.
AVK> Код это не дом или автомобиль, в процессе своей жизни код непрерывно эволюционирует. И если он написан некрасиво то жизнь такого кода будет тяжелой и недолгой.
Может, это особенности психики, но мне кажется, что пакостный код живёт очень долго. Красивый и логичный так долго не живёт, как какой-нибудь запутанный, глючный и нерегулярный.
Здравствуйте, mihailik, Вы писали:
M>P.S. Хотя, на сегодняшний день, самым классическим и строгим стандартным языком ООП-программирования можно считать Java. Его всякая научная общественность в институтах массово изучает, и на его основе всякое ООП проходят. Имеются ввиду, конечно, западные институты. Наши пока в программировании не авторитет.
Vi2>"Росту ниже среднего и блондинки. Ух, люблю..."
Vi2>
A>>Например множественное наследование это канон ООП или фича?
Vi2>А какое отношение имеет "наследование" к "инкапсуляции"? Это перпенидикулярные термины.
Такое, что отсутствие синтаксической поддержки для, скажем так, выдачи прав доступа нескольким определённым объектам, можно эмулировать за счёт множественного наследования.
Здравствуйте, mihailik, Вы писали:
R>>А пока, как я понял, даже с терминологией не договорились. =(( M>А как ты себе представляешь такую договорённость? Договорились разработчик Delphi, VB и C++. Постановили переименовать все record в struct, а friend в internal?
Например так.
M>Когда люди хотят друг друга понять, они не сомневаются в смысле слов "полиморфизм", "наследование" и т.п. А если поп*%деть на лекции — тогда конечно. Тогда и в математике договорённости плавающие.
Не сомневаются? А у меня после 5-ой книги по пэттернам в OOD осталось совсем другое впечатление. А в математике — некоторые краевые договоренности действительно плавающие (например слово "комплексный" в Питереи Москве математики по разному произносят — ударение на разных слогах), но центральные определения вполне четкие (на то они и определения). Есть еще понятия, но их довольно таки мало.
M>Например, чему равен квадратный корень из четырёх? Думаешь двум? Неверно. M>Квадратным корнем по строгому определению называется число, чей квадрат равен данному. То есть и два и минус два. А тот значок, который в школе изучают — это арифметический квадратный корень.
Вы удивитесь, но мне это известно — в школе проходили =))
M>Но эта плывучесть определений на практике никого не заботит, так как всё знают, что имеется ввиду в каждом конкретном случае.
Ну почему же никого не заботит? В каждой второй книге встречается, что-то вроде "часто под **** понимают ####, но здесь мы юудем иметь в виду @@@@@, т.к. ##### вызывает противоречия там и там".
Здравствуйте, Rumata, Вы писали:
S>>А как предполагается записывать эту самую математическую модель? Уж не на языке ли программирования каком-нибудь? Это я к тому, что программист эту математическую модель сам придумывает.
R>Ну почему же, я вот верю, что математика в конце концов опишет все =)
А при чем здесь опишет/не опишет? Вполне себе описывает, но наиболее удобное описание получается на каком-нибудь из языков программирования. Почти по определению
R>Дело в том, что я сначаала начал пользоваться реляционными бд (в т.ч. и нормальными формами), а потом прочитал теорию, почему нормальные форму лучше, чем ненормальные. С тех пор мне кажется, что за любым "rule of thumb", которое на практике облечает программисту жизнь лежит некоторое математическое обоснование =)
А при чем здесь это?
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, mihailik, Вы писали:
R>>Вот только опять не понятно, являются ли приведенные там документы какими-либо стандартами. неужели за более чем 10 лет развития, под ООП не подвели никаких признаных стандартов вообще?
M>А что, есть какие-то стандарты "реляционности" баз данных?
M>ООП — это архитектура, методология. Она призвана помогать строить программы. Точно так же, как нет стандартов, например, барокко, или готики — так же нет смысла в стандарте ООП.
M>P.S. Хотя, на сегодняшний день, самым классическим и строгим стандартным языком ООП-программирования можно считать Java. Его всякая научная общественность в институтах массово изучает, и на его основе всякое ООП проходят. Имеются ввиду, конечно, западные институты. Наши пока в программировании не авторитет.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ага, в этих случаях приходилось писать десяток перегруженных методов под каждый примитивный тип. Вот только что интерфейсы JDO смотрел.
Хех...ну не знаю, вобщем лично меня эти оболочки особо не напрягают,
поэтому можно их посоветовать идейным борцам за чистое ООП (сам к ним не отношусь ).
Кстати ИМХО спор об ООП все равно никакого результата не даст, да и пользы тоже
Здравствуйте, mihailik, Вы писали:
R>>Ну почему же, я вот верю, что математика в конце концов опишет все =) M>Что всё?
Да вообще все ...
Посмотрите книги Арнольда по нечеткой логике
M>Ты, кажется, математику с физикой перепутал. Математика вообще не занимается реальным миром. В принципе не занимается.
Нет, не перепутал. Математика применяется при моделировании реальной жизни. Физика здесь не при чем.
M>Можно даже так сказать: любая отрасль знаний, опирающаяся на строгую логику, и исследующая абстрактные модели — называется математикой.
Сказать — можно. Не уверен, что это будет правильно.
Здравствуйте, Sergey, Вы писали:
S>>>А как предполагается записывать эту самую математическую модель? Уж не на языке ли программирования каком-нибудь? Это я к тому, что программист эту математическую модель сам придумывает. R>>Ну почему же, я вот верю, что математика в конце концов опишет все =) S>А при чем здесь опишет/не опишет? Вполне себе описывает, но наиболее удобное описание получается на каком-нибудь из языков программирования. Почти по определению
Ну вот, когда она все опишет, описанным окажется и ооп =))
Т.е. будет формальноее определение понятий, обоснование того, что нужны именно public, private, protected и т.д.
S>А при чем здесь это?
Надеялся пояснить свою мысль. По-видимому не получилось =))
Здравствуйте, Sergey, Вы писали:
S>А при чем здесь опишет/не опишет? Вполне себе описывает, но наиболее удобное описание получается на каком-нибудь из языков программирования. Почти по определению
Нда. Формат дискусии и количествво работы не оставляют мне шанса высказать все, что считаю нужным. Потому буду краток. Как правило под формализацией понимают некий набор декларативных утверждений. Большинство современных языков программирования сильно перекошены в сторону процедурности.
R>Дело в том, что я сначаала начал пользоваться реляционными бд (в т.ч. и нормальными формами), а потом прочитал теорию, почему нормальные форму лучше, чем ненормальные. С тех пор мне кажется, что за любым "rule of thumb", которое на практике облечает программисту жизнь лежит некоторое математическое обоснование =)
S>А при чем здесь это?
Именно при том, что без понимания математической сути происходящего невозможно быть хорошим программистом.
А для лучшего понимания сути проблемы, задумайтесь:
С++ — это ООП?
Object Pascal — это ООП?
Java — это ООП?
JScript — это ООП?
COM — это ООП?
SQL — это ООП?
А теперь подумайте, где проходит граница между ООП и неООП, и почему она там проходит, и почему такие непохожие системы сваливают в одну кучу. И как их классифицировать, т.е. кто ближе — С++ к COM или JScript к Java.
... << RSDN@Home 1.0 beta 7a >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Rumata, Вы писали:
R>Тут я ну никак не могу с Вами согласиться. Математика строит модели реальной жизни. Раз есть реальная жизнь, будет и модель. Ту же экономику потихоньку описывают с разной точностью. А программирование все-таки чуть более структурированная штука. Из-за того, хотя бы, что в конце концов программа должна работать на машине фон-Неймана, которая очень даже хорошо описана.
Не можете, но соглашаетесь
Да, меня самого ужасно раздражает, что в большинстве случаев термины типа инкапсуляции объясняют при помощи примеров кода на каком-то языке. И я искренне надеюсь, что эта ситуация исправится.
С другой стороны, в каждой науке есть различные подходы. Да, сейчас математики вроде договорились строить весь анализ на теории множеств. Но совершенно не факт, что это есть единственно возможный подход.
Вот в физике например, что есть момент импульса?
Вариант один: "произведение импульса на плечо, mvr". Это как раз и есть что-то вроде "наследование — это когда после имени класс через двоеточие пишут имя класса-предка....". Непереносимое определение.
Вариант два: "инфинитезимальный оператор поворота". Особый такой векторный дифференциальный оператор. Совсем вроде другая штука. И откуда она такая берется? Куда девалось mvr?
Вариант три: "та величина, сохранение которой следует из изотропности пространства". О! Вот в это определение попадает и тот момент, который изучают в школе (классическая физика), и тот, который изучают в квантовой механике, а также все релятивистские модификации...
Тем не менее все эти определения сосуществуют.
Я думаю, что в ООП в итоге будет также. Типа "Наследование в смысле Руматы — это ........". Или там "полиморфизм в смысле Синклера".
R>А пока, как я понял, даже с терминологией не договорились. =((
Да не в этом даже дело. Ну покажите мне хотя бы пару точных формулировок того, что такое наследование. Чтобы их можно было применить к конкретной ситуации и сказать "да, здесь оно есть" или "нет, здесь его нету". Большинство авторов не затрудняют себя введением сколь бы то ни было точных определений.
Вот когда они начнут это делать, тогда и можно будет говорить к примеру о том, что Буч и Страуструп понимают под наследованием одно и то же, а вот Вирт придает ему несколько иной смысл. И будет о чем договариваться.
... << RSDN@Home 1.0 beta 7a >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Vi2, Вы писали:
Vi2>Интересно, есть ли определение точки, множества и т.п. терминов, краеугольные для математики? Которые вроде всем известны и понятны, но тем не менее...
Насчет точки — не помню. Вот материальная точка в физике вполне четко определена.
А множество вводится как интуитивно понятная категория, без чего невозможно даже начать математику При этом уверенность математиков во взаимопонимани основана на том, что таких "интуитивно понятных" категорий и неявных правил вывода используется весьма небольшое количество. И оно жестко контролируется.
... << RSDN@Home 1.0 beta 7a >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Rumata, Вы писали:
R>Здравствуйте, Аноним, Вы писали:
А>Стандартов нет, но если нужны теории — то изучайте дискретную математику и абстрактную алгебру, а именно: теорию графов, теорию конечных автоматов, мат. лог, алгебру логики, сложность алгоритмов, А>теорию структур, формальные языки, распознавание образов и т.д. R>Изучаю. А вот курса ооп у нас вроде как не намечается. Похоже, что нам покажут c++, скажут, что в нем бывают объекты и на этом все закончится =)
Так и будет. Немножко теории все-таки дадут, но это не будет даже близким по уровню формализма к вышеперечисленным теориям.
... << RSDN@Home 1.0 beta 7a >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Rumata, Вы писали:
R>>Тут я ну никак не могу с Вами согласиться. Математика строит модели реальной жизни. Раз есть реальная жизнь, будет и модель. Ту же экономику потихоньку описывают с разной точностью. А программирование все-таки чуть более структурированная штука. Из-за того, хотя бы, что в конце концов программа должна работать на машине фон-Неймана, которая очень даже хорошо описана. S>Не можете, но соглашаетесь S>Да, меня самого ужасно раздражает, что в большинстве случаев термины типа инкапсуляции объясняют при помощи примеров кода на каком-то языке. И я искренне надеюсь, что эта ситуация исправится.
Формализация это хорошо, однако человек проще понимает формализмы путём аналогий и примеров.
S>С другой стороны, в каждой науке есть различные подходы. Да, сейчас математики вроде договорились строить весь анализ на теории множеств. Но совершенно не факт, что это есть единственно возможный подход. S>Вот в физике например, что есть момент импульса?
Плохой ты выбрал пример.
S>Вариант один: "произведение импульса на плечо, mvr". Это как раз и есть что-то вроде "наследование — это когда после имени класс через двоеточие пишут имя класса-предка....". Непереносимое определение.
Это следствие и всю жизнь об этом честно говорят и ни один физик не скажет, что это определение.
S>Вариант два: "инфинитезимальный оператор поворота". Особый такой векторный дифференциальный оператор. Совсем вроде другая штука. И откуда она такая берется? Куда девалось mvr?
А с другой стороны очень даже и куда. Оно и берётся из этого определения
S>Вариант три: "та величина, сохранение которой следует из изотропности пространства". О! Вот в это определение попадает и тот момент, который изучают в школе (классическая физика), и тот, который изучают в квантовой механике, а также все релятивистские модификации...
Полный эквивалент предыдущего определения.
S>Тем не менее все эти определения сосуществуют.
Ничего подобного, ты пытаешься показать. что эти определения различны, однако вся наука строится на том, что эти определения одинаковы (ну кроме первого), а вот если бы это было не так, тогда и можно было бы говорить о недостаточности теории.
S>Я думаю, что в ООП в итоге будет также. Типа "Наследование в смысле Руматы — это ........". Или там "полиморфизм в смысле Синклера".
Мне кажется, что всё это можно формализовать. Может быть в конечном итоге получится вот так: "Синклер наследованием назвал вот это ..., но он не учитывал вот такие аспекты ..." и т.п.
R>>А пока, как я понял, даже с терминологией не договорились. =(( S>Да не в этом даже дело. Ну покажите мне хотя бы пару точных формулировок того, что такое наследование. Чтобы их можно было применить к конкретной ситуации и сказать "да, здесь оно есть" или "нет, здесь его нету". Большинство авторов не затрудняют себя введением сколь бы то ни было точных определений. S>Вот когда они начнут это делать, тогда и можно будет говорить к примеру о том, что Буч и Страуструп понимают под наследованием одно и то же, а вот Вирт придает ему несколько иной смысл. И будет о чем договариваться.
Есть очень интересная наука методологией зовётся и смысл именно в существовании некоторого общего базиса на котором можно построить новые методы познания (точнее даже определить дорогу к новым познаниям). Этот базис может быть размытым только вначале развития, чем дальше тем всё больше требования формализма к этому базису.
ООП как научный метод получил развитие в масштабах времени не так то и давно, именно поэтому, как мне кажется, он столь неформализованный. Но как я уже сказал, чем дальше тем больше требуется формализма, чтобы построить полную теорию. Вот уже и от нас (программистов) начали поступать справедливые возмущения (хотя это прерогатива теоретиков).
Поэтому как мне кажется формализм со временем появится и может даже кто-то из нас и станет его основателем.
З.Ы. Пример немного не в тему, но очень похоже: в истории физической науки как таковой сейчас стало принято выделять этапы накопления знаний и методов и этапы революционных изменений (для этого этапа очень часто употребляется фраза 'открытие витало в воздухе').
Здравствуйте, <Аноним>, Вы писали:
А>Покрывают. Что еще нужно ?
Все остальное. А>Одних графов достаточно почти для всего, а вкупе с алгеброй и матлогом — даже с избытком.
Ну так можно сказать, что все покрывается одной теорией множеств. Ибо и алгебра, и логика, и анализ вкупе с графами построены поверх нее.
Покажите мне то место графах, в котором что-то говорится об инкапсуляции. Графы в ООП заканчиваются на теореме "любой ориентированный ациклический граф соответствует валидной схеме наследования".
... << RSDN@Home 1.0 beta 7a >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andir, Вы писали:
A>Формализация это хорошо, однако человек проще понимает формализмы путём аналогий и примеров.
Согласен. Но заменить формализм примером нельзя — уж больно неравноценная замена.
A>Плохой ты выбрал пример. A>Ничего подобного, ты пытаешься показать. что эти определения различны, однако вся наука строится на том, что эти определения одинаковы (ну кроме первого), а вот если бы это было не так, тогда и можно было бы говорить о недостаточности теории.
Ок, ладно, черт с ним с моментом. Вообще говоря, тот факт, что некие определения эквивалентны, вовсе не является очевидным. В данном случае имеем два эквивалентных и одно неэквивалентное определения.
S>Я думаю, что в ООП в итоге будет также. Типа "Наследование в смысле Руматы — это ........". Или там "полиморфизм в смысле Синклера". A>Мне кажется, что всё это можно формализовать. Может быть в конечном итоге получится вот так: "Синклер наследованием назвал вот это ..., но он не учитывал вот такие аспекты ..." и т.п.
A>Есть очень интересная наука методологией зовётся и смысл именно в существовании некоторого общего базиса на котором можно построить новые методы познания (точнее даже определить дорогу к новым познаниям). Этот базис может быть размытым только вначале развития, чем дальше тем всё больше требования формализма к этому базису. A>ООП как научный метод получил развитие в масштабах времени не так то и давно, именно поэтому, как мне кажется, он столь неформализованный. Но как я уже сказал, чем дальше тем больше требуется формализма, чтобы построить полную теорию. Вот уже и от нас (программистов) начали поступать справедливые возмущения (хотя это прерогатива теоретиков). A>Поэтому как мне кажется формализм со временем появится и может даже кто-то из нас и станет его основателем.
Конечно появится. Но их будет много разных. Потом, возможно, будет доказана эквивалентность различных подходов, как это было с Гейзенбергом vs Шредингер.
Я очень сильно сомневаюсь, что какой-то один подход будет принят в качестве единственно правильного. Это все к вопросу о "стандартах".
... << RSDN@Home 1.0 beta 7a >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Rumata, Вы писали:
M>>Когда люди хотят друг друга понять, они не сомневаются в смысле слов "полиморфизм", "наследование" и т.п. А если поп*%деть на лекции — тогда конечно. Тогда и в математике договорённости плавающие. R>Не сомневаются? А у меня после 5-ой книги по пэттернам в OOD осталось совсем другое впечатление. А в математике — некоторые краевые договоренности действительно плавающие (например слово "комплексный" в Питереи Москве математики по разному произносят — ударение на разных слогах), но центральные определения вполне четкие (на то они и определения). Есть еще понятия, но их довольно таки мало.
Аксиомы в математике? Различные геометрические пространства которые казалось бы должны друг ддругу противоречить, а на самом деле дополняют?
M>P.S. Хотя, на сегодняшний день, самым классическим и строгим стандартным языком ООП-программирования можно считать Java.
AVK>Я бы не был столь категоричен. В джаве очень много моментов не очень хорошо ложащихся в ОО-парадигму. Ну те же примитивные типы к примеру.
Но всё-таки если выбирать самый классический язык ООП, то, уверен, победит Java.
M>P.S. Хотя, на сегодняшний день, самым классическим и строгим стандартным языком ООП-программирования можно считать Java.
L>Все верно. Но только не java, а smalltalk.
Vi2>Интересно, есть ли определение точки, множества и т.п. терминов, краеугольные для математики? Которые вроде всем известны и понятны, но тем не менее...
S>Насчет точки — не помню. Вот материальная точка в физике вполне четко определена.
Всю геометрию можно вывести через координатный метод из арфметики. А арифметика выводится их логики и теории множеств.
Мало того, геометрия, как и все некорневые дисциплины может быть задана ещё хитрее, через определение.
Точкой, прямой, плоскостью называются объекты, для которых верны аксиомы геометрии.
То есть аксиомы геометрии на сегодняшнем уровне уже не являются аксиомами, это просто определения. И дело не только в Лобачевском.
S>А множество вводится как интуитивно понятная категория, без чего невозможно даже начать математику При этом уверенность математиков во взаимопонимани основана на том, что таких "интуитивно понятных" категорий и неявных правил вывода используется весьма небольшое количество. И оно жестко контролируется.
Строгая теория множеств и строгая логика очень связаны между собой. Если удастся каким-нибудь акробатическим трюком задать логику, то, скорее всего, теория множеств будет тут же неподалёку.
Что такое, например, определение, как не задание множества объектов? И что такое задание множества объектов как не определение?
R>>Ну почему же, я вот верю, что математика в конце концов опишет все =)
M>Что всё?
R>Да вообще все... R>Посмотрите книги Арнольда по нечеткой логике
Я бы посмотрел, но поблизости нету. Может сам в двух словах прояснишь?
M>Ты, кажется, математику с физикой перепутал. Математика вообще не занимается реальным миром. В принципе не занимается.
R>Нет, не перепутал. Математика применяется при моделировании реальной жизни. Физика здесь не при чем.
Математика может применяться для всего чего угодно. Для самоутверждения, например. Но цель её не в моделировании какой-то там реальной жизни, которая вообще неизвестно существует ли.
Есть много областей математики, которые никто не собирался применять к реальной жизни. Лобачевский, например, геометрию свою придумал не для реальной жизни. Да она ему в реальной жизни не очень-то и помогла. А то, что потом эту идею развили разные другие люди, а Эйнштейн приспособил какие-то результаты — так это просто сопутствующие последующие факты. Сама математика живёт без причинной связи с реальным миром.
M>Можно даже так сказать: любая отрасль знаний, опирающаяся на строгую логику, и исследующая абстрактные модели — называется математикой.
R>Сказать — можно. Не уверен, что это будет правильно.
Здравствуйте, mihailik, Вы писали:
R>>Посмотрите книги Арнольда по нечеткой логике M>Я бы посмотрел, но поблизости нету. Может сам в двух словах прояснишь?
К сожалению, под рукой и у меня не оказалось. Может быть чуть позже найду. Там очень красочные примеры применения математики в необычных на первый взгляд областях.
M>Есть много областей математики, которые никто не собирался применять к реальной жизни. Лобачевский, например, геометрию свою придумал не для реальной жизни. Да она ему в реальной жизни не очень-то и помогла. А то, что потом эту идею развили разные другие люди, а Эйнштейн приспособил какие-то результаты — так это просто сопутствующие последующие факты. Сама математика живёт без причинной связи с реальным миром.
Согласен. Но есть одно но: существующие математические теории описывают больше, чем возможно в реальной жизни. Бывает и такое, что красивое математическое построение оказывается никому не нужным, т.к. таких объектов, на которых все рассматривается попросту не существует. Однако из этого множства теорий выделяли, выделяют и будут выделять те, которые, иногда неожидано, как в случае с теорией относительности, "ложаться" на реальный мир.
M>>Можно даже так сказать: любая отрасль знаний, опирающаяся на строгую логику, и исследующая абстрактные модели — называется математикой. R>>Сказать — можно. Не уверен, что это будет правильно. M>Найди лучшее определение, или опровергни это.
Нда, забавно, я понимал, что определение это проблема, но чтобы такая =))
Имхо самое удачное определение это "математика — это то, что написано в книгах по математике" =))
А вообще-то, в Вашем определение слишком много темных мест, чтобы его можно было считать определением =) ну, например, что такое "отась знаний", причем здесь "строгая логика" (В.И.Арнольд, как раз занимался нечеткой логикой =)) н и далее, по тексту =))
M>Есть много областей математики, которые никто не собирался применять к реальной жизни.
R> Бывает и такое, что красивое математическое построение оказывается никому не нужным, т.к. таких объектов, на которых все рассматривается попросту не существует.
Красивое математическое построение может быть "никому не нужным" с внешней стороны. Но внутри математики, слава богу, это не самое главное. Это я и пытаюсь доказать: математика не имеет внешних причин, вроде описания реальности. Разве что гранты на реалистичные исследования могут различаться. Но не всегда.
R> Однако из этого множства теорий выделяли, выделяют и будут выделять те, которые, иногда неожидано, как в случае с теорией относительности, "ложаться" на реальный мир.
Контрпример: тараканы выделяют литературу, напечатанную натуральными красками, а синтетические не жалуют. Но сама литература на эти внешние тараканьих оценки особо не смотрит.
M>>Можно даже так сказать: любая отрасль знаний, опирающаяся на строгую логику, и исследующая абстрактные модели — называется математикой. R>>Сказать — можно. Не уверен, что это будет правильно. M>Найди лучшее определение, или опровергни это.
R>Нда, забавно, я понимал, что определение это проблема, но чтобы такая =))
Здесь нужно просто уяснить, что ты имеешь ввиду, когда говоришь "математика". Действенный метод для таких общих понятий.
R>Имхо самое удачное определение это "математика — это то, что написано в книгах по математике" =))
Не рублю соль в этом определении. Если состязаться с такими перлами, то я бы сказал, "математика — это гнилой сыр".
R>А вообще-то, в Вашем определение слишком много темных мест, чтобы его можно было считать определением =) ну, например, что такое "отась знаний", причем здесь "строгая логика" (В.И.Арнольд, как раз занимался нечеткой логикой =)) н и далее, по тексту =))
Конечно, смутность есть. Но она не мешает, определение-то работает.
Определение должно быть адекватным определяемому понятию. И должно показывать, что можно называть определяемым словом, а что нет. Моё определение, кажется, вполне соотвествует. Приложи к нему любой предмет — и оно покажет, является ли предмет математикой или нет.
> Но всё-таки если выбирать самый классический язык ООП, то, уверен, победит Java.
TK>а чем eiffel не нравится? TK>а java, ihmo это это больше академический язык.
Именно-именно! Eiffel годится, но если искать чего-то классического, академического, остаётся наш основной кандидат.
... они говорят: "На что оно похоже — то, что ты видел? И он пытается рассказать им. Быть может, он видел самый первый в мире огонь. Он говорит им: "Он красен, как мак, но пляшут в нём и иные цвета. У него нет формы, как у воды, он текуч. Он тёплый, как летнее солнце, даже теплее. Он существует какое-то время на куске дерева — и дерево исчезает, будто съеденное, остаётся что-то чёрное, сыпучее, как песок. И он исчезает вместе с деревом." И вот слушатели вынуждены думать, что реальность эта схожа с маком, с водой, с солнцем, с тем, что ест и испражняется. Они думают, что она, эта реальность, схожа со всем, чему она подобна по словам познавшего её. Но вот огонь снова и снова появляется в этом мире. Всё новые и новые люди видят его. И спустя какое-то время огонь становится так привычен, как трава, облака, как воздух, которым они дышат. И они видят, что хотя и похож он на мак, это не мак, хотя и похож на воду, не вода, хотя похож на солнце, но не солнце, хотя похож на того, кто ест и испражняется, всё же это не тот, кто ест и испражняется, но нечто отличное от каждого из этих предметов или ото всех их разом. Так что смотрят они на эту новую суть и изобретают новое слово, чтобы назвать её. Они зовут её "огонь".
— Если же случится им вдруг встретить человека, который ещё не видел огня, и они скажут ему о нём, не поймёт он, что же они имеют в виду. И опять им, в свою очередь, придётся говорить ему, на что похож огонь. Но при этом они знают по собственному опыту, что говорят они ему не истину, а только часть истины. Они знают, что человек этот никогда не познает с их слов реальность, хотя и могут они использовать все слова на свете. Он должен взглянуть на огонь, ощутить его запах, согреть у него руки, всмотреться в его сердце — или остаться навеки неведающим.
Р. Желязны, Князь Света
Сдаётся мне, что Rumat'е может помочь в ответе на этот вопрос только собственный опыт, т.к. опыт лучший друг программиста (и злейший враг его также).
А так ли много потеряно?
Как-то не убеждают меня приведенные аргументы, что мы идем неверным путем. Сейчас я попробую каждый из них прокомментировать. Я не настаиваю на своей точке зрения — напротив, очень хотелось, чтобы, если я чего-то не вижу, мне это объяснили. Поскольку я совершенно не разбираюсь, в частности, в SmallTalk и мое мнение о нем основано на той самой статье, на которую ссылается _vovin.
Итак, концепция ООП чудовищно изуродована и сужена? То есть многое, что легко и красиво можно реализовать при изначальной трактовке ООП, становится сложным и запутанным, а подчас и невозможным?
Сразу оговорюсь,
_>Но это является пагубным упрощением, которое практически сводит на нет всю идею объектного подхода. Где главным выигрышем является возможность непосредственного манипулирования динамическим миром объектов посредством гибкой операции посылки сообщения, минуя привычную чрезмерную серию трансформаций текст->код->запуск->взаимодействие->результаты->текст->...
Не понимаю...
Во-первых, откуда хвост "результаты->текст->..."? Что это за процесс описывается, создание программы, что ли?
Во-вторых, как переход от концепции вызова метода к концепции посылки сообщения позволит обойтись без текста, или кода, или взаимодействия? Ну ладно еще без запуска — при определенной организации создаваемого кода его может быть просто не нужно как-то особо запускать...
А насчет описанного в предлагаемой статье примера процесса разработки можно сказать: такой подход отличается от обычного лишь тем, что окна отладчика все время висят на экране. Все равно в какие-то моменты времени программист ими пользуется, а в другие — пишет код и реализует методы, и вот тогда ему отладчик совершенно не нужен. Иногда, конечно, нужен (ради того самого контекста выполнения) — но ведь для редактирования кода не обязательно выходить из режима отладки, можно продолжать любоваться контекстом.
_>Кое-что на эту тему можно прочитать здесь.
Стало жутко интересно, прочитал. Не убедили
Однородность языка — это приятно, но нельзя из нее делать кумира. Она полезна лишь когда упрощает разработку программ на этом языке. В остальных случаях она значима только для научных изысканий, которые, быть может, и приведут в итоге к революции в программировании, но при этом не имеют ничего общего с повседневными решаемыми задачами.
такие языки называются prototype-based; в них создание новых типов объектов осуществляется посредством клонирования имеющихся и внесения изменений непосредственно в структуру нового объекта
То есть я в ответ на некое сообщение могу взять какой-то прототип, сделать с него копию и выкусить из копии пару полей или реакций на события? А какая мне от этого польза, ведь объекты, сконструированные на базе такого прототипа, не будут целостными? Ну, в плане добавления полей и реакций все вроде бы понятно. Непонятно только, зачем это делать при эксплуатации разработанной программы? Ведь возможные генерируемые таким образом прототипы все равно должны быть учтены при проектировании, а тогда их, вероятно, лучше описать заранее, чтобы не осложнять понимание программы? Иначе говоря, я опять же не вижу реальных преимуществ по сравнению, скажем, с Delphi и тем более с C# (C++ в расчет не беру только потому, что в языке отсутствует возможность конструирования объектов, класс которых на этапе компиляции неизвестен).
родительские слоты могут быть изменяемыми, т.е. поддерживается динамическое множественное наследование
Автор-то понимает, о чем сказал, а мне как быть? Что это означает и какие возможности открывает?
Мне пока пришло на ум только одно потенциальное преимущество: можно использовать в своих откомпилированных разработках сторонние классы, неизвестные на момент компиляции. Хотя хранение метаданных часто само по себе позволяет решить эту задачу, даже в рамках "суженной" концепции ООП.
Наконец, объясните мне, почему концепция вызова метода не может быть очень легко расширена до концепции посылки сообщения? В примитиве это вполне возможно даже в C, вспомним WinAPI SendMessage Если же сопроводить сообщение метаданными, описывающими передаваемую информацию и т.п., то разве концепции вызова метода будет недостаточно для воспроизведения операции посылки сообщения? Я не знаю, может быть, и нет.... Тогда, пожалуйста, объясните, в чем я ошибаюсь.
Теперь про скорость.
Тот факт, что одни типы вызовов в статически типизированных языках выполняются значительно медленнее других, объявляется автором статьи недостатком этих языков. Довольно странно — я бы сказал, хорошо, что некоторые менее общие типы вызовов выполняются быстрее, чем более общие. Вряд ли можно назвать достоинством подхода его единообразно медленную работу на всех операциях.
Врочем, далее автор опровергает мою сентенцию о единообразно медленной работе. Обратимся в слух:
Заметим, что посылка сообщения реализуется в динамических языках реализуется исключительно эффективно. По скорости она незначительно медленнее статического вызова. И, естественно, намного эффективнее виртуального вызова. (1)
Неплохо! Но в то же время:
Чем же таким особым обладает операция посылки сообщения (message passing), по сравнению с обычным вызовом метода (method invocation), который применяется в статически-типизированных языках?
Для начала, стоит разобрать из каких этапов состоят эти две операции.
И то, и другое имеет два основных этапа: поиск метода (method lookup) и собственно вызов метода (method invocation).
Откуда видно, что все метод равно нужно искать. Виртуальный вызов метода требует всего одного дополнительного обращения к памяти по ср. со статическим. Что в таком случае может быть медленнее статического вызова, но значительно быстрее виртуального (1)?
Кроме того, далее говорится о том, что в результате покупки динамического компилятора и его адаптации для Java удалось значительно ускорить работу Java-приложений. Вывод: Java-приложения работали медленно отнюдь не из-за ущербности Java по сравнению со Smalltalk или, в частности, из-за преимущества технологии посылки сообщений перед вызовом методов, а из-за меньшей эффективности компилятора и среды выполнения.
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, mihailik, Вы писали:
M>А что, есть какие-то стандарты "реляционности" баз данных?
Насчёт стандартов не знаю, но базис есть. Называется теорией множеств.
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>(C++ в расчет не беру только потому, что в языке отсутствует возможность конструирования объектов, класс которых на этапе компиляции неизвестен).
А ты случайно не забыл про абстрактные фабрики? Ну да ни чего... я напомню...
В прочем это оффтоп в данной теме.
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Rumata, Вы писали:
R>Вот например, всем известно, что бывают у объектов эл-ты public, private и protected. А почему только 3? Почему нет какого-нибудь четвертого?
Четвертое как правило есть А часто бывает еще и пятое, и шестое
Вот бука! Андрей, так это ж не в языке В языке присутствует возможность дать пользователю это сделать, но сам язык ничего не знает об абстракных фабриках.
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>А так ли много потеряно? SM>Как-то не убеждают меня приведенные аргументы, что мы идем неверным путем. Сейчас я попробую каждый из них прокомментировать. Я не настаиваю на своей точке зрения — напротив, очень хотелось, чтобы, если я чего-то не вижу, мне это объяснили. Поскольку я совершенно не разбираюсь, в частности, в SmallTalk и мое мнение о нем основано на той самой статье, на которую ссылается _vovin.
SM>Итак, концепция ООП чудовищно изуродована и сужена? То есть многое, что легко и красиво можно реализовать при изначальной трактовке ООП, становится сложным и запутанным, а подчас и невозможным? SM>Сразу оговорюсь,
_>>Но это является пагубным упрощением, которое практически сводит на нет всю идею объектного подхода. Где главным выигрышем является возможность непосредственного манипулирования динамическим миром объектов посредством гибкой операции посылки сообщения, минуя привычную чрезмерную серию трансформаций текст->код->запуск->взаимодействие->результаты->текст->... SM>Не понимаю... SM>Во-первых, откуда хвост "результаты->текст->..."? Что это за процесс описывается, создание программы, что ли?
Именно так. Еще не придумано хороших математических методов описания задачи, когда исходный код можно создать сразу и правильно. Либо приходится дизайнить приложения, потом вбивать код, а потом hack until it works. Либо идти путем постеменного наращивания функциональности с контролем корректности на каждом шаге.
В любом случае получается эволюционный замкнутый процесс от требований к тестированию и так до бесконечности.
Поэтому вот этот микро-цикл разработки является критичным (вспоминаю как мне приходится по десять минут перегрузать жававский веб-сервер ради малюсенького изменения). Объектный подход позволяет этот цикл сделать минимальным из возможных. Ты по ходу добавляешь код или корректируешь состояние объект чтобы увидеть как дальше оно работает.
SM>Во-вторых, как переход от концепции вызова метода к концепции посылки сообщения позволит обойтись без текста, или кода, или взаимодействия? Ну ладно еще без запуска — при определенной организации создаваемого кода его может быть просто не нужно как-то особо запускать...
Текст остается. Просто текст является носителем информации, которую ты хочешь передать в объектый мир посредством специализированных объектов — браузеров, рабочих областей и т.д.
Но суть посылки сообщения немного не в этом. Эта достаточно общая операция, которая позволяет создавать систему с рекурсивным дизайном, т.е. ту, в которой даже малые ее части могут обладать теми же возможностями, что и система в целом.
Для примера — сообщение можно послать и числу, и вызовется соответветствующий метод. Или можно модифицировать посылку сообщений для объекта так, что они будут упаковываться и передаваться по сети. Таким образом мы получаем SOA, которая сейчас так рекламируется как замена ООП (а технически SOA оказалось всего лишь специализированной реализацией посылки сообщения — всего лишь одна треть ООП ).
SM>А насчет описанного в предлагаемой статье примера процесса разработки можно сказать: такой подход отличается от обычного лишь тем, что окна отладчика все время висят на экране. Все равно в какие-то моменты времени программист ими пользуется, а в другие — пишет код и реализует методы, и вот тогда ему отладчик совершенно не нужен. Иногда, конечно, нужен (ради того самого контекста выполнения) — но ведь для редактирования кода не обязательно выходить из режима отладки, можно продолжать любоваться контекстом.
В общем так получается, что в отладке разработка половину времени проходит, когда-то больше, когда-то меньше. Это больше, чем компиляция. Кроме того, что только что вбитая строчка сразу же выполнилась, соответственно ошибки типов вылазят сразу, так еще и корректность легко контролируется. Вот от этого отказаться трудно. Разве что разработка в стиле TDD снижает степень утраты.
_>>Кое-что на эту тему можно прочитать здесь. SM>Стало жутко интересно, прочитал. Не убедили
SM>Однородность языка — это приятно, но нельзя из нее делать кумира. Она полезна лишь когда упрощает разработку программ на этом языке. В остальных случаях она значима только для научных изысканий, которые, быть может, и приведут в итоге к революции в программировании, но при этом не имеют ничего общего с повседневными решаемыми задачами.
Однородность и предсказуемость решает. Она очень и очень упрощает разработку. Это не стоит игнорировать особенно учитывая человеческое 7+-2.
Сколько человеко-дней было потрачено каждый разработчиком .NET для изучения C#/VB, базовой библиотеки и сопутствующих технологий? А сколько новых возможностей появляется, на которые опять нужно тратить ценные человеко-дни.
И это при том, что в Smalltalk с его неограниченными возможностями (объекты могут все и все является объектом — значит возможно все) на изучения языка уходит день, на стандартную библиотеку по ходу работы пару месяцев. И все — дальше ты начинаешь решать только насущные задачи, а сам язык не замечается абсолютно. Все очень прозрачно — вот мои классы и объекты, вот их сообщения. И то и другое хорошо ложится на проблемную область как участники системы и взаимодействие между ними.
Когда переходишь на Java, сразу чувствуется как наваливается множество ограничений, сильно снижающих продуктивность:
1. Почему new это какое-то ключевое слово, а не простой метод, и с ним ничего сделать нельзя?
2. Почему классы это не объекты, методы static нельзя переопределить и у них нет this?
3. Почему миллион в квадрате это полная билиберда?
4. Почему везде final?
5. Почему мне навязывают checked exceptions?
6. Почему во время отладки я не могу создать пару новых методов и подправить определение класса?
7. Почему обычный веб-сервер не может нормально работать 24x7 и его нельзя патчить на лету?
И так до бесконечности...
SM>
такие языки называются prototype-based; в них создание новых типов объектов осуществляется посредством клонирования имеющихся и внесения изменений непосредственно в структуру нового объекта
SM>То есть я в ответ на некое сообщение могу взять какой-то прототип, сделать с него копию и выкусить из копии пару полей или реакций на события? А какая мне от этого польза, ведь объекты, сконструированные на базе такого прототипа, не будут целостными? Ну, в плане добавления полей и реакций все вроде бы понятно. Непонятно только, зачем это делать при эксплуатации разработанной программы? Ведь возможные генерируемые таким образом прототипы все равно должны быть учтены при проектировании, а тогда их, вероятно, лучше описать заранее, чтобы не осложнять понимание программы? Иначе говоря, я опять же не вижу реальных преимуществ по сравнению, скажем, с Delphi и тем более с C# (C++ в расчет не беру только потому, что в языке отсутствует возможность конструирования объектов, класс которых на этапе компиляции неизвестен).
Ты конечно можешь выкусывать, но это не есть цель прототипов. Их цель исключить дуальный подход объект-класс, из-за которого в Smalltalk имеется нетривиальная структура объект-класс-метакласс и иерархии у них достаточно витиевато устроены.
При наличии прототипов создание новых экземпляров осуществляется сообщением copy, посланным прототипу (в случае с классами это сообщение new, посланное классу). Чтобы создать новый тип объектов, нужно взять какой-то прототип за основу, клонировать его, внести необходимые изменения и назвать его новым прототипом.
Таким образом объектная система упрощается, остаются только объекты, слоты и сообщения.
SM>
родительские слоты могут быть изменяемыми, т.е. поддерживается динамическое множественное наследование
Автор-то понимает, о чем сказал, а мне как быть? Что это означает и какие возможности открывает?
Упрощенно говоря — у каждого отдельно взятого объекта ты можешь менять его предков.
SM>Мне пока пришло на ум только одно потенциальное преимущество: можно использовать в своих откомпилированных разработках сторонние классы, неизвестные на момент компиляции. Хотя хранение метаданных часто само по себе позволяет решить эту задачу, даже в рамках "суженной" концепции ООП.
Не думаю, что это хорошо. Как раз выгоднее менять предков с заранее известным поведением. Таким образом легко реализуется паттерн State.
Т.е. если у нас есть объект Socket и у него состояния closed/connected/reading, тогда при смене состояния можно менять предка на SocketClosed/SocketConnected/SocketReading соответственно, который будет соответствующим образом обрабатывать все вызовы.
SM>Наконец, объясните мне, почему концепция вызова метода не может быть очень легко расширена до концепции посылки сообщения? В примитиве это вполне возможно даже в C, вспомним WinAPI SendMessage Если же сопроводить сообщение метаданными, описывающими передаваемую информацию и т.п., то разве концепции вызова метода будет недостаточно для воспроизведения операции посылки сообщения? Я не знаю, может быть, и нет.... Тогда, пожалуйста, объясните, в чем я ошибаюсь.
А по-твоему откуда SendMessage взялось?
Для наводки — message sending это концепция из Smalltalk, первый графический интерфейс создавался в Smalltalk и под него библиотека MVC, для элементов интерфейса была взята та же объектая метафора объектов и сообщений (каждый элемент представляется объектом, они обмениваются сообщениями)... Ход мысли понятен?
Посылка сообщения от вызова метода отличается двумя существенными моментами:
1. Любое сообщение можно послать любому объекту
2. Объект сам решает как ему обработать сообщение
Первое в Smalltalk выполняется автоматически, второе обеспечивается с помощью механизма #doesNotUnderstand:.
В принципе возможно приблизить по возможностям вызов метода к посылке сообщения. Что мы и видим в .NET на примере ContextBoundObject или RealProxy.
Но тут же возникает множество ограничений как раз связанных с крайней неоднородностью платформы. Т.е. все реализовано в виде каких-то специализированных случаев и использовать это не так то легко. А если что-то трудно использовать, то можно сказать, что этой возможности и нет. Мы же говорим не о принципиальной возможности что-то сделать, а о влиянии этой возможности на продуктивность.
Иначе всегда была бы актуальна фраза "да все это на ассемблере можно реализовать"...
SM>
SM>Теперь про скорость.
SM>Тот факт, что одни типы вызовов в статически типизированных языках выполняются значительно медленнее других, объявляется автором статьи недостатком этих языков. Довольно странно — я бы сказал, хорошо, что некоторые менее общие типы вызовов выполняются быстрее, чем более общие. Вряд ли можно назвать достоинством подхода его единообразно медленную работу на всех операциях.
Единообразно достаточно быструю.
Наличие быстрых, но тривиальных и медленных, но продвинутых возможностей волей-неволей подвигает людей отказывать от продвинутых в пользу быстрых.
Вот так и рождаются идеи типа "не используйте виртуальные методы, потому что они медленные"! И это говорят люди, пишущие приложения для баз данных. В домохозяйки — однозначно!
А если все — и продвинутые и простые операции не сильно отличаются по скорости, то даже и вопроса не возникает что использовать. Я ни разу не испытывал сомнений, если нужно было задействовать рефлекшн. Во-первых, потому что в Smalltalk он раз в сто быстрее, чем в Java, и к тому же профайлер не покажет там никакого узкого места, если там всего пару сотен вызовов.
SM>Врочем, далее автор опровергает мою сентенцию о единообразно медленной работе. Обратимся в слух:
SM>
Заметим, что посылка сообщения реализуется в динамических языках реализуется исключительно эффективно. По скорости она незначительно медленнее статического вызова. И, естественно, намного эффективнее виртуального вызова. (1)
Неплохо! Но в то же время: SM>
SM>Чем же таким особым обладает операция посылки сообщения (message passing), по сравнению с обычным вызовом метода (method invocation), который применяется в статически-типизированных языках?
SM>Для начала, стоит разобрать из каких этапов состоят эти две операции.
SM>И то, и другое имеет два основных этапа: поиск метода (method lookup) и собственно вызов метода (method invocation).
SM>Откуда видно, что все метод равно нужно искать. Виртуальный вызов метода требует всего одного дополнительного обращения к памяти по ср. со статическим. Что в таком случае может быть медленнее статического вызова, но значительно быстрее виртуального (1)?
Хитрость в кэшировании.
Смотри http://www.smalltalk.ru/articles/cpp-is-faster.html
SM>Кроме того, далее говорится о том, что в результате покупки динамического компилятора и его адаптации для Java удалось значительно ускорить работу Java-приложений. Вывод: Java-приложения работали медленно отнюдь не из-за ущербности Java по сравнению со Smalltalk или, в частности, из-за преимущества технологии посылки сообщений перед вызовом методов, а из-за меньшей эффективности компилятора и среды выполнения.
Правильно, дело не в этом. Дело в культуре разработки, которая прививается тем или иным подходом.
Smalltalk ориентируется на человека и его задачи, Java ориентируется на машину.
Поэтому полезные с точки зрения разработчика тяжелые операции — полиморфизм и рефлексия — получили высокий приоритет и были уравнены в правах с арифметическими операциями. Благодаря этому подходу и был создан "умный" компилятор, который хорошо управляется с полиморфными вызовами.
А в Java как всегда был сделан упор на тривиальные арифметические операции, а виртуальные вызовы реализованы классически по-тупому через таблицы методов и косвенные вызовы. Что на современных процессорах является ох какой дорогой операцией (но они тут умудряются "мухлевать" и запоминают несколько последних вызовах, но если вызовов с десяток, тут все и проседает).
SM>Slicer
_>Поэтому вот этот микро-цикл разработки является критичным (вспоминаю как мне приходится по десять минут перегрузать жававский веб-сервер ради малюсенького изменения). Объектный подход позволяет этот цикл сделать минимальным из возможных. Ты по ходу добавляешь код или корректируешь состояние объект чтобы увидеть как дальше оно работает.
Хм. В предположении, что на SmallTalk можно написать веб-сервер: при его отладке не понадобиться компилировать его заново для учета внесенных изменений?
_>Для примера — сообщение можно послать и числу, и вызовется соответветствующий метод. Или можно модифицировать посылку сообщений для объекта так, что они будут упаковываться и передаваться по сети. Таким образом мы получаем SOA, которая сейчас так рекламируется как замена ООП (а технически SOA оказалось всего лишь специализированной реализацией посылки сообщения — всего лишь одна треть ООП ).
Странно. В результате сегодняшнего обмена письмами с Ричардом Тёрнером у меня сложилось немного другое впечатление. А именно, что SOA не является заменой ООП, а лишь дополняет его в области, в которой требуется учет некоторых вещей, которые в чистом ООП не учтены. Впрочем, это к делу не относится, а относится вот что: ни пример с числом, ни пример с сетью не показывает, чем же посылка сообщения в корне отличается от вызова метода, и почему она выходит за рамки ООП в его обычном, не Алленовском понимании.
_>Однородность и предсказуемость решает. Она очень и очень упрощает разработку. Это не стоит игнорировать особенно учитывая человеческое 7+-2. _>Сколько человеко-дней было потрачено каждый разработчиком .NET для изучения C#/VB, базовой библиотеки и сопутствующих технологий? А сколько новых возможностей появляется, на которые опять нужно тратить ценные человеко-дни.
... _>Когда переходишь на Java, сразу чувствуется как наваливается множество ограничений, сильно снижающих продуктивность: _>1. Почему new это какое-то ключевое слово, а не простой метод, и с ним ничего сделать нельзя? _>2. Почему классы это не объекты, методы static нельзя переопределить и у них нет this? _>3. Почему миллион в квадрате это полная билиберда? _>4. Почему везде final? _>5. Почему мне навязывают checked exceptions? _>6. Почему во время отладки я не могу создать пару новых методов и подправить определение класса? _>7. Почему обычный веб-сервер не может нормально работать 24x7 и его нельзя патчить на лету? _>И так до бесконечности...
Ты же не хуже меня понимаешь, что почти все эти ограничения чем-то обоснованы: соображениями надежности программирования, или производительности, или и т.д. С ними можно соглашаться или не соглашаться, но они обоснованны. Кроме, разве что, того, что классы не являются полноценными объектами и нет метаклассов. И, честно говоря, я не вижу, как это может действительно снизить продуктивность работы. Впрочем, возможно, мне стоит попробовать пописать на SmallTalk
Но основная идея моего постинга заключалась не в защите Java или охаивании SmallTalk, а в том, что я не вижу, 1) почему подход SmallTalk не вписывается в "узкое" ООП, и 2) почему "узкое" ООП менее общо, чем подход SmallTalk.
А приведенные выше ограничения являются ограничениями языка, а не ООП.
_>Ты конечно можешь выкусывать, но это не есть цель прототипов. Их цель исключить дуальный подход объект-класс, из-за которого в Smalltalk имеется нетривиальная структура объект-класс-метакласс и иерархии у них достаточно витиевато устроены. _>При наличии прототипов создание новых экземпляров осуществляется сообщением copy, посланным прототипу (в случае с классами это сообщение new, посланное классу). Чтобы создать новый тип объектов, нужно взять какой-то прототип за основу, клонировать его, внести необходимые изменения и назвать его новым прототипом. _>Таким образом объектная система упрощается, остаются только объекты, слоты и сообщения.
То есть это не дает новых практически применимых возможностей, а лишь опять же служит унификации работы с различными сущностями языка, что предположительно (не спорю, может, это и так!) сильно повысит эффективность программирования. Я правильно понимаю?
_>Упрощенно говоря — у каждого отдельно взятого объекта ты можешь менять его предков.
Ясно. Но, как мне кажется, такая схема ничуть не лучше простого агрегирования Хотя... в отличие от агрегирования в "классических" языках, при этом сохраняется полиморфизм относительно типов-предков, так? Может, и применимо в некоторых случаях — так сразу ничего не приходит в голову.
_>Т.е. если у нас есть объект Socket и у него состояния closed/connected/reading, тогда при смене состояния можно менять предка на SocketClosed/SocketConnected/SocketReading соответственно, который будет соответствующим образом обрабатывать все вызовы.
Ну, тут вполне можно обойтись агрегированием обобщенного SocketImpl в класс-фасад Socket, а от SocketImpl отнаследовать SocketClosed/SocketConnected/SocketReading... Кстати, если я изменю предка с SocketClosed (фактически, пустышки) на SocketReading — состояние новоявленного предка мне придется инициализировать вручную?
_>А по-твоему откуда SendMessage взялось? _>Для наводки — message sending это концепция из Smalltalk, первый графический интерфейс создавался в Smalltalk и под него библиотека MVC, для элементов интерфейса была взята та же объектая метафора объектов и сообщений (каждый элемент представляется объектом, они обмениваются сообщениями)... Ход мысли понятен?
Ага, читал. Но заимствование концепции еще не делает заимствующего недееспособным
_>Посылка сообщения от вызова метода отличается двумя существенными моментами: _>1. Любое сообщение можно послать любому объекту _>2. Объект сам решает как ему обработать сообщение
Уже в Delphi существуют динамические методы с этими же двумя свойствами и механизм динамической диспетчеризации как альтернатива статической или виртуальной. Есть лишь одно ограничение, связанное с определенным уклоном в использовании этого механизма в Delphi: параметром динамически диспетчеризуемого метода должна быть структура не более чем определенного размера — 14 байт (тип значения не имеет), +2 заразервированных. Хотя можно создать свой диспетчеризатор (по-прежнему из одной функции!), который будет работать вместо этого с идентификатором сообщения и списком из произвольного числа произвольных параметров.
Про .NET я уже молчу
Ну, а если говорить о ООП... Как показывает пример Delphi, динамическая диспетчеризация легко выражается "один к одному" в понятиях "узкого" ООП, если язык предоставляет возможность свободно оперировать нестрого типизированными параметрами методов.
_>Но тут же возникает множество ограничений как раз связанных с крайней неоднородностью платформы. Т.е. все реализовано в виде каких-то специализированных случаев и использовать это не так то легко. А если что-то трудно использовать, то можно сказать, что этой возможности и нет.
Представим себе ситуацию, при которой механизм диспетчеризации Delphi изменен таким образом, как я только что описал. Чем же при таком подходе вызов диспетчера будет уступать посылке сообщения? А при наличии такой языковой поддержки (которая вообще не имеет отношения к ООП, так что правила игры не меняются) использовать динамическую диспетчеризацию будет совсем не трудно, а таки очень даже легко
SM>>Тот факт, что одни типы вызовов в статически типизированных языках выполняются значительно медленнее других, объявляется автором статьи недостатком этих языков. Довольно странно — я бы сказал, хорошо, что некоторые менее общие типы вызовов выполняются быстрее, чем более общие. Вряд ли можно назвать достоинством подхода его единообразно медленную работу на всех операциях.
_>Единообразно достаточно быструю. _>Хитрость в кэшировании. _>Смотри http://www.smalltalk.ru/articles/cpp-is-faster.html
Там ссылка на статью в PostScript, пока не читал, но обязательно почитаю. Пока мне приходит на ум только один способ заставить виртуальный вызов превратиться в статический: подменить адрес в точке вызова (назовем это привязкой). А при замене впоследствии объекта, которому направляется вызов, на другой, привязка отменяется и впоследствии может быть осуществлена снова, но уже к новому объекту. Любой другой способ потребует чтения адреса метода (раз он не указан в самой инструкции вызова ), так что, видимо, я угадал
Да, нельзя не согласиться.. Беру свои слова обратно, но лишь эти. А вот с тем, о чем я говорю дальше, спорить тяжело
_>Правильно, дело не в этом. Дело в культуре разработки, которая прививается тем или иным подходом. _>Smalltalk ориентируется на человека и его задачи, Java ориентируется на машину.
Все это очень замечательно. Но наша дискуссия так и не показала, почему практически важные возможности, предоставляемые "оригинальной" концепцией ООП вообще и Smalltalk в частности, шире, чем те, что возможны в рамках "суженной" концепции. Ну разве что фишка с динамическим наследованием...
Или я чего-то опять проглядел?
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, Slicer [Mirkwood], Вы писали:
_>>Поэтому вот этот микро-цикл разработки является критичным (вспоминаю как мне приходится по десять минут перегрузать жававский веб-сервер ради малюсенького изменения). Объектный подход позволяет этот цикл сделать минимальным из возможных. Ты по ходу добавляешь код или корректируешь состояние объект чтобы увидеть как дальше оно работает. SM>Хм. В предположении, что на SmallTalk можно написать веб-сервер: при его отладке не понадобиться компилировать его заново для учета внесенных изменений?
Опять проглядывают уши процедурного подхода.
Объектную систему не нужно перекомпилировать. В ней изменения вносятся по одному методу. И если метод странслирован без ошибок, то создается объект-метод с байт-кодом, который помещается в словать методов, находящийся в объекте-классе. Естественно, изменения вступают в силу сразу же.
_>>Для примера — сообщение можно послать и числу, и вызовется соответветствующий метод. Или можно модифицировать посылку сообщений для объекта так, что они будут упаковываться и передаваться по сети. Таким образом мы получаем SOA, которая сейчас так рекламируется как замена ООП (а технически SOA оказалось всего лишь специализированной реализацией посылки сообщения — всего лишь одна треть ООП ). SM>Странно. В результате сегодняшнего обмена письмами с Ричардом Тёрнером у меня сложилось немного другое впечатление. А именно, что SOA не является заменой ООП, а лишь дополняет его в области, в которой требуется учет некоторых вещей, которые в чистом ООП не учтены. Впрочем, это к делу не относится, а относится вот что: ни пример с числом, ни пример с сетью не показывает, чем же посылка сообщения в корне отличается от вызова метода, и почему она выходит за рамки ООП в его обычном, не Алленовском понимании.
Транспортный уровень SOA реализуется через специализированную посылку сообщения из ООП. Поэтому да, SOA является некоторой специфической надстройкой ООП. Но в маркетинговых речах мы слышим нечто другое — ООП себя не оправдал, там нужно тащить длл-ки на сервер и при изменении публичного интерфейса в распределенном приложении приходится передеплоивать длл-ки; поэтому была придумана новая технология SOA, которая приходит на смену ООП, где сетевые сервисы обмениваются между собой сообщениями (loose binding так сказать).
Чувствуешь насколько описание SOA совпадает с объектным подходом? Но почему-то говорится, что "узкий" ООП не решает проблему? Т.е. авторы согласны с тем, что вызов процедуры послабее SOA будет, который в свою очередь идеально ложится на объекты и сообщения.
_>>Однородность и предсказуемость решает. Она очень и очень упрощает разработку. Это не стоит игнорировать особенно учитывая человеческое 7+-2. _>>Сколько человеко-дней было потрачено каждый разработчиком .NET для изучения C#/VB, базовой библиотеки и сопутствующих технологий? А сколько новых возможностей появляется, на которые опять нужно тратить ценные человеко-дни. SM>... _>>Когда переходишь на Java, сразу чувствуется как наваливается множество ограничений, сильно снижающих продуктивность: _>>1. Почему new это какое-то ключевое слово, а не простой метод, и с ним ничего сделать нельзя? _>>2. Почему классы это не объекты, методы static нельзя переопределить и у них нет this? _>>3. Почему миллион в квадрате это полная билиберда? _>>4. Почему везде final? _>>5. Почему мне навязывают checked exceptions? _>>6. Почему во время отладки я не могу создать пару новых методов и подправить определение класса? _>>7. Почему обычный веб-сервер не может нормально работать 24x7 и его нельзя патчить на лету? _>>И так до бесконечности... SM>Ты же не хуже меня понимаешь, что почти все эти ограничения чем-то обоснованы: соображениями надежности программирования, или производительности, или и т.д. С ними можно соглашаться или не соглашаться, но они обоснованны. Кроме, разве что, того, что классы не являются полноценными объектами и нет метаклассов. И, честно говоря, я не вижу, как это может действительно снизить продуктивность работы. Впрочем, возможно, мне стоит попробовать пописать на SmallTalk
Никогда абстрактные фабрики не писал? С объектным подходом затрат усилий на это — практически ноль.
Вот тебе и пример почему плохо, что классы не объекты.
Я вижу только два соображения для таких ограничений языка:
1. Если выкинуть объекты, должно получиться как в C — такие же возможности и такая же скорость.
2. Объектная часть должна быть реализована привычным образом.
Отсюда это наследие, местами очень глупое.
Опять попытка one size fits all. Но, как мы знаешь, это невозможно. Ниша возможностей и продуктивности Smalltalk точно не закрыта. А для голой скорости я использую C++. Поэтому и разработчик и машина остаются удовлетворены.
SM>Но основная идея моего постинга заключалась не в защите Java или охаивании SmallTalk, а в том, что я не вижу, 1) почему подход SmallTalk не вписывается в "узкое" ООП, и 2) почему "узкое" ООП менее общо, чем подход SmallTalk. SM>А приведенные выше ограничения являются ограничениями языка, а не ООП.
Ну почему же, последние два это как раз ограничения "узкого" ООП. Чтобы их снять, нужно будет сделать такие шаги, которые сильно приблизит его к чистому ООП или к чему-то эквивалентному (как Lisp например).
_>>Ты конечно можешь выкусывать, но это не есть цель прототипов. Их цель исключить дуальный подход объект-класс, из-за которого в Smalltalk имеется нетривиальная структура объект-класс-метакласс и иерархии у них достаточно витиевато устроены. _>>При наличии прототипов создание новых экземпляров осуществляется сообщением copy, посланным прототипу (в случае с классами это сообщение new, посланное классу). Чтобы создать новый тип объектов, нужно взять какой-то прототип за основу, клонировать его, внести необходимые изменения и назвать его новым прототипом. _>>Таким образом объектная система упрощается, остаются только объекты, слоты и сообщения. SM>То есть это не дает новых практически применимых возможностей, а лишь опять же служит унификации работы с различными сущностями языка, что предположительно (не спорю, может, это и так!) сильно повысит эффективность программирования. Я правильно понимаю?
Унификация и как результат новые возможности. Делегирование любому сообщений объекту, наличие нескольких предков, динамическое изменение предков и т.д.
Вот это передний край науки, а Smalltalk — это так, промышленная технология.
_>>Упрощенно говоря — у каждого отдельно взятого объекта ты можешь менять его предков. SM>Ясно. Но, как мне кажется, такая схема ничуть не лучше простого агрегирования Хотя... в отличие от агрегирования в "классических" языках, при этом сохраняется полиморфизм относительно типов-предков, так? Может, и применимо в некоторых случаях — так сразу ничего не приходит в голову.
Далеко не всегда нужно, но некоторые идиомы легко кладутся на код.
_>>Т.е. если у нас есть объект Socket и у него состояния closed/connected/reading, тогда при смене состояния можно менять предка на SocketClosed/SocketConnected/SocketReading соответственно, который будет соответствующим образом обрабатывать все вызовы. SM>Ну, тут вполне можно обойтись агрегированием обобщенного SocketImpl в класс-фасад Socket, а от SocketImpl отнаследовать SocketClosed/SocketConnected/SocketReading... Кстати, если я изменю предка с SocketClosed (фактически, пустышки) на SocketReading — состояние новоявленного предка мне придется инициализировать вручную?
У тебя прототип уже инициализирован. Но изменяя предка, ты конечно можешь вызвать у него любой метод дополнительной инициализации.
_>>А по-твоему откуда SendMessage взялось? _>>Для наводки — message sending это концепция из Smalltalk, первый графический интерфейс создавался в Smalltalk и под него библиотека MVC, для элементов интерфейса была взята та же объектая метафора объектов и сообщений (каждый элемент представляется объектом, они обмениваются сообщениями)... Ход мысли понятен? SM>Ага, читал. Но заимствование концепции еще не делает заимствующего недееспособным
_>>Посылка сообщения от вызова метода отличается двумя существенными моментами: _>>1. Любое сообщение можно послать любому объекту _>>2. Объект сам решает как ему обработать сообщение SM>Уже в Delphi существуют динамические методы с этими же двумя свойствами и механизм динамической диспетчеризации как альтернатива статической или виртуальной. Есть лишь одно ограничение, связанное с определенным уклоном в использовании этого механизма в Delphi: параметром динамически диспетчеризуемого метода должна быть структура не более чем определенного размера — 14 байт (тип значения не имеет), +2 заразервированных. Хотя можно создать свой диспетчеризатор (по-прежнему из одной функции!), который будет работать вместо этого с идентификатором сообщения и списком из произвольного числа произвольных параметров. SM>Про .NET я уже молчу SM>Ну, а если говорить о ООП... Как показывает пример Delphi, динамическая диспетчеризация легко выражается "один к одному" в понятиях "узкого" ООП, если язык предоставляет возможность свободно оперировать нестрого типизированными параметрами методов.
Опять же повторюсь, некоторые динамические возможности присутствуют во многих языках, но у них есть ряд серьезных ограничений (ты сам перечислил) и они не распространяются на все элементы языка. Т.е. использовать их будет посложнее, откуда и берется пресловутая разница в продуктивности.
К тому же когда динамические возможности не включены в базис языка, а реализваны как дополнительные фичи, то страдает все та же скорость.
А в объектной системе все является посылкой сообщения, поэтому она оптимизирована до безобразация. Поэтому разница скорости рефлекции и прокси отличается в сотни раз.
_>>Но тут же возникает множество ограничений как раз связанных с крайней неоднородностью платформы. Т.е. все реализовано в виде каких-то специализированных случаев и использовать это не так то легко. А если что-то трудно использовать, то можно сказать, что этой возможности и нет. SM>Представим себе ситуацию, при которой механизм диспетчеризации Delphi изменен таким образом, как я только что описал. Чем же при таком подходе вызов диспетчера будет уступать посылке сообщения? А при наличии такой языковой поддержки (которая вообще не имеет отношения к ООП, так что правила игры не меняются) использовать динамическую диспетчеризацию будет совсем не трудно, а таки очень даже легко
Разница в том, что для применения динамичекой диспетчеризации тебе нужно сделать усилие, потратить больше времени. И работать будет только в ограниченном числе случаев. И скорость пострадает. В общем одни неудобства.
SM>
SM>>>Тот факт, что одни типы вызовов в статически типизированных языках выполняются значительно медленнее других, объявляется автором статьи недостатком этих языков. Довольно странно — я бы сказал, хорошо, что некоторые менее общие типы вызовов выполняются быстрее, чем более общие. Вряд ли можно назвать достоинством подхода его единообразно медленную работу на всех операциях.
_>>Единообразно достаточно быструю. _>>Хитрость в кэшировании. _>>Смотри http://www.smalltalk.ru/articles/cpp-is-faster.html SM>Там ссылка на статью в PostScript, пока не читал, но обязательно почитаю. Пока мне приходит на ум только один способ заставить виртуальный вызов превратиться в статический: подменить адрес в точке вызова (назовем это привязкой). А при замене впоследствии объекта, которому направляется вызов, на другой, привязка отменяется и впоследствии может быть осуществлена снова, но уже к новому объекту. Любой другой способ потребует чтения адреса метода (раз он не указан в самой инструкции вызова ), так что, видимо, я угадал
Соображаешь.
Схема там, конечно посложнее, но общая идея такая.
SM>Да, нельзя не согласиться.. Беру свои слова обратно, но лишь эти. А вот с тем, о чем я говорю дальше, спорить тяжело
_>>Правильно, дело не в этом. Дело в культуре разработки, которая прививается тем или иным подходом. _>>Smalltalk ориентируется на человека и его задачи, Java ориентируется на машину.
SM>Все это очень замечательно. Но наша дискуссия так и не показала, почему практически важные возможности, предоставляемые "оригинальной" концепцией ООП вообще и Smalltalk в частности, шире, чем те, что возможны в рамках "суженной" концепции. Ну разве что фишка с динамическим наследованием... SM>Или я чего-то опять проглядел?
Так сколько раз уже обсуждали.
Не надо пытаться выискать какие-то теоретические преимущества. Все они заключены уже в самом определение.
Но главное не это — главное какую культуру разработки прививает тот или иной подход.
А благодаря объектному подходу появилось все то, что можно увидеть в Smalltalk — графический интерфейс, среда разработки, интерактивный отладчик, отсуствие цикла компиляции-запуска, бесперебойное исполнение, эволюционный дизайн, гибкие методологии, refactoring, SUnit, TDD, XP, ...
Этот момент хорошо ощущается после примыкания к соответствующей (любой) культуре разработки. Ты начинаешь руководствоваться соответствующими ценностями и производить сходный результат.
Например, примкнув к культуре Java я увидел JSP, необъектные beans, ненужное засилие XML и т.д. Встречаются и отличные вещи от Apache Group, но у меня ощущение, что плотность полезного намного меньше.
SM>Slicer
Здравствуйте, Vi2, Вы писали:
Vi2>Здравствуйте, Rumata, Вы писали:
Vi2>
R>>... Кто-то решил, что их должно быть 3, т.к. это "следует из инкапсуляции". Но, т.к. понятие самой инкапсуляции, как я понимаю, само четко не сформулировано, следствия из него имхо строить довольно опасно.
Vi2>Инкапсуляция — это доступность (или сокрытие) того, что имеет объект, для кого-либо, отличного от самого объекта.
Vi2>Количество состояний доступности определяется тремя словами "никому", "одному" и "всем". Если ты сможешь найти еще слово, которое не выражается из этих трех, то тебе будет слава и почет.
Мне кажется, что Rumata прав. Что в действительности значит public, private, protected?
Public в пределах чего? Модуля? Системы? Чего то ещё?
Private — для кого — класса, объекта, класса и его друзей, класса и друзей его друзей?
Protected — для класса и его потомков или только для объекта?
Разные языки трактуют это по разному, хотя большинство определяют идею инкапсуляции примерно одинакого...
Здравствуйте, Slicer [Mirkwood], Вы писали: SM>Уже в Delphi существуют динамические методы с этими же двумя свойствами и механизм динамической диспетчеризации как альтернатива статической или виртуальной. Есть лишь одно ограничение, связанное с определенным уклоном в использовании этого механизма в Delphi: параметром динамически диспетчеризуемого метода должна быть структура не более чем определенного размера — 14 байт (тип значения не имеет), +2 заразервированных. Хотя можно создать свой диспетчеризатор (по-прежнему из одной функции!), который будет работать вместо этого с идентификатором сообщения и списком из произвольного числа произвольных параметров.
Прошу прощения, а откуда дровишки про ограничения на параметры? Впервые об этом слышу.
... << RSDN@Home 1.1.4 beta 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndreyFedotov, Вы писали:
AF> Мне кажется, что Rumata прав. Что в действительности значит public, private, protected? AF> Public в пределах чего? Модуля? Системы? Чего то ещё? AF> Private — для кого — класса, объекта, класса и его друзей, класса и друзей его друзей? AF> Protected — для класса и его потомков или только для объекта? AF> Разные языки трактуют это по разному, хотя большинство определяют идею инкапсуляции примерно одинакого...
Все очень и очень просто. Инкапсуляция в общем смысле — это ограничение прав внешних субъектов к данному объекту. В самом простом случае это вырождается в разделение между интерфейсом и реализацией. В юнитах Паскаля для этого есть две секции, которые совершенно четко выражают эту концепцию — interface и implementation.
Но структура Паскаля предполагает одноуровневые модули; никаких особых взаимоотношений между ними нет. Поэтому весь код делится только на две "кучи" — код моего модуля и код любого другого.
Как только появляется более сложная структура, появляется и желание более детально управлять обязанностями объекта. В привычном нам ООП (С++ и Object Pascal) объекты всегда можно поделить на три группы:
— объекты "моего" класса
— объекты классов — наследников
— все остальные объекты.
Именно из этих трех групп появились секции private, protected и public. Ребята, они не от бога даны. Это всего лишь отражение структуры конкретного языка. Не было бы наследования — не было бы protected.
Что мы наблюдаем в Java? Ага, помимо классов и наследования, появляются еще и пакеты. И сразу вводится четвертая категория доступа!
Кстати, в Delphi тоже есть лишняя (по отношению к С++) структурная единица — юнит. Было бы более чем логично ввести соответствующий спецификатор в язык для обозначения членов, доступных коду из того же юнита. Увы, разработчики языка не были готовы зайти так далеко, и вместо этого изменили смысл private. Т.е. на самом деле в Object Pascal нет private в смысле плюсов, хотя это не слишком и мешает.
Один взгляд в сторону дотнета подтвердит эти рассуждения с легкостью — появились сборки, и сразу потребовался спецификатор internal. Кстати, в отличие от канонической триады, internal и protected являются ортогональными. Т.е. мы не можем упорядочить все спецификаторы по "нарастанию открытости". Именно поэтому есть protected internal.
Помяните мои слова — при появлении в будущем более сложноструктурированных платформ список спецификаторов может быть расширен.
Представьте себе, что мы в .NET 3.0 решили выделить из всей массы посторонних классов те, которые живут в том же пространстве имен, и счесть, что наш класс будет иметь перед ними какие-то особые обязанности. Ок, введем спецификатор namespace. И возможные сочетания превратятся в:
S>Прошу прощения, а откуда дровишки про ограничения на параметры? Впервые об этом слышу.
Mea culpa
Сначала глючно написал, а потом не везде успел исправить.
Да, единственный var-параметр, тип не ограничивается
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>Вот бука! Андрей,
А что делать? SM>так это ж не в языке В языке присутствует возможность дать пользователю это сделать, но сам язык ничего не знает об абстракных фабриках.
И я считаю что так и надо. ИМХО не нужно вносить в язык то что можно сделать не особо напрягаясь тремя десятками строк.
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Slicer [Mirkwood], Вы писали: SM>Да, единственный var-параметр, тип не ограничивается SM>Slicer
Странно. Никогда об этом не слышал. Дал себе труд проверить под D7. Следующий код прекрасно компилируется и работает:
type
TMyClass = class
public
procedure Test(a: string; b: integer; c: Extended); dynamic;
end;
TMyClass2 = class(TMyClass)
procedure Test(a: string; b: integer; c: Extended); override;
end;
По-моему кое-то путает диспетчеризацию вызовов через VMT/DMT с диспетчеризацией оконных сообщений.
... << RSDN@Home 1.1.4 beta 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Vi2, Вы писали:
Vi2>Здравствуйте, Rumata, Вы писали:
Vi2>
R>>А пока, как я понял, даже с терминологией не договорились.
Vi2>Интересно, есть ли определение точки, множества и т.п. терминов, краеугольные для математики? Которые вроде всем известны и понятны, но тем не менее...
Что касается теории множеств и парадоксов оной, то, как говорится, здесь скорее проблема не в понятии множества, а в самом слове "понятие". Вводя операции на множестве(суть, описание взаимодействия элементов множества) мы получаем структуры(полугруппы, группы, кольца и т.д.), которыми занимается алгебра. Операции, впрочем тоже являются элементами некоторого множества операций со своими операциями на нем Построение геометрии и теории функционального анализа невозможно без понимания топологии(в частности понятие предела определяется топологическими свойствами пространства). Математические дисциплины очень тесно взаимосвязаны друг с другом и одно немыслимо без другого.
P.S. Ну, а что касается точки — то это сильно зависит от контекста. Т.е. точка чего?
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>Не, ты не понял SM>Не dynamic methods, a message methods!
Вот так и надо писать. А то
Уже в Delphi существуют динамические методы с этими же двумя свойствами и механизм динамической диспетчеризации как альтернатива статической или виртуальной
Вся фраза абсолютно верна по отношению к dynamic методам. А потом ты зачем-то съехал в описание ограничений совсем других методов.
... << RSDN@Home 1.1.4 beta 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
_>Чувствуешь насколько описание SOA совпадает с объектным подходом? Но почему-то говорится, что "узкий" ООП не решает проблему? Т.е. авторы согласны с тем, что вызов процедуры послабее SOA будет, который в свою очередь идеально ложится на объекты и сообщения.
А я поясню. Под ООП в данном случае в слоганах понимаются существующие реализации ООП — точнее, то, что вариантов межобъектного сетевого взаимодействия придумано множество. И SOA в числе прочего предлагает это сетевое взаимодействие стандартизовать (хотя сама парадигма SOA не предлагает такого стандарта, лишь призывает к его разработке).
_>Никогда абстрактные фабрики не писал? С объектным подходом затрат усилий на это — практически ноль.
Ну на Delphi на это вроде как особых усилий и не нужно, на то есть виртуальные конструкторы.
_>Ну почему же, последние два это как раз ограничения "узкого" ООП. Чтобы их снять, нужно будет сделать такие шаги, которые сильно приблизит его к чистому ООП или к чему-то эквивалентному (как Lisp например).
Почему же.. Среду разработки для любого языка с динамически компилируемыми методами и управляемыми объектами имхо можно усовершенствовать до такрого уровня. Сюда относится и Java, и любой .NET-язык. Действительно, что изменится, если мы добавим метод в класс или, тем более, изменим содержимое метода? Правда, некоторые трудности возможны с объектами на стеке в .NET (из-за изменения их размера при включении невиртуальных методов) и, возможно. с обновлением метаданных.
_>Опять же повторюсь, некоторые динамические возможности присутствуют во многих языках, но у них есть ряд серьезных ограничений (ты сам перечислил) и они не распространяются на все элементы языка. Т.е. использовать их будет посложнее, откуда и берется пресловутая разница в продуктивности. _>К тому же когда динамические возможности не включены в базис языка, а реализваны как дополнительные фичи, то страдает все та же скорость.
Но их можно включить в язык и можно снять большинство ограничений. И в этом случае вызов метода становится столь же мощным, как посылка сообщения. Я хочу сказать, что посылка сообщения не выходит за рамки "суженного" ООП.
_>Разница в том, что для применения динамичекой диспетчеризации тебе нужно сделать усилие, потратить больше времени. И работать будет только в ограниченном числе случаев. И скорость пострадает. В общем одни неудобства.
Опять же, посылка сообщения не выходит за рамки "суженного" ООП. Потому что при усовершенствовании только лишь процедурных возможностей языка посылка сообщения один к одному выражается вызовом метода.
SM>>Все это очень замечательно. Но наша дискуссия так и не показала, почему практически важные возможности, предоставляемые "оригинальной" концепцией ООП вообще и Smalltalk в частности, шире, чем те, что возможны в рамках "суженной" концепции. Ну разве что фишка с динамическим наследованием... SM>>Или я чего-то опять проглядел? _>Так сколько раз уже обсуждали. _>Не надо пытаться выискать какие-то теоретические преимущества. Все они заключены уже в самом определение. _>Но главное не это — главное какую культуру разработки прививает тот или иной подход. _>А благодаря объектному подходу появилось все то, что можно увидеть в Smalltalk — графический интерфейс, среда разработки, интерактивный отладчик, отсуствие цикла компиляции-запуска, бесперебойное исполнение, эволюционный дизайн, гибкие методологии, refactoring, SUnit, TDD, XP, ...
Иначе говоря, в настоящее время SmallTalk предоставляет некоторые возможности, отсутствующие в языках, построенных на базе "суженной" концепции ООП. Пускай, спорить с этим трудно.
Но это не означает, что "суженная" концепция проигрывает Алленовской в своей выразительной силе. Она лишь добавляет к Алленовской концепции несколько механизмов. Проектировщик может ими пользоваться, а может придумать свои, дополнительные. Но даже в этих условиях все рассмотренные нами задачи, решаемые Алленовским ООП, столь же легко решаются в рамках "суженного" ООП (я говорю об этапе проектирования, а не реализации — последняя ограничивается возможностями используемых языков).
Вроде бы, все выяснили
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Рррр. Message Methods являются динамическими методами, кроме того, они являются dynamic methods и управляются тем же внутренним механизмом, но программист сам приписывает им индекс метода.
А для обсуждаемой темы тонкости вроде того, как именно они называются в Delphi, значения не имеют: важно, что они существуют, что они могут служить для передачи сообщения и что для них используется динамическая диспетчеризация
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>Иначе говоря, в настоящее время SmallTalk предоставляет некоторые возможности, отсутствующие в языках, построенных на базе "суженной" концепции ООП. Пускай, спорить с этим трудно. SM>Но это не означает, что "суженная" концепция проигрывает Алленовской в своей выразительной силе. Она лишь добавляет к Алленовской концепции несколько механизмов. Проектировщик может ими пользоваться, а может придумать свои, дополнительные. Но даже в этих условиях все рассмотренные нами задачи, решаемые Алленовским ООП, столь же легко решаются в рамках "суженного" ООП (я говорю об этапе проектирования, а не реализации — последняя ограничивается возможностями используемых языков).
Во первых "суженная" концепция сильно урезает ООП таким образом, что становится невозможным рекурсивный дизайн и эволюционно развивающаяся объектная система. Вдобавок приделанная (точнее оставленная) процедурная парадигма увеличивает энтропию. Получается плохо сопровождаемое нерегулярное ни то ни се.
Степень полиморфности вообще ограничивается только теми случаями, которые были явно предусмотрены. Т.е. там где программист поставил public/protected, virtual, нет final, создано побольше fine-grained интерфейсов и предусмотрена возможность повлиять на создание объектов.
В объектной среде пределов возможностям практически нет. Если выскочит баг в моей среде разработки, я тут же могу его сам пофиксить или обойти и продолжить выполнение функции дальше.
Продуктивность рождается только от дополнительных возможностей, а не от ограничений (сверх какого-то минимально необходимого набора).
SM>Вроде бы, все выяснили
Да, дальше что-то обсуждать уже будет излишне. Если твоей целью было получение точки зрения на проблему, то ты ее получил. Правда учти, что любая жесткая точка зрения есть добровольное самоограничение.
Лучшим способом изучить предмет по прежнему остается практическое использование. Правда тут есть своя опасность...
SM>Slicer
Здравствуйте, mihailik, Вы писали:
R>>Вот только опять не понятно, являются ли приведенные там документы какими-либо стандартами. неужели за более чем 10 лет развития, под ООП не подвели никаких признаных стандартов вообще?
M>А что, есть какие-то стандарты "реляционности" баз данных?
Да, нужно, чтобы любой запрос, сделанный на языке реляционный алгебры (есть такой), можно было переести на язык этой БД (SQL).
Здравствуйте, _vovin, Вы писали:
_>Именно так. Еще не придумано хороших математических методов описания задачи, когда исходный код можно создать сразу и правильно.
Э.Дейкстра. Дисциплина программирования.
Д.Грис. Наука программирования.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Хайку или хокку. Первое более позднее
Хаику и хокку — это одно и то же См. словарь японского языка.
До них была немного другая (но похожая) стихотворная форма, но как называлась — не помню.
Здравствуйте, Astaroth, Вы писали:
A>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Хайку или хокку. Первое более позднее
A>Хаику и хокку — это одно и то же См. словарь японского языка. A>До них была немного другая (но похожая) стихотворная форма, но как называлась — не помню.
Я и не утверждал что это разное. Более поздним является само _название_ — хайку, которое стало употребляться этак в веке 17. А хокку изначально это просто первая строфа танка (той самой "другой" стихотворной формы), а впоследствии уже самостоятельный жанр — как бы принципиально незавершенное стихотворение.
Фаза первая) Никому никому никому.
Фаза вторая) Никому никому никому, только ему одному.
Фаза третья) Никому никому никому, только ему одному и его друзьям.
Фаза четвертая) Всем всем всем.
Фаза пятая) Кому кому кому.
Здравствуйте, _vovin, Вы писали:
_>После этого Алан Кей сформулировал три базовых принципа объектного подхода: _>1. Объект — базовая единица системы. _>2. Объекты обладают состоянием. _>3. Единственным способом взаимодействия между объектами является посылка сообщения. Объекты сами определяют как обрабатывать сообщения.
_>Соответственно объектно-ориентированным языком является язык, который взаимодействует с такой системой объектов посредством посылки сообщения. _>Заметьте, тут ничего не говорится про классы и наследование.
_>Но почему-то так вышло, что все обратились к модели Simula, т.е. навесили ООП ярлык ИНКАПСУЛЯЦИЯ, ПОЛИМОРФИЗМ, НАСЛЕДОВАНИЕ. И главными ценностями были провозглашены модульность и повторное использование.
Видишь-ли в чем дело. Оно конечно все так. Но если речь идет об общеупотребимом смысле термина ООП, то разумно признать под ООП то, что понимает под ним большинство, причем уже продолжительное время. Это язык, он создан чтобы люди понимали друг друга, а ООП всего лишь название. Например, глупо сейчас спорить о том, что "блядь" — это вполне цензурное слово, приводя в доказательство исторические справки (когда-то оно действительно было вполне обиходным, а сейчас режет слух, хоть обчитайся этих справок). Поздновато.
ООП — это именно ИНКАПСУЛЯЦИЯ, ПОЛИМОРФИЗМ, НАСЛЕДОВАНИЕ, — то есть то, что под ним сейчас понимает сообщество Computer Science. Все. Принципы Алана Кея — это конечно интересно, но это не ООП. Называйте их как хотите.
Теперь если разобраться по существу, то принципы Кея (а именно №3) определяют понятие инкапсуляции, и динамического связывания как способа достижения полиморфизма. Эти вещи были изучены исследователями, и сформулированны в более общем виде, без всяких "сообщений".
Инкапсуляция - это "абстрактные типы данных", которые задаются поведением, а не структурой. Полиморфизм - в общем случае возможность вызова функции с агрументами разных типов (для метода класса — экземпляр тоже является неявным аргументом), причем поведение может различаться в зависимости от типа аргумента (С++: виртуальные функции, перегруженные функции), а может и нет (С++: шаблонные функции). Наследование - отношение между абстрактными типами данных, позволяющее использовать один тип в контексте другого (отношение "подтипа"). Оно совсем не обязательно должно задаваться программистом явно (!) — об этом в определении ничего не сказано!
Легко видеть, что Smalltalk удовлетворяет этому определению . Оно более общо, нежели модели программирования С++, Simula, Oberon, Smalltalk, etc. В ЦК, знаете-ли, тоже не дураки сидят. Мы полетим ночью.
_> Но это является пагубным упрощением, которое практически сводит на нет всю идею объектного подхода. Где главным выигрышем является возможность непосредственного манипулирования динамическим миром объектов посредством гибкой операции посылки сообщения, минуя привычную чрезмерную серию трансформаций текст->код->запуск->взаимодействие->результаты->текст->...
Как раз напротив. В определении ООП ничего не говорится ни про динамичность или статичность типизации, ни про другие подобные характеристики языка, вроде сообщений. Там даже не сказано, что у класса должны быть "методы" в привычном смысле этого слова , и каким именно образом и в каком объеме реализуется полиморфизм. А вот схема смолтока — это один из частных случаев. Возможно , чем-то лучше, чем другие.
_> Поэтому ООП можно условно поделить на две категории — OBJECT-oriented и object-ORIENTED. _> В первом случае имеем полноценную динамическую систему (Smalltalk, Self, отчасти Objective-C, Ruby), во втором — процедуры, завернутые в классы (Simula, C++, Java, C#).
Стоит отметить, что вы сравниваете языки, а не определения ООП. Не надо мешать общеизвестное определение ООП, с особенностями системам типов упомянутых языков. Причем как тех (Simula, C++, Java, C#), так и других (Smalltalk, Self, отчасти Objective-C, Ruby), потому как все эти языки ему удовлетворяют. Каждый по своему, с особенностями. Но это не повод, чтобы разводить языковые войны .
Здравствуйте, Rumata, Вы писали:
R>Здравствуйте, WFrag, Вы писали:
R>>>Вот например, всем известно, что бывают у объектов эл-ты public, private и protected. А почему только 3? Почему нет какого-нибудь четвертого?
WF>>Кто тебе такую глупость сказал?
WF>>public, private, protected — это уже косвенное следствие инкапсуляции. R>Пардон, совсем пропустил это замечание. R>Ну дык именно, что косвенное. Кто-то решил, что их должно быть 3, т.к. это "следует из инкапсуляции". Но, т.к. понятие самой инкапсуляции, как я понимаю, само четко не сформулированно, следствия из него имхо строить довольно опасно.
Сформулировано предельно четко. Весь вопрос — "где". Идея, которая лежит в основе инкапсуляции — Abstract Data Types, типы, которые определяются набором операций над ними, и ничем другим. Совершенно математическая по духу концепция. Одной только инкапсуляции посвящены целые книги, например
Использование абстракций и спецификаций при разработке программ
Лисков Б., Гатэг Д.
М.: Мир
1989. 424 с.
Задача, решаемая применением инкапсуляции: разбить систему на набор по возможности слабо связанных компонентов, так, чтобы реализация одного компонента как можно меньше влияла на другие. Пример: алгоритмы STL, такие как transform, работают с любым типом контейнера, не зависимо от его внутренней структуры (список, массив, строка). Почему так? Потому, что контейнеры предоставляют одинаковый интерфейс через итераторы, который не зависит от способа реализации контейнера (т. е. не ломает инкапсуляцию, как, например, доступ по индексу).
Решение: выставлять наружу интерфейс в виде функций, по возможности определяющих поведение объекта, а не структуру. Пример: доступ по индексу — не лучший интерфейс для контейнера "вообще", он накладывает серьезные ограничения на способ хранения. Списки, к примеру, вы уже не попользуете. Такой интерфейс ломает инкапсуляцию, не смотря на то, что может быть реализован в виде функции — вы выдаете наружу структуру хранения. Еще один пример плохой инкапсуляции — использование сеттеров-геттеров.
"Плохая инкапсуляция" — это всегда плохо? Нет. Все хорошо в меру и к месту. Ключевое слово в предыдущем абзаце — "по возможности".
Применение инкапсуляции поможет писать программы быстрее? Вообще говоря нет. Думать придется больше. В ряде случаев это замедлит разработку . Так где преимущество? Оно в том, при разумном применении инкапсуляции система будет проще (благодаря уменьшению количества внутренних зависимостей), и, как следствие, менее "хрупкая" (т. е. будет устойчивее к изменениям). Начиная с некоторого (довольно большого) объема кода это критичный фактор, определяющий качество продукта (кол-во дефектов), а также цену вносимых изменений. Т. е. хорошая инкапсуляция принесет дивиденты при развитии и сопровождении системы (докрутке фич/модификации, рефакторинге, исправлении дефектов, просто при итеративной разработке). Это способ держать сложность системы под контролем.
Реализация: поддержка инкапсуляции языком не критична — инкапсуляцию можно применять на уровне соглашений в любом языке. Но поддержка на уровне языка приятна. Т. к. ее проверяет компилятор, есть уверенность, что в незнакомом коде инкапсуляция не нарушена. Хотя... Есть же еще спецназ от программирования, которых ничего не остановит!
#define private public
#include"header.h"
Так что не уверенность, а всего лишь надежда
private, protected, public — определяют уровни доступа "локальный", "для подклассов", "для всех". Почему их три? Попробуйте придумать еще.
Здравствуйте, Gaperton, Вы писали:
G>Видишь-ли в чем дело. Оно конечно все так. Но если речь идет об общеупотребимом смысле термина ООП, то разумно признать под ООП то, что понимает под ним большинство, причем уже продолжительное время.
А может, стоит как раз обратиться к определению Алана Кея? Оно, кстати, гораздо более компактное и простое. И, заметьте, никаких понятий вроде "абстрактные типы данных", инкапсуляция, полиморфизм и прочей шелухи
Здравствуйте, serg_mo, Вы писали:
_>Здравствуйте, Gaperton, Вы писали:
G>>Видишь-ли в чем дело. Оно конечно все так. Но если речь идет об общеупотребимом смысле термина ООП, то разумно признать под ООП то, что понимает под ним большинство, причем уже продолжительное время.
_>А может, стоит как раз обратиться к определению Алана Кея? Оно, кстати, гораздо более компактное и простое. И, заметьте, никаких понятий вроде "абстрактные типы данных", инкапсуляция, полиморфизм и прочей шелухи
"Пусть это будет просто, просто — насколько это возможно, но не проще"
Да пожалуйста. Есть только несколько маленьких нюансов.
1) Ни один функциональный язык не может быть ООП языком по этому определению, так как состояния у объектов там нет — это противоречит самой идее функциональности. Есть только значения. Бедные Haskell, CLOS и OCaml.
2) Из определения следует, что статически типизированные языки не могут быть ООП языками в принципе, поскольку явно обозначена динамическая диспетчеризация "сообщений". Уходят С++, С#, и другие статически типизированные языки.
3) Что остается? Smalltalk , все что на него похоже.
Весь вопрос — зачем. Авторы (и читатели) большинства статей подразумевают под ООП отнюдь не определение Кея. Хотите, чтобы вас понимали правильно? Используйте устоявшуюся терминологию. Подобные подмены терминов ни к чему кроме путаницы не ведут. А утверждения из разряда "С# не поддерживает ООП" (к чему вы придете пользуясь определением Кея) так вообще вызовет у читателей истерику. Вам нужно такое определение?
А если не хотите забивать себе голову теорией, то все гораздо проще и компактнее. ООП — это когда есть классы.
Здравствуйте, Gaperton, Вы писали:
G>1) Ни один функциональный язык не может быть ООП языком по этому определению, так как состояния у объектов там нет — это противоречит самой идее функциональности. Есть только значения. Бедные Haskell, CLOS и OCaml.
Не может. И что в этом такого страшного?
G>2) Из определения следует, что статически типизированные языки не могут быть ООП языками в принципе, поскольку явно обозначена динамическая диспетчеризация "сообщений". Уходят С++, С#, и другие статически типизированные языки.
Здесь, в принципе, можно "притянуть", приняв вызов метода = посылка сообщения (что, кстати, обычно и делают).
G>3) Что остается? Smalltalk , все что на него похоже.
Да, эти языки являются наиболее адекватными реализациями модели Кея.
G>Весь вопрос — зачем. Авторы (и читатели) большинства статей подразумевают под ООП отнюдь не определение Кея. Хотите, чтобы вас понимали правильно? Используйте устоявшуюся терминологию.
Хе, большинство статей, которые я помню, где авторы брали на себя труд объяснить, что такое объектный подход, они начинали именно с кеевского определения, в том или ином виде. А затем уже переходили к инкапсуляции, полиморфизму и т. д. И знаете, мне кажется, почему? Потому что слова "инкапсуляция", "полиморфизм" и "наследование" никак не отражают динамики объектной системы. Они описывают лишь свойства объектных систем, но не их поведение.
Кстати, именно такой взгляд на объекты приводит к появлению статей типа "Is OO Dead?"
G>Подобные подмены терминов ни к чему кроме путаницы не ведут.
Именно. Поэтому я и ратую за определение Кея
G>А утверждения из разряда "С# не поддерживает ООП" (к чему вы придете пользуясь определением Кея) так вообще вызовет у читателей истерику. Вам нужно такое определение?
Отчего же вызовут? Да, C# поддерживает некое подобие ООП, и давая волю фантазии при проектировании, придется себя ограничивать
Тем не менее и анализ, и моделирование предметной области Вы проводите, именно используя определение Кея .
G>А если не хотите забивать себе голову теорией...
Как раз именно хочу. Только теория теории рознь
Здравствуйте, serg_mo, Вы писали:
_>Здравствуйте, Gaperton, Вы писали:
G>>1) Ни один функциональный язык не может быть ООП языком по этому определению, так как состояния у объектов там нет — это противоречит самой идее функциональности. Есть только значения. Бедные Haskell, CLOS и OCaml. _>Не может. И что в этом такого страшного?
Уж не знаю, насколько это страшно , но перечисленые языки (Haskell, CLOS и OCaml) поддерживают ООП . Даже в простом, интуитивном смысле, хотя это легко и проверить формально по классическому определению. Что говорит о плохо составленом определении Кея — оно недостаточно общо, настолько, что не работает на целом классе языков.
G>>2) Из определения следует, что статически типизированные языки не могут быть ООП языками в принципе, поскольку явно обозначена динамическая диспетчеризация "сообщений". Уходят С++, С#, и другие статически типизированные языки. _>Здесь, в принципе, можно "притянуть", приняв вызов метода = посылка сообщения (что, кстати, обычно и делают).
Ну, в общем-то все так и делают. Но это будет именно "притянуть", потому как "объекты сами определяют как обрабатывать сообщения" — здесь имеется в виду динамическая диспетчеризация. Тонкость. Любому объекту может быть отправлено любое сообшение, которое этот объект может корректно (!) отработать — вот важный элемент системы типов Кея. Именно поэтому Кей использует термин "сообщение", а не "метод". И это та часть определения, которую уже никак не притянешь, и не выбросишь — или это определение перестанет быть определением Кея.
G>>3) Что остается? Smalltalk , все что на него похоже. _>Да, эти языки являются наиболее адекватными реализациями модели Кея.
Ага. И единственными языками, которые формально удовлетворяют его определению. Что говорит о том, что это определение вполне конкретной системы типов, используемой в данных языках, а отнюдь не парадигмы ООП.
G>>Весь вопрос — зачем. Авторы (и читатели) большинства статей подразумевают под ООП отнюдь не определение Кея. Хотите, чтобы вас понимали правильно? Используйте устоявшуюся терминологию. _>Хе, большинство статей, которые я помню, где авторы брали на себя труд объяснить, что такое объектный подход, они начинали именно с кеевского определения, в том или ином виде. А затем уже переходили к инкапсуляции, полиморфизму и т. д. И знаете, мне кажется, почему? Потому что слова "инкапсуляция", "полиморфизм" и "наследование" никак не отражают динамики объектной системы. Они описывают лишь свойства объектных систем, но не их поведение.
Верно. Это именно свойства системы типов. Поэтому они и используются как ОО характеристика не зависящая от языка и системы типов. Оно и не должно отражать динамику объектной системы само по себе. Не вижу, кстати, ничего удивительного в том, что такая абстрактная характеристика плохо воспринимается.
Хотя у меня получается за 40 минут объяснить это определение так, что люди все прекрасно понимают. Берется определение, объясняется смысл каждого пункта с примерами, поясняется как именно принципы реализуются в С++, Java, как в динамически типизированных языках, почему COM не удовлетворяет этому определению. И вы знаете, прекрасно понимают. При этом, я прекрасно обхожусь без аналогий, аллегорий, и прочих метафизических переходов на яблоки — все предельно конкретно. ИМХО, люди не идиоты, а в мире не так много сложных вещей; надо просто уметь объяснять.
Кстати, хочу уточнить. Вы хотите сказать, что вам удасца избежать знакомства с этими тремя понятиями, программируя на смолтоке?
_>Кстати, именно такой взгляд на объекты приводит к появлению статей типа "Is OO Dead?"
Эт врядли. К появлению таких статей ведет то, что люди считают систему типов своего любимого языка фактическим определением ООП. На деле же ОО языки весьма разнообразны и многолики. Чтобы иллюзии ушли, рекомендую взлянуть на систему типов CLOS. После этого станет ясно, например, почему именно в определение введен скромный пункт "полиморфизм", а не "сообщения Smalltalk" или "виртуальные функции C++".
G>>Подобные подмены терминов ни к чему кроме путаницы не ведут. _>Именно. Поэтому я и ратую за определение Кея
Ну и напрасно. Непродуктивное это занятие, спорить о значении слов ("что такое ООП"). Особенно тех слов, относительно смысла которых весь остальной мир уже давно договорился.
G>>А утверждения из разряда "С# не поддерживает ООП" (к чему вы придете пользуясь определением Кея) так вообще вызовет у читателей истерику. Вам нужно такое определение? _>Отчего же вызовут? Да, C# поддерживает некое подобие ООП, и давая волю фантазии при проектировании, придется себя ограничивать
Ну, я имею в виду, у сторонников С#
_>Тем не менее и анализ, и моделирование предметной области Вы проводите, именно используя определение Кея .
Откуда такая уверенность? Вдруг я использую для этого SADT?
Здравствуйте, Gaperton, Вы писали:
G>private, protected, public — определяют уровни доступа "локальный", "для подклассов", "для всех". Почему их три? Попробуйте придумать еще.
Я бы ещё ввёл
private protected. В этом случае member может переопределить только непосредственный потомок класса, но не все потомки. Этакое замыкание контракта наследования в потомке в отличие от final в текущем классе.
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, Gaperton, Вы писали:
G>>private, protected, public — определяют уровни доступа "локальный", "для подклассов", "для всех". Почему их три? Попробуйте придумать еще.
ZEN>Я бы ещё ввёл ZEN>private protected. В этом случае member может переопределить только непосредственный потомок класса, но не все потомки. Этакое замыкание контракта наследования в потомке в отличие от final в текущем классе.
Чтобы добиться такого эффекта, достаточно иметь возможность изменять модификаторы видимости содержимого базового класса в подклассе. Т. е. в подклассе правим protected на private для нашего мембера.
На самом деле, Синклер замечательно и исчерпывающе написал про модификаторы здесь
Здравствуйте, Gaperton, Вы писали: iZEN>>Я бы ещё ввёл iZEN>>private protected. В этом случае member может переопределить только непосредственный потомок класса, но не все потомки. Этакое замыкание контракта наследования в потомке в отличие от final в текущем классе. G>Чтобы добиться такого эффекта, достаточно иметь возможность изменять модификаторы видимости содержимого базового класса в подклассе. Т. е. в подклассе правим protected на private для нашего мембера.
Отнюдь не одно и то же. Я не это имел ввиду.
(Да и сторонний разработчик не захочет объявить private.)
В моём случае мы обязываем будущие классы-наследники объявлять фактически final protected member. Причём мы не уверены, какие классы будут порождаться от нашего, но будем уверены, что member может быть переопределён только в наследниках и нигде больше (с областью видимости final protected, полиморфизм будет заканчиваться на близком наследнике однозначно).
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, serg_mo, Вы писали:
_>>Здравствуйте, Gaperton, Вы писали:
G>>>Видишь-ли в чем дело. Оно конечно все так. Но если речь идет об общеупотребимом смысле термина ООП, то разумно признать под ООП то, что понимает под ним большинство, причем уже продолжительное время.
_>>А может, стоит как раз обратиться к определению Алана Кея? Оно, кстати, гораздо более компактное и простое. И, заметьте, никаких понятий вроде "абстрактные типы данных", инкапсуляция, полиморфизм и прочей шелухи
G>
G>"Пусть это будет просто, просто — насколько это возможно, но не проще"
Во-во.
G>Да пожалуйста. Есть только несколько маленьких нюансов. G>1) Ни один функциональный язык не может быть ООП языком по этому определению, так как состояния у объектов там нет — это противоречит самой идее функциональности. Есть только значения. Бедные Haskell, CLOS и OCaml.
Объектный принцип более широкое понятие чем язык программирования. В частности Erlang представляет собой вполне объектную систему на несколько другом уровне абстракции — в терминах процессов. SOA это в чистом виде транспортная объектная модель с навешанной кучей соглашений.
Если бы ООП всеми понималось как вначале, думаешь пришлось бы тридцать лет ждать появления SOA? Все remoting frameworks в Smalltalk это свой SOA.
G>2) Из определения следует, что статически типизированные языки не могут быть ООП языками в принципе, поскольку явно обозначена динамическая диспетчеризация "сообщений". Уходят С++, С#, и другие статически типизированные языки.
Хе-хе. Совершенно отчетливо проглядывает желание НАЙТИ СЕРЕБРЯНУЮ ПУЛЮ.
Ну зачем всему и вся навязывать единственный правильный способ. Вот собирает человек марки, и должен этими марками всем в лицо тыкать?
Меня Haskell, CLOS, C++ вполне устраивают в своем текущем виде если применять их в соответствующих нишах. Объектный подход тоже имеет свои (достаточно широкие) рамки.
Я поражаюсь, насколько бездарно тратятся усилия (в том числе и мои) на борьбу с JSP+Oracle, когда то же самое можно достичь с помощью VisualWorks+GemStone раза в три проще!
G>3) Что остается? Smalltalk , все что на него похоже.
Читаем выше.
G>Весь вопрос — зачем. Авторы (и читатели) большинства статей подразумевают под ООП отнюдь не определение Кея. Хотите, чтобы вас понимали правильно? Используйте устоявшуюся терминологию. Подобные подмены терминов ни к чему кроме путаницы не ведут. А утверждения из разряда "С# не поддерживает ООП" (к чему вы придете пользуясь определением Кея) так вообще вызовет у читателей истерику. Вам нужно такое определение?
Я не против этого. Более того, я сам использую термин ООП (благодяря слову "ориентированное") в общепринятом смысле. Для оригинального определения обычно употребляется Объектный Подход или что-то вроде этого. Но терминология эта зыбкая, т.к. когда говорят ООП (при этом думают о наследовании и т.д.), то под этим подразумевают и Smalltalk, который реализует более общую и продуктивную концепцию.
Вот я против такого обобщения.
Когда говорят "ООП потерпел неудачу", пусть тогда уточняют, что это именно обрезанный статический взгляд на объекты не удался. Отсюда и фразы вроде "C# не поддерживает ООП".
Я за то, чтобы объектный подход (термин и само понятие) стал распознаваем. Нет термина, значит нет предмета.
Глупо замалчивать наличие такой вещи, лишая людей возможности выбора. Больше возможностей — лучше результа. Пусть тебе сам подход не нравиться, но давай другим людям возможность о нем у знать и решить самим.
G>А если не хотите забивать себе голову теорией, то все гораздо проще и компактнее. ООП — это когда есть классы.
А это вообще в корне не верно. Классы были в Симуле, откуда ООП и позаимствовало их как деталь реализации. Но ни в одном определении ООП их нет.
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, Gaperton, Вы писали: iZEN>>>Я бы ещё ввёл iZEN>>>private protected. В этом случае member может переопределить только непосредственный потомок класса, но не все потомки. Этакое замыкание контракта наследования в потомке в отличие от final в текущем классе. G>>Чтобы добиться такого эффекта, достаточно иметь возможность изменять модификаторы видимости содержимого базового класса в подклассе. Т. е. в подклассе правим protected на private для нашего мембера.
ZEN>Отнюдь не одно и то же. Я не это имел ввиду. ZEN>(Да и сторонний разработчик не захочет объявить private.) ZEN>В моём случае мы обязываем будущие классы-наследники объявлять фактически final protected member. Причём мы не уверены, какие классы будут порождаться от нашего, но будем уверены, что member может быть переопределён только в наследниках и нигде больше (с областью видимости final protected, полиморфизм будет заканчиваться на близком наследнике однозначно).
Здравствуйте, _vovin, Вы писали:
G>>Да пожалуйста. Есть только несколько маленьких нюансов. G>>1) Ни один функциональный язык не может быть ООП языком по этому определению, так как состояния у объектов там нет — это противоречит самой идее функциональности. Есть только значения. Бедные Haskell, CLOS и OCaml. _>Объектный принцип более широкое понятие чем язык программирования.
Конечно. Но определение должно быть точным (или это уже не определение). Приведенные тобой принципы Кея неверны ни для какого функционального языка, понимаешь? Там у объектов нет и не может быть состояний, в силу свойства referencial transparency. Там функция — базовая единица системы. Functions are the first class citizens in that languages. Эту строчку ты найдешь в любом факе по ФЯ. Знаешь, насколько далек полиморфный вызов языка CLOS от посылки сообщения? Ты удивишься. Представь себе мультиметод — функция, которая "виртуальна" по всем своим аргументам. Это является обобщением известного "виртуального" вызова, и при этом невыразимо в терминах сообщений в принципе. Здесь ты никак не притянешь сообщения.
Да, при этом CLOS удовлетворяет известному определению ООП (инкапсуляция, наследование, полиморфизм). Как и Smalltalk. Вывод? Обычное определение ООП более общо, чем определение Кея, которое есть один из его частных случаев, так же как и системы типов C#, СLOS, Smalltalk, и Simula. Но при этом, ты его почему-то называешь "ограниченным" в сравнении с определением Кея. Ты неправ. Тебе на самом деле не нравятся системы типов конкретных языков, а не "инкапсуляция" с "наследованием" и "полиморфизмом".
_> В частности Erlang представляет собой вполне объектную систему на несколько другом уровне абстракции — в терминах процессов. SOA это в чистом виде транспортная объектная модель с навешанной кучей соглашений.
Вот как раз Erlang — это не объектная система ни в каком смысле, ни в классическом, ни в твоем. Кстати, авторы это языка тоже в этом уверены. А ты здесь путаешь народ. Я проверяю Erlang на соответсвие твоему определению, читай внимательно:
Базовый элемент языка Erlang как и любого другого функционального языка — функция (а не объект!), состояния у объектов нет (язык функциональный), а сообщениями обмениваются не объекты, а процессы, количество которых в реальной системе ограничено десятками тысяч (их нельзя использовать как объекты хотя-бы по этой, второстепенной причине!).
Кстати, "сообщение" в Erlang не приводит к вызову никаких методов, и тем более не возвращает результата. Ты просто не сможешь использовать процессы в роле объектов, потому как единственный способ доступится к процессу — это в свою очередь принять от него сообщение. Там сообщения — это наоборот данные, "объекты" произвольного типа (ты можешь послать другому процессу вообще любую структуру данных — например двоичное дерево), которые посылаются и принимаются примитивами SEND/RECEIVE, и диспетчеризуются полностью вручную. В конце концов, дизайн приложений на Erlang не является объектным. Могу прислать образцы кода, чтобы ты в этом убедился.
Ни одного (!) пересечения с определением Кейна, кроме слова "сообщение". Но с этой точки зрения — и обычный С с библиотекой MPI является такой же объектной системой.
G>>2) Из определения следует, что статически типизированные языки не могут быть ООП языками в принципе, поскольку явно обозначена динамическая диспетчеризация "сообщений". Уходят С++, С#, и другие статически типизированные языки. _>Хе-хе. Совершенно отчетливо проглядывает желание НАЙТИ СЕРЕБРЯНУЮ ПУЛЮ.
Это где, пардон, оно проглядывается? Прошу показать пальцем, я не понимаю.
_>Ну зачем всему и вся навязывать единственный правильный способ. Вот собирает человек марки, и должен этими марками всем в лицо тыкать?
Какой способ? Да не навязывает известное определение ООП никому никакого способа, доказательство тому — многообразие ООП языков.
G>>Весь вопрос — зачем. Авторы (и читатели) большинства статей подразумевают под ООП отнюдь не определение Кея. Хотите, чтобы вас понимали правильно? Используйте устоявшуюся терминологию. Подобные подмены терминов ни к чему кроме путаницы не ведут. А утверждения из разряда "С# не поддерживает ООП" (к чему вы придете пользуясь определением Кея) так вообще вызовет у читателей истерику. Вам нужно такое определение? _>Я не против этого. Более того, я сам использую термин ООП (благодяря слову "ориентированное") в общепринятом смысле. Для оригинального определения обычно употребляется Объектный Подход или что-то вроде этого. Но терминология эта зыбкая, т.к. когда говорят ООП (при этом думают о наследовании и т.д.), то под этим подразумевают и Smalltalk, который реализует более общую и продуктивную концепцию.
Стоп. "более общую и продуктивную концепцию" в сравнении с чем? С С#? Возможно. С ООП? Однозначно нет.
Наоборот, наследование, полиморфизм, инкапсуляция — это более общая концепция чем Smalltalk, С++, и CLOS. И терминология не зыбкая, она как раз предельно точна. Если у тебя есть в этом сомнения, готов их обсудить предметно, по пунктам, и привести необходимые доказательства.
_>Вот я против такого обобщения. _>Когда говорят "ООП потерпел неудачу", пусть тогда уточняют, что это именно обрезанный статический взгляд на объекты не удался. Отсюда и фразы вроде "C# не поддерживает ООП".
Совершенно согласен. Я тоже против такого обобщения.
_>Я за то, чтобы объектный подход (термин и само понятие) стал распознаваем. Нет термина, значит нет предмета. _>Глупо замалчивать наличие такой вещи, лишая людей возможности выбора. Больше возможностей — лучше результа.
Поностью с тобой согласен.
_> Пусть тебе сам подход не нравиться, но давай другим людям возможность о нем у знать и решить самим.
Почему ты решил, что я имею что-то против объектного подхода? Нет, он мне как раз весьма симпатичен. Я против замешивания на дерьме ООП (инкапсуляции, полиморфизма и наследования), и миссионерских фраз вроде "термин ООП стал жертвой обстоятельств". На самом деле, типа, все не так, как вы привыкли думать! И мы, узкий круг посвященных, знаем истину. Вот он, тайный, правильный смысл термина ООП!
На самом деле ты приводишь еще одну, кстати, объективно говоря, не самую гибкую из известных реализаций того же самого ООП. Я не против смолтока, а Кея считаю одним из самых выдающихся людей за историю Computer Science. Но откровенно сектантскую пропаганду я видеть уже устал — это уже третье на моей памяти письмо примерно одинакового содержания.
G>>А если не хотите забивать себе голову теорией, то все гораздо проще и компактнее. ООП — это когда есть классы. _>А это вообще в корне не верно. Классы были в Симуле, откуда ООП и позаимствовало их как деталь реализации. Но ни в одном определении ООП их нет.
Вообще-то я пошутил, а ты сразу всерьез. Да знаю я, что неверно. Но человек чего хотел? Простоты и отсутствия шелухи? Вот ему простота на блюдечке. Цитату из Эйнштейна про простоту видал в начале письма? Это как раз тот случай, когда проще, чем это возможно.
И я боюсь, что больше половины разработчиков считают именно так. Отсюда, в часности, и появление дурацких статей типа "ООП потерпел неудачу", где речь идет о языках вроде С++ и Java, а автор сокрушается, что они таки не серебряная пуля. Я такие статьи совершенно спокойно игнорирую — мало-ли, что на заборах написано.
Здравствуйте, Шахтер, Вы писали:
Ш>Здравствуйте, AndreyFedotov, Вы писали: ...
Ш>Фаза первая) Никому никому никому. Ш>Фаза вторая) Никому никому никому, только ему одному. Ш>Фаза третья) Никому никому никому, только ему одному и его друзьям. Ш>Фаза четвертая) Всем всем всем. Ш>Фаза пятая) Кому кому кому.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, Шахтер, Вы писали:
Ш>>Здравствуйте, AndreyFedotov, Вы писали: ...
Ш>>Фаза первая) Никому никому никому. Ш>>Фаза вторая) Никому никому никому, только ему одному. Ш>>Фаза третья) Никому никому никому, только ему одному и его друзьям. Ш>>Фаза четвертая) Всем всем всем. Ш>>Фаза пятая) Кому кому кому.
AF> Сколько помню это было про студенток...
Да, но как-то перекликается со спецификациями доступа в C++.
Здравствуйте, Gaperton, Вы писали:
G>Вот как раз Erlang — это не объектная система ни в каком смысле, ни в классическом, ни в твоем. Кстати, авторы это языка тоже в этом уверены. А ты здесь путаешь народ. Я проверяю Erlang на соответсвие твоему определению, читай внимательно:
G>Базовый элемент языка Erlang как и любого другого функционального языка — функция (а не объект!), состояния у объектов нет (язык функциональный), а сообщениями обмениваются не объекты, а процессы, количество которых в реальной системе ограничено десятками тысяч (их нельзя использовать как объекты хотя-бы по этой, второстепенной причине!).
G>Кстати, "сообщение" в Erlang не приводит к вызову никаких методов, и тем более не возвращает результата. Ты просто не сможешь использовать процессы в роле объектов, потому как единственный способ доступится к процессу — это в свою очередь принять от него сообщение. Там сообщения — это наоборот данные, "объекты" произвольного типа (ты можешь послать другому процессу вообще любую структуру данных — например двоичное дерево), которые посылаются и принимаются примитивами SEND/RECEIVE, и диспетчеризуются полностью вручную. В конце концов, дизайн приложений на Erlang не является объектным. Могу прислать образцы кода, чтобы ты в этом убедился.
Ты достаточно узко понимаешь что есть посылка сообщения. Наподобие того, что полиморфизм часто понимается как наличие таблицы виртуальных методов.
The first Smalltalks were in the middle of the progression of
designs. The objects in Smalltalk-72, for example, implemented a kind
of top down recognizer that parsed the messages and responded. There
were no separate methods, and each object was essentially a looping
process (like a machine on the internet) waiting for a message to
parse.
This is very similar to where several Prolog derivatives got to later
on (including Erlang). Hewitt's Actors used this idea in many
interesting and important ways.
Здравствуйте, _vovin, Вы писали:
_>Здравствуйте, Gaperton, Вы писали:
G>>Вот как раз Erlang — это не объектная система ни в каком смысле, ни в классическом, ни в твоем. Кстати, авторы это языка тоже в этом уверены. А ты здесь путаешь народ. Я проверяю Erlang на соответсвие твоему определению, читай внимательно:
G>>Базовый элемент языка Erlang как и любого другого функционального языка — функция (а не объект!), состояния у объектов нет (язык функциональный), а сообщениями обмениваются не объекты, а процессы, количество которых в реальной системе ограничено десятками тысяч (их нельзя использовать как объекты хотя-бы по этой, второстепенной причине!).
G>>Кстати, "сообщение" в Erlang не приводит к вызову никаких методов, и тем более не возвращает результата. Ты просто не сможешь использовать процессы в роле объектов, потому как единственный способ доступится к процессу — это в свою очередь принять от него сообщение. Там сообщения — это наоборот данные, "объекты" произвольного типа (ты можешь послать другому процессу вообще любую структуру данных — например двоичное дерево), которые посылаются и принимаются примитивами SEND/RECEIVE, и диспетчеризуются полностью вручную. В конце концов, дизайн приложений на Erlang не является объектным. Могу прислать образцы кода, чтобы ты в этом убедился.
_>Ты достаточно узко понимаешь что есть посылка сообщения. Наподобие того, что полиморфизм часто понимается как наличие таблицы виртуальных методов.
Издеваешься? "Посылка сообщения" есть "посылка сообщения".
_>Почитай что Алан Кей говорит по этом поводу: _>http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-November/070157.html
_>The first Smalltalks were in the middle of the progression of
_>designs. The objects in Smalltalk-72, for example, implemented a kind
_>of top down recognizer that parsed the messages and responded. There
_>were no separate methods, and each object was essentially a looping
_>process (like a machine on the internet) waiting for a message to
_>parse.
Ну, если так... Любопытно посмотреть, как ты в Эрланге сделаешь аггрегацию процессов и передачу процесса как параметра. А также как у тебя получится скопировать процесс (что, понятное дело, не проблема с объектами). Уж очень странная штука состояние процесса в Эрланге, — это только стек вызовов и "локальные переменные" на стеке .
_>This is very similar to where several Prolog derivatives got to later _>on (including Erlang). Hewitt's Actors used this idea in many _>interesting and important ways. _>[/q]
_>Читай и анализируй.
Что мне анализировать? Намек: я знаю Erlang не по цитатам в статьях о Смолтоке.
Нажал "отправить" слишком рано. _>Ты достаточно узко понимаешь что есть посылка сообщения. Наподобие того, что полиморфизм часто понимается как наличие таблицы виртуальных методов.
Мне кажется, что ты наделяешь пару примитовов SEND/RECEIVE магической силой. Они могут быть реализованы в любом языке как библиотечные функции. Анализируй это! Доказательство от противного: тогда любой язык — объектный! Компрене ву? Не бросается в глаза легкое несоответствие?
_>
_>The first Smalltalks were in the middle of the progression of
_>designs. The objects in Smalltalk-72, for example, implemented a kind
_>of top down recognizer that parsed the messages and responded. There
_>were no separate methods, and each object was essentially a looping
_>process (like a machine on the internet) waiting for a message to
_>parse.
_>This is very similar to where several Prolog derivatives got to later
_>on (including Erlang). Hewitt's Actors used this idea in many
_>interesting and important ways.
Лирическое отступление. Erlang от пролога наследует только похожий синтаксис. Плюс, первый интерпретатор был написан на Прологе. Все. Это concurrent non-pure strict dynamically typed functional language. Там нет ничего такого, что нет в других функциональных языках (ну, может, кроме binaries, да и процессы есть не везде — но к прологу все это мало относится). Т. е. prolog derivative — это последнее, что можно сказать об Erlang.
Кей конечно уважаемый человек, но не стоит ссылаться на каждое его слово как на библию, и тупо повторять все за ним. Я мог бы зацитировать здесь статью Joe Armstrong-а, одного из авторов Эрланга, где он рвет на клочки объектный подход. Но я же не привожу этот бред, потому как из статьи очевидно, что автор нихрена не понял в ООП (как и Кей в ФП). Что не мешает старине Джо оставаться гуру в функциональном программировании (а Кею — в ОП).
G>Уж не знаю, насколько это страшно , но перечисленые языки (Haskell, CLOS и OCaml) поддерживают ООП . Даже в простом, интуитивном смысле, хотя это легко и проверить формально по классическому определению. Что говорит о плохо составленом определении Кея — оно недостаточно общо, настолько, что не работает на целом классе языков.
Открыл тут книжку "Developing application with Objective Caml", на главе "Object-Oriented Programming". В первом же абзаце:
A method is invoked by sending a message to an object. When an object receives a message, it performs the action or the computation corresponding to the method specified by the message.
Кстати, если я не ошибаюсь, в OCaml объекты _имеют_ состояние: в определение класса входят instance variables. Интересно, в других функциональных языках из перечисленных выше такая же ситуация?
Здравствуйте, serg_mo, Вы писали:
_>Здравствуйте, Gaperton, Вы писали:
G>>Уж не знаю, насколько это страшно , но перечисленые языки (Haskell, CLOS и OCaml) поддерживают ООП . Даже в простом, интуитивном смысле, хотя это легко и проверить формально по классическому определению. Что говорит о плохо составленом определении Кея — оно недостаточно общо, настолько, что не работает на целом классе языков.
_>Открыл тут книжку "Developing application with Objective Caml", на главе "Object-Oriented Programming". В первом же абзаце:
Респект!
_>
_>A method is invoked by sending a message to an object. When an object receives a message, it performs the action or the computation corresponding to the method specified by the message.
Ну да, про OCaml так можно сказать, т. к. там "методы" полиморфны по одному (неявному) аргументу — адресату "сообщения". Это, кстати, не снимает других "но" — OCaml строго типизирован, и там далеко не каждому объекту можно отправить любое сообщение. Т. е. объект не "сам решает", как его обработать . Но ладно, будем считать это придиркой и закроем на это глаза.
Есть пример поинтереснее. Попробуй придумать, как можно выразить в терминах сообщений вызов мультиметода (CLOS. Вызов, "виртуальный" по всем аргументам). Кому отправляется "сообщение"? Кто обрабатывает "сообщение"?
_> Кстати, если я не ошибаюсь, в OCaml объекты _имеют_ состояние: в определение класса входят instance variables.
Здесь необходимо пояснить. Наличие instance variables само по себе не означает наличие "состояния". Состояние предполагает наличие изменяемых членов класса, т. е. возможность их модификации. Суть же функциональных языков состоит в отсутствии у функций побочных эффектов (referential transparency), что отрицает возможность модификаций (destructive updates) — вместо этого объект пересоздается заново.
Но. OCaml не является "чистым" (pure) функциональным языком , и включает в себя полный набор императивных возможностей. В частности, в OCaml ты можешь объявить переменные класса как mutable, вот тут-то у объекта и появится состояние. Так что ты отчасти прав - объекты OCaml могут иметь состояние. Но программисту рекомендуется пользоваться этим мотивировано и как можно реже — только когда по другому нельзя или слишком сложно (рекомендация общая для всех ФЯ с побочными эффектами). Если же ты будешь пренебрегать этой рекомендацией, встает вопрос — зачем тогда вообще писать на OCaml с его функциональными возможностями. С# (ну или Smalltalk ) в руки — и вперед.
_>Интересно, в других функциональных языках из перечисленных выше такая же ситуация?
В CLOS — возможно, так как он тоже допускает побочные эффекты. Но там зато там есть мультиметоды , и это плюс одна причина, по которой он не подходит под определение Кея.
Наиболее интересны с этой точки зрения Haskell и Clean. Эти языки принципиально не допускает побочных эффектов — они "чисты". То есть там у объектов не может быть состояния даже в порядке исключения. И там есть поддержка ООП.
Если уж у тебя хватило духа отрыть мануал по OCaml, то могу посоветовать к чтению вот этот документ:
A Gentle Introduction to Haskell 98 http://www.haskell.org/tutorial/haskell-98-tutorial.pdf
Посмотри их систему типов, в частности type classes. Этот документ написан очень интересно, просто и понятно. Ты возможно, поймешь, о чем это я здесь, и (я почти уверен) получишь удовольствие от прочтения. Он действительно хорош — одно из лучших чтив на тему Computer Science. Советую читать подряд .
Здравствуйте, Sinclair, Вы писали:
S>Именно из этих трех групп появились секции private, protected и public. Ребята, они не от бога даны. Это всего лишь отражение структуры конкретного языка. Не было бы наследования — не было бы protected.
А в Delphi, вообще-то, их не три, а четыре. Еще есть published — это ой-ой-ой что такое!!! Если метод объявляется как published то информация о нем доступна в run-time, то есть во время выполнения программы этот метод можно вызвать по его имени, а не по индексу в таблице функций. Метаинформация, однако. На использовании этой метаинформации построена сама среда Delphi — там в design-time когда кидаешь на форму компоненты — они же все "живые", в смысле скомпилированы и их код запущен на выполнение, а как поиметь доступ к скомпилированному коду без метаинформации? Никак. В .NET метаинформация хранится для всего-перевсего, а в среде Delphi — только для того кто объявлен как published. Borland когда делала C++ Builder, то ей пришлось внести добавку в сам язык С++ — в него тоже было добавлено слово published, иначе VCL к С++ притянуть невозможно было. В последней версии Borland C++ Builder X — позиционирующейся как кроссплатформенная, Borland отказалась от дальнейшей поддержки VCL, я предполагаю именно из-за того чтобы не вносить изменения в язык С++.
Здравствуйте, iZEN, Вы писали:
ZEN>В моём случае мы обязываем будущие классы-наследники объявлять фактически final protected member. Причём мы не уверены, какие классы будут порождаться от нашего, но будем уверены, что member может быть переопределён только в наследниках и нигде больше (с областью видимости final protected, полиморфизм будет заканчиваться на близком наследнике однозначно).
Идея занятная. С точки зрения теории кристалла, такие ситуации являются слишком экзотическими для введения ключевых слов в язык. С другой стороны, мы можем изобрести возможность использовать произвольные критерии для сегрегации кода. В .Net есть специальная Code Access Security, которая выполняет ту же работу. Вот только делает это она динамически, и на основе разрешений, выданных коду администратором при развертывании. Не вижу принципиальной проблемы реализовать промежуточную схему. Например, ввести атрибут, задающий некоторый статически вычислимый предикат, и подшаманить компилятор так, чтобы он этот предикат проверял. Т.е. private превратится в SourceClass==MyClass, public превратится в true, internal превратится в SourceClass.Assembly == MyClass.GetAssembly, а то, что хочешь ты, превратится в SourceClass.BaseType == MyClass.
... << RSDN@Home 1.1.4 beta 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Gaperton, Вы писали:
G>3) Что остается? Smalltalk , все что на него похоже.
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.
G>Весь вопрос — зачем. Авторы (и читатели) большинства статей подразумевают под ООП отнюдь не определение Кея. Хотите, чтобы вас понимали правильно? Используйте устоявшуюся терминологию. Подобные подмены терминов ни к чему кроме путаницы не ведут. А утверждения из разряда "С# не поддерживает ООП" (к чему вы придете пользуясь определением Кея) так вообще вызовет у читателей истерику. Вам нужно такое определение?
Как-то некрасиво получается. Кей придумал нечто и назвал его ООП. Тут понабежали всякие разные и давай интерпретировать, кто во что горазд. В конце концов, оказывается что ООП — нечто совсем другое. И что прикажете делать автору?
[q] "Я уверен в том, что я не марксист" — К.Маркс[q]
Трурль wrote:
> Здравствуйте, Gaperton, Вы писали: > > G>3) Что остается? Smalltalk , все что на него похоже. > >
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.
> > G>Весь вопрос — зачем. Авторы (и читатели) большинства статей подразумевают под ООП отнюдь не определение Кея. Хотите, чтобы вас понимали правильно? Используйте устоявшуюся терминологию. Подобные подмены терминов ни к чему кроме путаницы не ведут. А утверждения из разряда "С# не поддерживает ООП" (к чему вы придете пользуясь определением Кея) так вообще вызовет у читателей истерику. Вам нужно такое определение? > > Как-то некрасиво получается. Кей придумал нечто и назвал его ООП. Тут понабежали всякие разные и давай интерпретировать, кто во что горазд. В конце концов, оказывается что ООП — нечто совсем другое. И что прикажете делать автору? > [q] "Я уверен в том, что я не марксист" — К.Маркс[q]
Все нормально.
Понимающие люди уже перешли на неформальный термин "объектный подход"
вместо "Объектно-недо-Ориентированное Программирование".
Здравствуйте, _vovin, Вы писали:
_>Автором концепии ООП является Алан Кей. Мотивацией создания ООП послужили два основных источника — SketchPad и Simula.
Дай, плиз, ссылку на истиочник данной информации. Почти уверен, что ты путаешь термин ООП и "объектое программирование" которое пропагандировал Кей.
_>Кое-что на эту тему можно прочитать здесь.
Смолток как раз не является ООЯ. Он как раз тот самый объектный. То есть исповедующих похожую, но несколько другую парадигму.
По большому счету языки можно делить на классовые и на прототипные. Но это не принято. А термин ООП на сегодня четко определен и не стоит птыаться его подменять даже от огромной любви к Смолтоку и т.п.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Vi2, Вы писали:
Vi2>Здравствуйте, Rumata, Вы писали:
Vi2>
R>>... Кто-то решил, что их должно быть 3, т.к. это "следует из инкапсуляции". Но, т.к. понятие самой инкапсуляции, как я понимаю, само четко не сформулировано, следствия из него имхо строить довольно опасно.
Vi2>Инкапсуляция — это доступность (или сокрытие) того, что имеет объект, для кого-либо, отличного от самого объекта.
Vi2>Количество состояний доступности определяется тремя словами "никому", "одному" и "всем". Если ты сможешь найти еще слово, которое не выражается из этих трех, то тебе будет слава и почет.
легко. например: "васе из трнтьего подьезда и еще пете"
Здравствуйте, Rumata, Вы писали:
R>Сразу просьба: не кидайте тухлыми овощами. =)
R>Пару месяцев назад задался целью узнать, что такое ООП. Максимум, что получилось — вышел на omg. Но там тоже толком ничего нет. Может быть all сможет показать мне четкую формулировку, что же такое этот самый ООП =)
тут ,как по мне, неплохое описание в разделе "Объектно-ориентированное программирование" Однако, следует делать поправку на то, что ресурс посвящен Smalltalk.
Здравствуйте, Rumata, Вы писали:
R>Пару месяцев назад задался целью узнать, что такое ООП. Максимум, что получилось — вышел на omg. Но там тоже толком ничего нет. Может быть all сможет показать мне четкую формулировку, что же такое этот самый ООП =)
Несколько не в тему. Но кто-то говорит, что ООП — это Объектно Озабоченный Программист. После рассмотра результатов некоторых пролетариев умственного труда склонен согласиться.
Здравствуйте, Rumata, Вы писали:
R>Вот например, всем известно, что бывают у объектов эл-ты public, private и protected. А почему только 3? Почему нет какого-нибудь четвертого?
Здравствуйте, Turtle.BAZON.Group, Вы писали:
TBG>Здравствуйте, Rumata, Вы писали:
R>>Вот например, всем известно, что бывают у объектов эл-ты public, private и protected. А почему только 3? Почему нет какого-нибудь четвертого?
TBG>В яве есть еще и default. Особенности реализации.
