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

S>>Открыть можно ящик стола, ящик Пандоры, Америку, окно, дверь, глаз, рот, душу... От того, что глагол 'открыть' применим ко всем этим существительным, абсолютно никак не следуют что все они имеют общего предка. Дверь и окно, если мы говорим о комнате, могут иметь предка ДыраВСтене или ЭлементИнтеръера или ЭлементПокраски или ГорючийМатериал или. То есть некую абстракцию, несущую общие ствойства этих предметов в контексте решаемой задачи.

M>Только в реальной жизни они этих предков не имеют, вот ведь засада.

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

Представьте – разруха, зима (не в Молдавии). Вы в холодной квартире, где нет не только что воды/отопления и света, но даже интернет не работает. Температура около нуля (спокойно, по Цельсию). Всё что у вас есть – это камин. Дров нет разумеется. Но вокруг стоят табуретка, деревянная полка, железная кровать и раритетная акустическая система Танной. Стерео! 1972 года выпуска.

Внимание, ставлю вам задачу – сколько времени пройдет, пока нормальный здоровый мозг, выделит общий класс ‘Полено’ из табуретки, полки и акустической системы Танной 1972 года? И при какой температуре окружающей среды это произойдёт. Влияет ли температура окружающего воздуха на способность мозга к обучению абстрагированию/выделению общих сущностей?

S>>>Открыть можно ящик стола, ящик Пандоры, Америку, окно, дверь, глаз, рот, душу... От того, что глагол 'открыть' применим ко всем этим существительным, абсолютно никак не следуют что все они имеют общего предка. Дверь и окно, если мы говорим о комнате, могут иметь предка ДыраВСтене или ЭлементИнтеръера или ЭлементПокраски или ГорючийМатериал или. То есть некую абстракцию, несущую общие ствойства этих предметов в контексте решаемой задачи.

M>>Только в реальной жизни они этих предков не имеют, вот ведь засада.
pkl>А вы в курсе, что бывают чисто виртуальные классы/методы и т.п.? Как вы предлагаете создать объект абстрактного класса? Вы наверное не шарите. У двери и шкатулки есть общий предок, но он абстрактный. Стрелять колотить.

А вы в кусрес, что в реальной жизни таких предков не существует?

S>Задач мне ставить не надо, право же, мне неловко бесплатно решать их для Вас...

S>Абстрагируйтесь-абстрагируйтесь...

А ну да. Внезапно «реальная жизнь прекрасно ложится на ООП и наоборот» первращается в «абстрагируйтесь»

S>Кто-то дёрнул метод ‘открыть’, во делов то. Пока для вас это не важно, вы можете не обращать на это никакого внимания.

Ага. То есть все сказки про то, как ООП отражает реальну жизнь являются строго сказками. Уже внезапно «неважно, кто дернул метод открыть». Ну-ну.

S>Ладно, допустим, для вас это всё-таки важно. Скажем, вы хотите начистить репу этому залётному чибису (накрайняк — соседу). Ну затребуйте в параметре какая сука вызвала метод ‘открыть’. Хозяин вы своему коду или не хозяин?

При чем тут хозяин-не хозяин? Хотя, я знаю при чем — попытка уйти с обсуждения куда-то не в ту степь.

S>Допустим чибис практически не виноват. Он, пролетая, дёргает все попадающие на пути двери (натура такая, ищет где нарваться на приключения). Некие двери открываются, некие нет. Усложним модель. Введём в дверь метод ‘воздействовать’ с некими параметрами типа (ё.пнул ногой, дёрнул за ручку, зацепил сапогом/бампером, пальнул из РПГ и так далее).

Только вот к реальной жизни это опять же не имеет никакого отношения.

S>Внутри метода тщательно анализируем угол приложения усилия и саму его величину и, о чудо, сами вызываем свой метод ‘открыть’, переводя сортир в паблик/стриптиз состояние. И вот... наша пикантная модель заиграла новыми красками. Любой сторонний объект может воздействовать, а мы, подумав/посчитав (да хоть эрлангом) вежливо открываем дверь. Всё живёт, всё крутится...

