Зачем нужно ООП

Я несогласен с «обычно». Под «сущность с состоянием» попадают и простые структуры с функциями. Характеристики, выделяющие объекты, - это self/this и открытая рекурсия. Обе реализуются на хаскеле.

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

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

Нет, ты их не видел IRL, иначе не порол бы такую чушь. Электрические цепи — это целиком и полностью состояния, и только они. ФП тут сосет настолько глубоко, что любая глубокая глотка могла бы позавидовать.

Пример реализации: http://lambda-the-ultimate.org/node/4569#comment-71821

Цепь состоит из блоков-объектов, которые получают некоторые данные, по команде запускают некий метод и меняют своё состояние.

Ну тут явные лишние сущности.

Более того, они имеют поля-состояния и когда питания нет.

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

И не нужны там никакие поля, сообщения и т д.

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

Это изолированность, компонентность и повторное использование кода.

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

Электрические цепи — это целиком и полностью состояния, и только они. ФП тут сосет настолько глубоко, что любая глубокая глотка могла бы позавидовать.

Садись, 2. Открывой учебник Баскакова, да прочитай главу про математические модели цепей, умника не корчи.

Ну тут явные лишние сущности.

Где?

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

А есть триггеры, ПЗУ и прочие штуки, которые хранят состояние и не могут быть функциями ни в каком виде.

Конечно можно извратиться и описать их функционально. Как и программы ООП компилируются в ассемблер где-то внутри. Но зачем?

Даже в sicp в третьей главе про объекты и состояния есть пример про электрические цепи.

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

Молодец, годный высер, садись 5.

и не могут быть функциями ни в каком виде.

Вообще-то могут. Есть функция задержки, например)

Описывают же как-то рекурсивные ЦФ.

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

И не нужны там никакие поля, сообщения и т д.

Вот тебе простейшая электрическая цепь:

to source______/ ____rele____lamp___ to source
to source_____________/ _____lamp2__ to source

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

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

Вне всякого сомнения, тут идеально подошла бы парадигма реактивного event-based программирования. Но я бы с удовольствием взглянул бы и на чисто-функциональную реализацию, lol, только без императивных костылей, плиз.

просто поля и вся фигня тут - лишние сущности, достаточно просто функций и данных.

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

Данные у тебя одни, входные, которые преобразуются в выходные.

Данные у тебя одни, входные, которые преобразуются в выходные.

Состояния каких нибудь озу ты где хранишь?

Это изолированность, компонентность и повторное использование кода.

программирование как вид деятельности не масштабируется

Господи, ну хоть кто-то сказал в этом треде.

Состояния каких нибудь озу ты где хранишь?

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

там по ссылке безпруфные кукареканья какой-то тупой мрази

Вообще-то ООП это Симула, и она была ну ни разу не для UI.

В те годы было много академических изысков :)

У чувака либо адовая каша в голове, либо, скорее всего, он троллит. После той ссылке «о вреде ООП» я бы вообще не связывался. Хотя, смеха ради, попроси его ссылку на его репозитории с кодом.

У тебя входные данные это замкнут или разомкнут ключ?

Так элементарно описывается, не?

Вот тебе на хаскиле, который я не знаю:

rele :: Int -> (Int, Int)
rele x = case x of
  1 -> (1, 0)
  0 -> (0, 1)

Java это когда MapModelTaskManagerPrototypeDatabaseMappingQueue и прочие SetterComposerMapAttributeAdvisorConcreteClone.

fixed for ya

Причина появления ООП в том, что оно ближе к пониманию человеком.

это в теории, на деле ООП это композиция по большей части и там уже примеры типа animal/dog/cat не катят и логики четкой особо нет.

А что я то - это Брукс еще надвое сказал

где ооп применимо?

как показывает 23991305139502391432139353465241161237767621 строк кода в опен сурсе - везде.

Ты толи совсем дурачек, то ли притворяешься. Нужно не описать, а реализовать — то-есть модулировать работу. А то что ты кукарекаешь, действительно, сродни математической демагогии. У меня есть яблоко, надо его разделить надвое. Ответ ФП-дегенерата: 1/2. Только от этого яблоко не разделится на две части. Нужны средства для этого.

