LINUX.ORG.RU

Существуют ли иные модели ООП?

 , ,


1

3

На сегодняшний день известно 2 модели ООП. Назовем их условно, «сильная» и «слабая».

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

Вторая — основанная на лексических замыканиях.

К сожалению, вторая модель получила наибольшее распространение в современных языках программирования. Первая нашла свое воплощение лишь в очень малом количестве ЯП, из мейнстримных я знаю только JS и Ruby. Видимо, основная причина в трудностях эффективной реализации мощной модели, хотя, пример JS заставляет усомниться в этом. Другой причиной, может быть то, что средний программист не может понять сильную модель, тогда как слабую понимают почти все.

А вопрос такой: есть ли какая-нибудь альтернативная модель, некий третий путь. Тут следует пояснить, наверное, что я не провожу различия между смолтоковской классовой(smalltalk, ruby) и прототипной(js, self, io) моделями, условно считаем, что это то же самое, также я не провожу различия между замыканиями и java-like-классами, в данном случае (т.е. модель scheme в контексте примеров модели вычислений с окружениями из SICP === java-style etc), нутыпонел — я обобщил. Может быть что-то еще, принципиально отличающееся от этих двух, есть такое?


основанная на лексических замыканиях

смолтоковской классовой(smalltalk, ruby) и прототипной(js, self, io)

js, ruby

SICP ну ты понел.

anonimous, ну ты понел.

LongLiveUbuntu ★★★★★ ()

Говорю с анонiмусом

Объекты — в голове, а не в языке. При желании они есть хоть в C. Могу себе представить их в Forth. Следовательно, вопрос — ни о чём.

x3al ★★★★★ ()
Ответ на: Говорю с анонiмусом от x3al

Да, в любом ЯП можно писать фортран. Но абсолютно ясно, что никто писать не будет, кто может — тот возьмет более подходящий инструмент, основная же масса будет писать дефолтную хрень. Поэтому, вопрос как раз «о чем» — о проектировании, о массовом подходе к нему, а ответ вот Ваш, да, ни о чем.

oop ()
Ответ на: комментарий от oop

Начиная с определённого размера проекта язык становится пофиг из-за десятого правила Гринспуна. Какая разница, что там за реализация объектов была в нижележащем языке?

x3al ★★★★★ ()
Ответ на: комментарий от x3al

Ну ладно, вопрос был все равно не о языках. О моделях.

oop ()

К сожалению, вторая модель получила наибольшее распространение в современных языках программирования. Первая нашла свое воплощение лишь в очень малом количестве ЯП, из мейнстримных я знаю только JS и Ruby.

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

umren ★★★★★ ()

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

Вроде эти модели справляются, зачем еще новые нужны.

loz ★★★★★ ()

А что модель на основе замыканий не может быть в тоже время с передачей сообщений? Передача сообщений, это скорее аспект реализации обьектоной модели, того как комуницирует обьекты, через таблицу вирутальных функций, или через message passing.

dizza ★★★★★ ()

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

ziemin ★★ ()
Ответ на: комментарий от dizza

Может, но это все равно другая модель. Можно считать частным случаем, или подмножеством первой.

oop ()
Ответ на: комментарий от ziemin

методы в функциональном стиле

Вы хотите сказать, что мозгу не нужно запоминать состояния, когда он «вычисляет»?

это бесконечное наследование

Это что такое?

oop ()
Ответ на: комментарий от oop

Вы хотите сказать, что мозгу не нужно запоминать состояния, когда он «вычисляет»?

Нет. Сколько состояний ты запомнил формулируя мысль при том, что сверхоперативная память хранит всего 7 объектов?

Это что такое?

Совершенно дикие обобщения. Например клиентом ЛОРа может быть любой веб-браузер. Традиционный подход состоит в том, чтобы писать css под каждый вариант. Вариант с бесконечным наследованием подразумевает написание класса и наследников для каждого элемента html страницы для каждого варианта браузера. Т.е. классы сами решают, как им формировать свой элемент. И на кажный такой базовый элемент пишется фабрика, создающая элементы в зависимости от UserAgent. Это тонны кода, но именно так работает мозг. Дело в том, что доступ к элементу (реализован как «вспоминание») очень дешёвая операция. И на ней реализованы уже все остальные (даже сложение). Именно поэтому думать неохота. Просто самые, казалось бы элементарные, операции реализованы в башке через вспоминание. А это дикий оверхед. Всё равно что писать функцию без побочных эффектов.

ziemin ★★ ()