И не имеет никакого отношения к реальной жизни.

S>>>Открыть можно ящик стола, ящик Пандоры, Америку, окно, дверь, глаз, рот, душу... От того, что глагол 'открыть' применим ко всем этим существительным, абсолютно никак не следуют что все они имеют общего предка. Дверь и окно, если мы говорим о комнате, могут иметь предка ДыраВСтене или ЭлементИнтеръера или ЭлементПокраски или ГорючийМатериал или. То есть некую абстракцию, несущую общие ствойства этих предметов в контексте решаемой задачи.

M>>Только в реальной жизни они этих предков не имеют, вот ведь засада.

S>О нет, в реальной жизни они оч-чень даже имеют этих предков.
[skipped]

Ах, сколько слов ни о чем. Только вот «открыть дверь» не имеет отношения ни к «ДыреВСтене», ни к «ЭлементуИнтерьера» ни к любой другой фантазии.

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

M>Только вот к реальной жизни это опять же не имеет никакого отношения.
...
M>И не имеет никакого отношения к реальной жизни.

Отодвиньтесь вы уже от своего Эрланга и рассмотрите как прекрасна окружающая жизнь. Я медленно и на пальцах показал как просто моделируется действительность.

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

S>>>>Открыть можно ящик стола, ящик Пандоры, Америку, окно, дверь, глаз, рот, душу... От того, что глагол 'открыть' применим ко всем этим существительным, абсолютно никак не следуют что все они имеют общего предка. Дверь и окно, если мы говорим о комнате, могут иметь предка ДыраВСтене или ЭлементИнтеръера или ЭлементПокраски или ГорючийМатериал или. То есть некую абстракцию, несущую общие ствойства этих предметов в контексте решаемой задачи.

M>>>Только в реальной жизни они этих предков не имеют, вот ведь засада.

S>>О нет, в реальной жизни они оч-чень даже имеют этих предков.
M>[skipped]

M>Ах, сколько слов ни о чем. Только вот «открыть дверь» не имеет отношения ни к «ДыреВСтене», ни к «ЭлементуИнтерьера» ни к любой другой фантазии.

Что, правда? Опять всё что ООП не имеет отношения к жизни? Да забросьте вы свой дебильный Эрланг и оглянитесь вокруг... Как свободный человек.

Здравствуйте, мыщъх, Вы писали:

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

S>>Здравствуйте, мыщъх, Вы писали:

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


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

S>>Мдя...

S>>Открыть можно ящик стола, ящик Пандоры, Америку, окно, дверь, глаз, рот, душу...
М>сарказм неуместен. открытие двери и окна реализуется практически идентичным кодом. писать псевдокод лень, но будет что-то типа -- объект заперт? если да, то вставить ключ и отомкнуть. повернуть ручку и сделать pull/push в зависимости от флажка.

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

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

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

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

М>проблема в том, что общему предку трудно дать осмысленное название.

>> или ЭлементПокраски или ГорючийМатериал или. То есть некую абстракцию,
>> несущую общие ствойства этих предметов в контексте решаемой задачи.
М>сегодня один контекст, завтра -- другой. а хороший код позволит "подхватить" и ящик пандоры и много чего другого.

мыщъх, тут есть нюансы.

Скажем, открыть дверь и открыть банку пива, несколько разные вещи. В случае двери, мы говорми о предмете который делает дырку в другом предмете (это дверь). В случае открыть банку, мы говорим о предмете в котором делается дырка (банка). Если перевернуть адекватно, то в случае двреи банкой будет комната/дом. А в случае банки пива, дверью будет это вот колечко за которое мы дёргаем, дабы сделать в банке дырку. Эти вещи путать не нужно. Термин один, но семантика разная.

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

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

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

S>>>>Открыть можно ящик стола, ящик Пандоры, Америку, окно, дверь, глаз, рот, душу... От того, что глагол 'открыть' применим ко всем этим существительным, абсолютно никак не следуют что все они имеют общего предка. Дверь и окно, если мы говорим о комнате, могут иметь предка ДыраВСтене или ЭлементИнтеръера или ЭлементПокраски или ГорючийМатериал или. То есть некую абстракцию, несущую общие ствойства этих предметов в контексте решаемой задачи.

