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

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

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

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

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

Эта твоя модель никакого отношения к действительности не имеет.

M>>Нет, далеко не все. Процесс открывания двери ты так и не описал
pkl>А сей процесс разве не инкапсулируется в методах "открыть", "закрыть", мать их за ногу?

Может инкапсулироваться. Но, повторюсь, в контексте топика эти метод не имеют отношения к реальности.

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

M>>>Нет, далеко не все. Процесс открывания двери ты так и не описал
pkl>>А сей процесс разве не инкапсулируется в методах "открыть", "закрыть", мать их за ногу?

M>Может инкапсулироваться. Но, повторюсь, в контексте топика эти метод не имеют отношения к реальности.
Зачем повторяться всяким бредом?

M>>>>Нет, далеко не все. Процесс открывания двери ты так и не описал
pkl>>>А сей процесс разве не инкапсулируется в методах "открыть", "закрыть", мать их за ногу?

M>>Может инкапсулироваться. Но, повторюсь, в контексте топика эти метод не имеют отношения к реальности.
pkl>Зачем повторяться всяким бредом?

Где ты видишь бред? Бред пока у людей, которые неспособны подтвердить свой тезис, что ООП прекрасно моделирует реальность.

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



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>>Так сойдет?

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

Шо, опять?! Сильное упрощение?
Я уже приводил стандартный подход. Дверь наделяется методом 'воздействие'. Метод сам решает откроется она или нет.

По правде говоря — забавно. Какие-такие иные особенные волшебные подходы предоставляют другие методологии проектирования/программирования, что люди их практикующие могут эдак снисходительно потешаться над ООП? Дескать... ООП клоуны вы все, вот у нас о-о-о как всё круто! И действительность влёт полностью и реально моделирется, и упрощением моделей мы никогда не страдаем, и вообще лезгинку по щелчку как с куста.

Это что-ли малопопулярный Эрланг, который был изобретён лет на 10 раньше Джава вдруг вырос в такую мощную и культовую проектировочную дубину пока я тут спал? Да? Или старичок Хаскель заметно проклюнулся на свой дваццать какой-то там годок? Или никому неизвестный Немерле внезапно поутру попёр?

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


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

Так это без нас произошло. Нам надо только описать состояние двери (открыта). Мы же управляем сквозняком только косвенно, значит можем максимум сказать создатьСквозняк, а уж что он там наломает...

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

S>Давайте уже сразу с этим покончим — Господь Бог!
Полагаю, это надо читать как:

"Давайте уже сразу с этим покончим"
— Господь Бог.

Учитывая чудовищную бессмысленность творящихся в этой ветке холиваров,
заканчивать обсуждения надо именно так

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

S>Да. Это я неправильно сказал употребив фразу ...мозг работает... Никто не знает как он там себе работает. Скажем так, было замечено, что для понимания проблемы мозг "опускает" незначащие детали и оперирует только теми, которые важны для понимания проблемы. То есть делает некое абстрагирование, декомпозицию.
Абстрагирование и декомпозиция в программировании не являются эксклюзивными инструментами ООП и появились задолго до его появления.

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

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

try {
    mamut.open(fridge);
    mamut.drink(mamut.takeOut(fridge, beerBottle));
}
catch(CapacityExceededException e) {
    mamut.runToBath();
    mamut.throwUp();
}

Исключение кидает само-собой мамут, а не бутылка. Хотя если из mamut.open(fridge) вернуть холодильник, то мы очень близко подойдем к функциональному стилю:

    mamut.drink(mamut.takeOut(mamut.open(fridge), beerBottle));

тут уже один шаг до

    drink(takeOut(open(mamut, fridge), beerBottle));

Дело вкуса, короче...

Сокращение к-ва кода это довольно однобокое понимание ООП.

По крайней мере ООП может быть использована для лучшей читабельности. Это и декомпозиция и уменьшение связанности и т.п.

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

M>Расскажи, как ложится на ООП-парадигму такое банальное описание, как «открыть дверь». С нетерпением жду

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

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

R>Но самое неприятное — ООП слишком сильно концентрируется на сущностях и делает второстепенными действия.