А почему «сильная» и «слабая»? Они не эквивалентны?

bogus_result ()

обучаю не узнаваемому стилю речи,недорого))

MiniRoboDancer ★☆ ()
Ответ на: комментарий от bogus_result

Они не эквивалентны по своим выразительным возможностям.

oop ()

вот ты скажи, неужели тебе настолько плохо?

reprimand ★★★★★ ()
Ответ на: комментарий от bogus_result

Смотри. Допустим у тебя есть класс. от него наследуются экземпляры. тебе надо динамически определить суперкласс нал этим классом, в зависимости, например, от юзеринпута, таким образом, естественно, чтобы все экземпляры тут же унаследовали от этого суперкласса. Наличие/отсутствие этого суперкласса, должно зависеть исключительно от юзеринпута, если допустим, юзер сказал no, его не должно быть. Как ты реализуешь такую логику в рамках второго подхода?

oop ()
Ответ на: комментарий от ziemin

сверхоперативная память хранит всего 7 объектов?

Да хоть 1. Но хранит же.

Просто самые, казалось бы элементарные, операции реализованы в башке через вспоминание. А это дикий оверхед

Это кеширование по сути. Человек не вычисляет что-то заново, просто вспоминает результат. И тут нет оверхеда по вычислениям, тут оверхед по памяти. Человеческая память дешева, в отличии от вычислений/размышлений. И всплывают теже проблемы что и с кешированием — неактуальность информации на текущий момент. Отсюда и зомбирование — зачем думать самому, раскапывать что-то, если дядя по телеку и так все скажет, в книжках давно все написано, в инструкциях. До сути вещей мало кто доходит, человеческий мозг становится как матрица, на которую просто кто то пишет информацию.

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

oop ()
Ответ на: комментарий от bogus_result

Person=function(name){
  this.name=name
}
Person.prototype.skin="white"

person=new Person("Jack")

console.log(person.skin, person.hair)

getDataFromUser=function(user_input){
   if(user_input==="yes") {
   superClass=function(){}
   superClass.prototype.hair="black"
   Person.prototype.__proto__=superClass.prototype
}
}

getDataFromUser("yes")

console.log(person.skin, person.hair)

//  white undefined
//  white black
oop ()
Ответ на: комментарий от ziemin

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

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

oop ()

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

bogus_result ()
Ответ на: комментарий от oop

Как ты реализуешь такую логику в рамках второго подхода?

Точно так же, как и в рамках первого. Подходы же эквивалентны - замыкания можно рассматривать как вариант message-passing'a, message-passing - как вариант замыканий.

anonymous ()
Ответ на: комментарий от ziemin

наиболее соответствующая работе мозга модель это бесконечное наследование и методы в функциональном стиле

Бесконечное наследование? Что это?

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

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

anonymous ()

А вопрос такой: есть ли какая-нибудь альтернативная модель, некий третий путь.

CLOS, и вообще идея обобщённых функций. Смолтолковская модель тривиально реализуется на CLOS, а обратное неверно.

monk ★★★★★ ()
Ответ на: комментарий от erzent

а почему ооп под с++ есть а под с нет

Есть. https://ru.wikipedia.org/wiki/GObject

Или в самом языке? Тогда «а зачем?». В scheme тоже ооп в языке нет. Но реализуется при необходимости с любой нужной семантикой.

monk ★★★★★ ()
Ответ на: комментарий от oop

Как ты реализуешь такую логику в рамках второго подхода

Также как и в рамках первого. После юзеринпута придётся переопределять класс. В той же Scheme делается достаточно тривиально (на самописном ООП на замыканиях).

monk ★★★★★ ()
Ответ на: комментарий от anonymous

Подходы же эквивалентны - замыкания можно рассматривать как вариант message-passing'a, message-passing - как вариант замыканий.

Не совсем. При передаче сообщений есть понятия «обработка неизвестного сообщения» (как в Smalltalk и Ruby) и «очередь сообщений» (как в Erlang).

monk ★★★★★ ()
Ответ на: комментарий от monk

А где вы нашли переопределение класса в моем коде? Я измннил только одно поле.

oop ()
Ответ на: комментарий от monk

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

stevejobs ★★★★☆ ()
Ответ на: комментарий от monk

Не совсем. При передаче сообщений есть понятия «обработка неизвестного сообщения» (как в Smalltalk и Ruby) и «очередь сообщений» (как в Erlang).

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

oop ()
Ответ на: комментарий от oop