M>>>Только в реальной жизни они этих предков не имеют, вот ведь засада.
pkl>>А вы в курсе, что бывают чисто виртуальные классы/методы и т.п.? Как вы предлагаете создать объект абстрактного класса? Вы наверное не шарите. У двери и шкатулки есть общий предок, но он абстрактный. Стрелять колотить.

M>А вы в кусрес, что в реальной жизни таких предков не существует?
1) Если вы реальность ограничиваете только миром, доступным через чувственные ограны — то мне кажется сее есть органиченное понимание реальности. Ну ладно, это на форуме не обсудить — пасть порвётся от напряжения.
2) А вообще я был не в курсе, что мы говорим о полиморфизме, говоря про ООП. Что такое дверь как объект вроде бы ясно, а от чего она там может наследоваться — это немножко более широкая тема, которая даже не обязательна к обсуждению. Дверь — объект. Состояния имеет. Это мыслится просто и понятно. Чем не ООП? Я не считаю, что отодвигая вопрос наследования мы ОЧЕНЬ СИЛЬНО наносим ущерб идее ООП — объекты есть? Есть. Для соблюдения формальностей с наследованием рассмотрите дверь как базовый класс.

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

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


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

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

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

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

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

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

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


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


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

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

S>>

S>>class Дверь {
S>>  открыть();
S>>  закрыть();
S>>};

S>>Дверь дверь = new Дверь();

S>>дверь.открыть();
S>>дверь.закрыть();

S>>

M>Только это даже близко не относится к реальному миру. Потому что ты считаешь, что действие по открыванию двери принадлежат двери. Что, естественно, не так (за исключением автоматических дверей). Если в примере выше заменить «открыть дверь» на «выкинуть мусор» (с точки зрения человека относящиеся к одной категории — активное дейстиве над пассивным предметом), то твоя модуель вообще становится бредовой с точки зрения реального мира.

class Programmer
{
    open(Openable obj);
}

Programmer mamut = new Programmer();
mamut.open(fridgeDoor);
mamut.takeOut(beerBottle);

Так сойдет?

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

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

F>Programmer mamut = new Programmer();
F>mamut.open(fridgeDoor);
F>mamut.takeOut(beerBottle);

F>Так сойдет?
вношу правку:
mamut.takeOut(beerBottle).open();

исправьте свою иерархию, чтобы это работало. а то ведь неюзабельно....

Здравствуйте, мыщъх, Вы писали:

М>вношу правку:
М>mamut.takeOut(beerBottle).open();

М>исправьте свою иерархию, чтобы это работало. а то ведь неюзабельно....


а что должен возвращать метод takeOut()
?

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

Ф>Здравствуйте, мыщъх, Вы писали:

М>>вношу правку:
М>>mamut.takeOut(beerBottle).open();

М>>исправьте свою иерархию, чтобы это работало. а то ведь неюзабельно....
Ф>а что должен возвращать метод takeOut()
очевидно beerBottle. что еще он может возвращать?

это слегка иной тип наследования, но он очень удобен.
mamut.takeOut(beerBottle).open().drink().throw_out()

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

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

S>Внимание, ставлю вам задачу – сколько времени пройдет, пока нормальный здоровый мозг, выделит общий класс ‘Полено’ из табуретки, полки и акустической системы Танной 1972 года? И при какой температуре окружающей среды это произойдёт. Влияет ли температура окружающего воздуха на способность мозга к обучению абстрагированию/выделению общих сущностей?

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

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, Философ, Вы писали:

Ф>>Здравствуйте, мыщъх, Вы писали:

М>>>вношу правку:
М>>>mamut.takeOut(beerBottle).open();

М>>>исправьте свою иерархию, чтобы это работало. а то ведь неюзабельно....
Ф>>а что должен возвращать метод takeOut()
М>очевидно beerBottle. что еще он может возвращать?