Это не ООП концентрируется, а применятели.

R>но мы ведь так и не приблизились к решеню проблемы

Мы даже не приблизились к описанию того, что за проблему решаем, что характерно.

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

S>Если у вас в принципе мозг может оперировать лишь объектами при решении задач вроде там нахождения факториала, задачи о ферзях, моделировании физических процессов, то у вас ООПГМ.

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



S>>Давайте уже сразу с этим покончим — Господь Бог!
BS>это не понятие. это существительное , которое является обозначением для http://ru.wikipedia.org/wiki/%D0%91%D0%BE%D0%B3 . Читаем определение http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%BD%D1%8F%D1%82%D0%B8%D0%B5

Речь и шла о существительных. Слово 'понятие' было лишь одним из них. Вместо того, что бы ходить и старательно минусовать мои посты, лучше перечитайте тред.

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

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


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

S>>>Я исхожу из того, что человек называет окружающие предметы в терминах существительных (мозг его так устроен), и это ложится на существующую ООП парадигму.

M>>Расскажи, как ложится на ООП-парадигму такое банальное описание, как «открыть дверь». С нетерпением жду

LCR>Кстати, если-таки дверь открыть удастся, то я могу подкинуть ещё парочку задач:
LCR>1. Описать с помощью ООП как корова щиплет траву (там будет корова.щипать(трава), трава.бытьОщипанной(корова) или Природа.поедание(корова, трава)?).
LCR>2. Совсем хардкор, где бесполезность ООП лично для меня очевидна. Есть лужа (совсем необязательно являющаяся сечением шара), в лужу бросили камень (вектор скорости совсем необязательно перпендикулярным поверхности). Задача: описать поведение волн с течением времени.

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

Что интересно, люди понимающие ООП, как правило имеют неплохое представление и об ФП. А вот обратное — неверно. ФПшники тотально не понимают на каком уровне ООП работает. Откуда и всё эти наивные вопросы, которые им самим кажутся прикольными и типа ООП-тупиковыми. И тема очень ярко это показывает. 40 человек поставили плюс вашему посту, полагая что вы едко уели ООП. Хотя, на самом деле вы скорее продемонстрировали факт его полного непонимания.

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

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

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

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

Зачем мочить? Можно просто сжечь. И она поменяет свой статус.
В жизни всё постоянно меняется, и количество степеней свободы так велико, что приходится выбирать только критичные параметры с точки зрения задачи и отслеживать поведение только тех вещей, которые для данной задачи важны. Собсно эти все декомпозиции и есть ООП.

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



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>>Так сойдет?

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

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

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

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

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

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

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

вообще, объекту "мамут" необходим пул объектов, которые можно швырнуть. и метод "швырнуть" выбирает из них наиболее подходящий.


Ф>учитывая последнее получаем:
Ф>mamut.takeOut(beerBottle).open(beerBottle);
Ф>и всё равно меня смущает beerBottle в конце этой строки
Ф>mamut.takeOut(beerBottle).OpenCapacity()
вот примерно это я и предлагаю -- open может принимать в качестве аргументов как открыть, таймайт (в смысле как долго отрывать, прежде чем плюнуть и решить, что завтра докуем).

меня коробит, когда в питоне приходится писать f = open("demo.txt", 'rb');
путем легкой химии превратил это в f = "demo.txt".fopen('rb'). так красивше ИМХО.

суть в том, что теперь у меня работает это:
['demo1.txt', 'demo2.txt', 'demo3.txt'].fopen()

и оно возвращает список открытых файловых объектов,

соотвественно:
['demo1.txt', 'demo2.txt', 'demo3.txt'].fopen().fread()

возвращает список прочитанных данных. но это фигня, это только "сахар", а вот:

for lines in ['demo1.txt', 'demo2.txt', 'demo3.txt'].fopen()
print lines

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

Ф>земля.Копайся()
будет копаться и без смайлика. метод "копайся" посмотрит, что есть у земли, найдет первого встречного командира, который трахает машу, т.е. находится в состоянии idle и даст ему приказ "копать отсюда до ребута" и дальше объект "командир" будет копать ее хоть сам, хоть с бойцами.

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

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

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