Легко это реализуется, см. Руби, или прототипное ООП в JavaScript, да и тупо на замыканиях в лиспе такое сделать можно. Короче, я понял про какие две модели идет речь: статическое ооп и динамическое, замыкания тут вообще ортогональны, нечего их приплетать. Ну да, в том же Руби ооп динамичное, можно менять тип в рантайме, можно менять суперкласс в рантайме. А в жабке наследование compile time, ничего не поделаешь.

dizza ★★★★★ ()
Ответ на: комментарий от stevejobs

Плюс миллион, вон в жаваскрипте подход типа, нужны классы, слепи сам привел к тому, что есть овер9000 различных реализаций.

dizza ★★★★★ ()
Последнее исправление: dizza (всего исправлений: 1)
Ответ на: комментарий от dizza

Легко это реализуется, см. Руби, или прототипное ООП в JavaScript,

Алло, вы читали стартовый топик? Я отношу RUBY и JS к первой модели, разумеется

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

нет.

oop ()
Ответ на: комментарий от dizza

привел к тому, что есть овер9000 различных реализаций.

Это идет от непонимания Ъ. Классы там действительно не нужны. Там надо писать как в селфе и IO, в идеале. Но большинство пишущих на JS не то не другое, отсюда и идет эта мастурбация.

oop ()
Ответ на: комментарий от oop

не то не другое

не понимают ни то ни другое

//fixed

oop ()

На самом деле существует два модели объектной декомпозиции: основанные на тайп-классах и сломанные.

Deleted ()
Ответ на: комментарий от oop

Нужны, сорри, ты просто сам не до конца в теме разобрался. Разница между классовым ооп, и протоипным в том, что в прототипном ооп протипом может быть любой обьект, а в классовом - только обькт-класс. Т.е. можно свести классы просто к частному случаю прототипов. НО! Этот самый частный случай является и самым частым кейсом. По сути 99% всех обьектных моделей в JS являются наколеночной реализацией классов. И нужен сахарок для задания. Который уже готовы запилить

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

dizza ★★★★★ ()
Последнее исправление: dizza (всего исправлений: 1)
Ответ на: комментарий от oop

Я отношу RUBY и JS к первой модели, разумеется

Сам выдумал какую-то кривую классификацию, сам чего-то куда-то отнес. ОООК...

dizza ★★★★★ ()
Ответ на: комментарий от dizza

Разница между классовым ооп, и протоипным в том, что в прототипном ооп протипом может быть любой обьект, а в классовом - только обькт-класс.

Да, но это только в сильной модели.

Т.е. можно свести классы просто к частному случаю прототипов.

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

oop ()
Ответ на: комментарий от dizza

Я ничего не выдумывал. Основная разница между моделями именно в этом. Все существующие модели являются частными случаями либо того, либо другого(в основном — другого)

oop ()

oop, ответь, в каком классе учишься?

unt1tled ★★★★ ()
Ответ на: комментарий от oop

Очевидно, что если что-то с блекджеком и шлюхами эквивалентно чему то без оных, надо писать без них.

Юношеский максимализм детектед. Сущность тут не лишняя, так как убирает массу ручной работы.

dizza ★★★★★ ()
Ответ на: комментарий от dizza

Сущность тут не лишняя, так как убирает массу ручной работы.

Кого???


Object.prototype.clone=function(){return Object.create(this)}

////////////////////////////////////////////////////////////
//This SHIT

Person=function(name){
  this.name=name
}
Person.prototype.skin="white"

person=new Person("Jack")

console.log(person.skin, person.hair)

getDataFromUser=function(user_input){
   if(user_input==="yes") {
   superClass=function(){}
   superClass.prototype.hair="black"
   Person.prototype.__proto__=superClass.prototype
}
}

getDataFromUser("yes")
console.log(person.skin, person.hair)

//////////////////////////////////////////////////////////
//VS

person={skin: "white"}
person1=person.clone()
person1.name="Jack"
console.log(person.skin, person.hair)
getDataFromUser=function(user_input){
   if(user_input==="yes"){super_={hair: "black"}; person.__proto__=super_}
}

getDataFromUser("yes")
console.log(person.skin, person.hair)

// ::: white undefined
// ::: white black
// ::: white undefined
// ::: white black
Это я тут еще классы не оформил нормально, надо восстанавливать ссылки на конструкторы, и прочий гемор, те раельно еще на треть увеличится.

oop ()
Ответ на: комментарий от oop

Второй пример из разряда quick-and-dirty, такое не годится. Первый пример правильный, но таки да, раздутый, поэтому нужен сахарок для классов.

dizza ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.