да, точно, сорри
это было вполне логично

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, Философ, Вы писали:

Ф>>Здравствуйте, мыщъх, Вы писали:

М>>>вношу правку:
М>>>mamut.takeOut(beerBottle).open();


забавно всё это.
после takeOut() мы имеем систему beerBottle<->mamut
и это поинтереснее выключателя для лампочки.
Мамут здесь, например может эту самую бутылку швырнуть в оппонента.
Запишем, как бутылка.швырнись()???

а вот нифига!
интереснее выглядит вот такой подход:
мамут.Достать(бутылка)
мамут.ШвырнутьПредмет(топикстартер)

учитывая последнее получаем:
mamut.takeOut(beerBottle).open(beerBottle);

и всё равно меня смущает beerBottle в конце этой строки
mamut.takeOut(beerBottle).OpenCapacity()

М>тут drink() возвращает beerBottle и потому можно вызывать throw_out().
М>beerBottle.throw_out()

земля.Копайся()

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

M>>А вы в кусрес, что в реальной жизни таких предков не существует?
pkl>1) Если вы реальность ограничиваете только миром, доступным через чувственные ограны — то мне кажется сее есть органиченное понимание реальности. Ну ладно, это на форуме не обсудить — пасть порвётся от напряжения.
pkl>2) А вообще я был не в курсе, что мы говорим о полиморфизме, говоря про ООП. Что такое дверь как объект вроде бы ясно, а от чего она там может наследоваться — это немножко более широкая тема, которая даже не обязательна к обсуждению. Дверь — объект. Состояния имеет. Это мыслится просто и понятно. Чем не ООП? Я не считаю, что отодвигая вопрос наследования мы ОЧЕНЬ СИЛЬНО наносим ущерб идее ООП — объекты есть? Есть. Для соблюдения формальностей с наследованием рассмотрите дверь как базовый класс.

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

Samius> если табуретку намочить (или покрыть огнеупорным составом), то она внезапно поменяет базовый класс.
Принцип неопределенности базового класса

Mamut> Открыть дверь
Система "Открыватель — Дверь" находится в запутанном состоянии

SV> Как мало людей понимает ООП
Квантовые явления вообще мало кто хоть как-то заметно хорошо понимает

F>

F>class Programmer
F>{
F>    open(Openable obj);
F>}

F>Programmer mamut = new Programmer();
F>mamut.open(fridgeDoor);
F>mamut.takeOut(beerBottle);
F>

F>Так сойдет?

Тоже не совсем, потому что это является сильным упрощением. Если у нас не дверьхолодильника, а обыкновенная дерь, и ее открыло сквозняком, то скозняк тоже придется наделять методом open

M>>>>Только в реальной жизни они этих предков не имеют, вот ведь засада.
pkl>>>А вы в курсе, что бывают чисто виртуальные классы/методы и т.п.? Как вы предлагаете создать объект абстрактного класса? Вы наверное не шарите. У двери и шкатулки есть общий предок, но он абстрактный. Стрелять колотить.

M>>А вы в кусрес, что в реальной жизни таких предков не существует?
pkl>1) Если вы реальность ограничиваете только миром, доступным через чувственные ограны — то мне кажется сее есть органиченное понимание реальности. Ну ладно, это на форуме не обсудить — пасть порвётся от напряжения.

Кхм. То есть еще есть идеальный мир?

pkl>2) А вообще я был не в курсе, что мы говорим о полиморфизме, говоря про ООП.

Мы говорим о смешном утверждении, что «реальный мир прекрасно ложится на ООП и наоборот».

pkl>Что такое дверь как объект вроде бы ясно, а от чего она там может наследоваться — это немножко более широкая тема, которая даже не обязательна к обсуждению. Дверь — объект. Состояния имеет. Это мыслится просто и понятно. Чем не ООП? Я не считаю, что отодвигая вопрос наследования мы ОЧЕНЬ СИЛЬНО наносим ущерб идее ООП — объекты есть? Есть. Для соблюдения формальностей с наследованием рассмотрите дверь как базовый класс.

Рассмотрели. Дальше что?