переменные могут существовать

И где существует переменная, которая хранит состояние триггера? В какой функции, если каждая функция живёт только в момент прохождения сигнала через узел?

Понятно, что всегда можно найти плохой пример реализации.

Объекты, обменивающиеся сообщениями, - это явно гуманитарии придумали.

Когда в детстве пытался осознать эту фразу, никак не мог понять механизм «обмена сообщениями», пока, наконец, не дочитал, что «сообщение» — это просто вызов метода объекта.

модулировать

Что делать?

сродни математической демагогии

Ну а как же ты без математики это все моделировать собрался?

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

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

Такая «реализация» под силу младенцу или секретутке. В каком месте ты инженер тогда?

объект теперь это субъект раньше.

кстати, лично мне был бы нафиг не нужен с++, если б в си ввели наследование структур.

И где существует переменная, которая хранит состояние триггера? В какой функции, если каждая функция живёт только в момент прохождения сигнала через узел?

Нигде. Тебе нужна функция задержки, я же сказал.

если каждая функция живёт только в момент прохождения сигнала через узел?

Нет конечно, что за бред, у тебя функция от времени.

функция задержки

Какая нах*й задержка, если в ФП нет времени?

мм, да нет как раз, композиция применяется в любом опен сорс коде и разобраться в нем «быстро» исходя из просто «логики» не получится, все же ООП по мне так это в первую очередь «отсутствие дублированния через объекты», полиморфизм это уже следствие, а инкапсуляция это уже следствие необходимости изоляции и безопаности объектов от воздействия.

Почитай про историю ООП. Simula 68, smalltalk, C++, self и пр. И тогда вопросы некоторые уйдут. Далее можно взять Буча(первые главы до uml), а потом Б.Мейера и его «Объектно-ориентированное конструирование программных систем». Тогда вопросов не останется. Фанатиков(как сторонников, так и противников) не слушай.

Такая «реализация» под силу младенцу или секретутке. В каком месте ты инженер тогда?

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

А когда начнешь моделировать, ты в любом случае элементы будешь как функции представлять, как ты их по-другому сможешь описать?

Simula 67, сорри, сглючило.

Тебе нужна функция задержки, я же сказал.

А поподробнее? Я как человек от ООП понимаю так, что нечто запускает «функцию цепи», которая запускает функции над каждым элементом. Так где хранится текущее состояние элементов?

Для UI есть FRP. Так что и тут без ООП обойтись можно.

Функции - тоже объекты. Тут нет противоречия.

если в ФП нет времени

Ну приехали, в фп состояний нет, функцию от времени тебе кто запрещает запилить?

Так где хранится текущее состояние элементов?

Нигде. Когда ты моделируешь сигнал, ты же даешь не мгновенные значения на вход, а сигнал на определенном временном отрезке. Некая входная S(t), цепь описывается переходной функцией h(t), на выходе получишь свертку.

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

Я уже понял, что у тебя очень плохо все с пониманием прочитанного, когда ты прочитал «функциональное проектирование цепей» как «моделирование цепи с помощью функционального программирования».

Там безо всякой схемы все любому дебилу понятно по описанию.

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

Ты что же маленький, даже не понял, что делает эта цепь?

Ты что же маленький, даже не понял, что делает эта цепь?

Ты мне лучше модель этой цепи покажи. Мне интересно, как ты ее смоделируешь.

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

Ну а как же ты, малыш представляешь себе проектирование без моделирования? Типо, декларативно описал, КАК ДОЛЖНА работать схема, а реализацией пусть занимаются инженера? Это типа как принцесса на горошине, сказала, я хочу чтобы у меня было авто, чтоб ездило со скоростью такой-то такой-то, была полулимузином, полукабриолетом, покрашена была бы в серебристый металлик, и чтобы музыка вней была — это она спроектировала автомобиль, по-твоему? Хватит уже, у меня легкие уже от смеха отваливаются, иди лучше в ученики к Петросяну.

не могу

Ясно, слив засчитан.

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