Здравствуйте, Воронков Василий, Вы писали:
AVK>>Ага, все просто когда наконец мозги себе поломаешь. Ну так и в ООП тоже все просто в таком разрезе.
ВВ>Так обо что именно ломаются мозги? Можно все-таки это как-то объяснить? Линк на твой взгляд тоже взрывает мозг?
До определенного момента, если не вникать, нет. Потом — да. Я это лично наблюдал, к примеру, на Платформе 2006, кажется, года, когда почти весь зал просто подвис через какое то время на нашем с IB докладе про LINQ. Сейчас такого эффекта уже нет, попривыкли.
А в функциональных языках монады существенно более бесчеловечны, чем специально заточенный под конкретные задачи линк.
AVK>>А я этого нигде и не писал.
ВВ>Ты писал, что код станет недостаточно абстрактным.
Где?
ВВ>И мне не очень понятно, почему ты считаешь это подпорками
Потому что это подпорки к базовой концепции ФВП+иммутабельность. Большая часть вещей выражается только через это, но неудобно.
ВВ>>>Они просто позволяют писать короче и выразительнее. AVK>>А ФП и ООП в целом, это тоже про короче и выразительнее. ВВ>Остается понять, у кого это получается лучше.
И это очень непростой вопрос. Одно знаю точно, крайности типа как у Клапауция или у Икемефулы, точно далеки от реальности. Моя ИМХА — у ООП получается лучше начиная с компонентов и выше по абстракции, у ФП — оттуда же ниже.
ВВ>Здесь, видимо, неплохо бы объяснить, чем же хуже, и о каких бревнах речь.
Все что я хотел, я уже сказал. Если тебе не нравится моя точка зрения, это вовсе не означает что я неправ или чего то не сказал.
ВВ>Я вот замечаю обратное
А я нет. Дальше то что? Опять скатываемся в субъективно-экспертный подход? Да, если мы цепочку данных иммутабельно трансформируем, ФП скорее всего даст более короткий и понятный код. Но вот, к примеру, для дизайна GUI фреймворков все что я в функциональном мире видел, это либо подточеный под ФП классический ОО подход, либо такие страшные чудовища, да еще и без дизайнера, что мама дорогая. С дизайном распределенных систем у функционального подходя я тоже каких то особых прорывов не видел. И т.д.
ВВ>Ну если мы не выходим за рамки ФП, то это никак не может являться новой концепцией.
Это все спор о терминах. Не нравится слово "концепция", замени на "сущность".
ВВ>В ООП же, для сравнения, у нас действительно появляются подпорки. Даже банальные статические методы уже выходят за рамки ООП.
Нет, статические не выходят, потому что никаких проблем ООП не решают.
ВВ>Современные ОО языки вообще развиваются по принципу — постоянно упираемся в неудобство и тяжеловесность ООП
Что характерно, функциональные языки, имеющие хоть отдаленное отношение к промышленному применению, тоже.
ВВ>Я чего-то тут явно не понимаю.
Скорее не хочешь.
... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>
Здравствуйте, Klapaucius, Вы писали:
K>Отлично, пошли в ход убедительные аргументы за ООП. Начинаем с голословного утверждения о моей неадекватности.
Какая, нафик, неадекватность? Сочиняешь на ходу? Я тебе, помнится, прямой вопрос задал, про ФП vs ООП. Ты сперва повилял хвостом, но потом таки сказал, что считаешь что ФП безусловно лучше и перспективнее ООП.
K>Во-вторых, вы легко можете ознакомится со статьями лучших экспертов по этим вопросам с помощью сети интернет.
Только там таких статей, что за, что против ООП, что можно найти любую заранее заданную точку зрения.
K>Объективно. Формальное описание нетривиального ООП — это высшая точка TAPL K>Это формальное описание требует F^omega_sub K>Самое же обидное, что при такой сложности извлекать из этого формального описания затруднительно.
Одна проблема — формальное описание интересно в основном только математикам и любителям CS. А вот, к примеру, у обычных чертежей, графических, тоже никакого формального описания нет. Но что то пока никто не перевернул инженерный мир их афигительной заменой. Да и в программировании чистый незамутненный ФП по прежнему на задворках отрасли прозябает.
K>Комбинатор в ФП — это обычная функция, которую можно применить к другим и получить нужную "комбинацию" функций.
Спасибо тебе, КО.
K>Нельзя скомбинировать объекты послав им какие-то "сообщения" — можно только произвести "комбинирование" в уме и записать его результат в коде.
А наследование, агрегация, композиция, это, по твоему, не комбинирование?
AVK>>приходится даже на нижнем уровне вводить всякие подпорки типа карринга,
K>Почему карринг — подпорка?
Потому что без него объем писанины возрастает.
AVK>>туплов, АлгТД и т.п.
K>Туплы — это и есть АлгТД.
Нет. Туплы это просто набор значений, кортеж в РА. А АлгТД обязан иметь дискриминант.
K>Претензия к "автоматическому протягиванию" тайпклассов через неявный параметр — это претензия к дополнительной сущностности того же уровня, что претензия к неявному this в ООП.
В какой то мере, да. Но я нигде и не писал, что ООП идеален.
... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>
Здравствуйте, Sinclair, Вы писали:
S>Это будет нарушением SRP.
И чо?
Индусы код не поймут?
Система работать не будет?
Цена поддержки многократно вырастет?
Чувству прекрасного будет нанесен невосполнимый урон?
S>То получится так называемая Anemic Model, в которой логика написана так, что её легко понять и отладить, без попыток сделать "чёрными ящиками" сущности, лишённые тонкостей внутренней структуры.
Выделенное плохо?
Подчеркнутое обязательно?
>anemic model: >"Logic cannot be implemented in a truly object-oriented way"
> То что мы мыслим объектами — не означает, что этот тип мышления самый лучший. Под него заточнен наш мозг — потому что он развивался в направлении улучшения взаимодействия с реальными физическими объектами и предсказания их поведения.
Человек мысли не объектами. Мыслительный процесс человека образный, как раз ближе к ФП.
Мозг это в основном память. В определенных структурах запечатлеваются образы. Берем простой пример — это машина, она зеленая. Объект и свойство? Нихрена.
"Это машина" — ассоциативным запросом выбирается из долговременной памяти образ машины в структуры формирующие образ. Либо сразу образ зеленой машины если образ конкретной зеленой машины (где зеленое это не свойство), либо образ какой-то пока еще не зеленой машины. Теперь нужно перейти к зеленой машине. Дергаем метод покрасить образа машины?? Нихрена. "Зеленый", это отдельный образ. Переход к зеленой машине, это ассоциативный запрос образ машины + образ зеленая => выбирается из долговременной памяти ряд ассоциаций, из которой выбирается образ зеленой машины в те же структуры работы с образами, либо частично затирая предыдущий образ, либо формируя новый образ в этих структурах. Это типично функциональный подход.
ООП, это примерно такой же процес, только структурно более сложный, и в струтурах больше привычных к логическому мышлению. То есть дальше от простого естественного способа мышления. Переход же к ООП от естественного образного мышления, это уже как переход от "бей ломай" к писменности.
> Я пытался поддержать мысль, но получил возражение. В недоумении.
Пытаюсь донести мысль, что в программировании больше синтеза, чем моделирования как такового.
> А рисование формочек — это не совсем и программирование.
Аргумент Но вот только кода, выполняющего далекие от модели основной задачи функции, внезапно больше.
Здравствуйте, vdimas, Вы писали:
V>В этом и состоит моя ирония, т.к.:
Мне так кажется, кроме тебя самого никто твоей иронии не понял.
V>- по определению чистых ф-ий им не важен порядок вычисления операндов;
Не важен.
V>- ленивость вычислений в чистом ФП не играет никакой рояли, можно считать ленивость подробностью реализации, то бишь семантически её нет;
Да.
V>- но для случая ветвления на if-then-else или ветвления на ПМ (что одно и тоже семантически), та самая ленивость, в сочетании с де-факто порядком вычисления аргументов, начинает играть рояль.
Нет, не начинает.
V> Некие выражения вычисляются заведомо РАНЬШЕ других
Ну и что? Это не приводит к ни к каким сайд-эффектам.
AVK>>Превосходно. Итого, из трех базовых конструкций в ФП две отсутствуют.
V>Заблуждение.
Факт.
AVK>>А логические ветвления присутствуют, наверное, в любой парадигме. V>Предположу, что только у наследованных от структурной. V>Например, в логическом программировании никакого ветвления нет.
Есть. Предикаты как раз ветвление для тел правил и задают.
V>>>Про последовательное исполнение в Хаскеле — do-стрелки. AVK>>А при чем тут Хаскелл? V>А чтобы сферических коней не гонять туда-сюда.
Если обсуждать концепции, то таки надо их и обсуждать, а не конкретную реализацию.
V>Наличие рекурсии в языке в сочетании с ветвлением даёт цикл.
Нет, не дает. Кури определение чистоты. Цикл не может быть чистым, рекурсия может.
V>[q] V>* цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла).
А теперь включаем моск и осмысливаем написанное. Если при последовательном исполнении можно придумать условие, которое изменится на очередной итерации внутри одной функции — налицо сайд-эффект, которого в чистом ФП быть не может по определению. В то же время при чистой рекурсии любое условие всегда будет давать один и тот же результат для заданных аргументов, и каждая последующая итерация вызывает функцию с другими аргументами, так что условие чистоты на 100% соблюдается.
Меня совершенно потрясает, что ты местами забираешься глубоко в хитрые детали, а местами демонстрируешь зияющие пробелы в базовых знаниях.
V>И да, изначально далеко не все языки позволяли рекурсивные вызовы. Вот как раз в ф-ых языках она и появилась в кач-ве способа организации цикла.
Я, честно, затрудняюсь назвать хотя бы один императивный язык без рекурсии. А ты?
... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>
Здравствуйте, grosborn, Вы писали:
>> То что мы мыслим объектами — не означает, что этот тип мышления самый лучший. Под него заточнен наш мозг — потому что он развивался в направлении улучшения взаимодействия с реальными физическими объектами и предсказания их поведения.
G>Человек мысли не объектами. Мыслительный процесс человека образный, как раз ближе к ФП. G>Мозг это в основном память. В определенных структурах запечатлеваются образы. Берем простой пример — это машина, она зеленая. Объект и свойство? Нихрена. G>"Это машина" — ассоциативным запросом выбирается из долговременной памяти образ машины в структуры формирующие образ. Либо сразу образ зеленой машины если образ конкретной зеленой машины (где зеленое это не свойство), либо образ какой-то пока еще не зеленой машины. Теперь нужно перейти к зеленой машине. Дергаем метод покрасить образа машины?? Нихрена. "Зеленый", это отдельный образ. Переход к зеленой машине, это ассоциативный запрос образ машины + образ зеленая => выбирается из долговременной памяти ряд ассоциаций, из которой выбирается образ зеленой машины в те же структуры работы с образами, либо частично затирая предыдущий образ, либо формируя новый образ в этих структурах. Это типично функциональный подход.
Про воссоздание образа очень занятно, проблема только в том, что ты описал воображение а не мышление.
> либо частично затирая предыдущий образ, либо формируя новый образ в этих структурах.
"Затирая" тут как бы не совсем правильно написал. Когда один образ заменяется другим, это не значит что он попадает в те же нейроны. Но для простоты понимания можно и так.
> Про воссоздание образа очень занятно, проблема только в том, что ты описал воображение а не мышление.
Это общий механизм мышления. Логическое мышление построено на этом же принципе, но структурно сложнее и с непринципиальными вариациями. Мозг это ассоциативная память, любое мышление это последовательность снимков, наборов образов. Вообще добиться того, что бы следующий снимок не накладывался на предыдущий и не разрушал его, а это требуется для логического мышления, это человеку специально приходится приучиваться и напрягаться и формировать специальные, контролируемые образы. А в ООП просто Машина.Цвет = Зеленый, никакого риска разрушения образа объекта.
В общем естественное мышление и ООП это не рядом.
.
Здравствуйте, AndrewVK, Вы писали:
AVK>До определенного момента, если не вникать, нет. Потом — да. Я это лично наблюдал, к примеру, на Платформе 2006, кажется, года, когда почти весь зал просто подвис через какое то время на нашем с IB докладе про LINQ. Сейчас такого эффекта уже нет, попривыкли. AVK>А в функциональных языках монады существенно более бесчеловечны, чем специально заточенный под конкретные задачи линк.
Ну раз к линку попривыкли, наверное, и до монад не так много осталось. Или линк есть абсолютный предел того, что может выдержать сознание рядового программиста? Наверное, все же все не так печально.
AVK>>>А я этого нигде и не писал. ВВ>>Ты писал, что код станет недостаточно абстрактным. AVK>Где?
Так и я про то, что для удобства в ФП точно так же приходится вводить ряд подпорок, потому что без них код станет слишком многословным и недостаточно абстрактным.
ВВ>>И мне не очень понятно, почему ты считаешь это подпорками AVK>Потому что это подпорки к базовой концепции ФВП+иммутабельность. Большая часть вещей выражается только через это, но неудобно.
Ну можешь считать это подпорками, если тебе так хочется. Странно еще, кстати, что ты ПМ не вспомнил. Непонятно только, что это тебе дает. Ты хотел только чистую лямбду увидеть? Это действительно неудобно. Но здесь ничего такого нового в ФП не привносится же, ФП не становится менее чистым. АлгТД те же в общем ортогональны ФП. А вот статические методы как раз очень даже противоречат ООП с его объектами и поведениями.
ВВ>>Здесь, видимо, неплохо бы объяснить, чем же хуже, и о каких бревнах речь. AVK>Все что я хотел, я уже сказал. Если тебе не нравится моя точка зрения, это вовсе не означает что я неправ или чего то не сказал.
Точку зрения неплохо чем-либо аргументировать. Ты же ожидаешь от других подобного? А так — польза-то какая? Ты высказал свою точку зрения, я — свою. Ну и все, можно расходиться по домам.
ВВ>>Я вот замечаю обратное
AVK>А я нет. Дальше то что? Опять скатываемся в субъективно-экспертный подход? Да, если мы цепочку данных иммутабельно трансформируем, ФП скорее всего даст более короткий и понятный код.
ФП это далеко не обязательно про иммутабельность.
AVK>Но вот, к примеру, для дизайна GUI фреймворков все что я в функциональном мире видел, это либо подточеный под ФП классический ОО подход, либо такие страшные чудовища, да еще и без дизайнера, что мама дорогая. С дизайном распределенных систем у функционального подходя я тоже каких то особых прорывов не видел. И т.д.
Ну в дизайне распределенных я вообще что-то ООП ооочень давно не видел. UI будет.
ВВ>>Ну если мы не выходим за рамки ФП, то это никак не может являться новой концепцией. AVK>Это все спор о терминах. Не нравится слово "концепция", замени на "сущность". ВВ>>В ООП же, для сравнения, у нас действительно появляются подпорки. Даже банальные статические методы уже выходят за рамки ООП. AVK>Нет, статические не выходят, потому что никаких проблем ООП не решают.
Как же не решают. Решают стандартную проблему — "неудобно". Причем это вам не тюплы в ФП, статические методы как раз явно вступают в интерференцию с ООП.
ВВ>>Современные ОО языки вообще развиваются по принципу — постоянно упираемся в неудобство и тяжеловесность ООП AVK>Что характерно, функциональные языки, имеющие хоть отдаленное отношение к промышленному применению, тоже.
Что, тоже? ФЯ упираются в тяжеловесность ООП? Что-то я вообще не понял, о чем ты.
ВВ>>Я чего-то тут явно не понимаю. AVK>Скорее не хочешь.
Нет, я не действительно не понимаю. ФП более самодостаточная концепция, чем ООП. Да и собственно та форма рантайм полиморфизма, которая обеспечивается ООП, прекрасно достигает и ФП, причем родными средствами. Причем даже императивный код на Хаскелле более выразителен, чем на шарпе. Это в do нотации, про стрелки я уж молчу. Есть конечно и свои проблемы, но они решаются со временем.
А что происходит в ООЯ? Появляются мегамонстры вроде Скалы? И что это дикая солянка — наше светлое будущее?
Причем ФЯ развиваются как раз именно как ФЯ, ООЯ же уносит черт знает куда, в какое-то монстроподобие. Какие тут преимущества можно усмотреть?
Воспроизведу весь контекст, покоцав свои цитаты:
K>Одним подавай язык для задания бизнес-правил, у них все во вполне конкретных терминах и все абстракции заранее проанализированы AVK>Это не программисты уже в привычном понимании. K>>Привычном для кого ? AVK>Для людей, присутствующих в софтверном бизнесе. K>Это какой такой софтверный бизнес, что программисты на языках высокого уровня перестали быть программистами ? AVK>Нет, это не софтверный бизнес такой, это ты продолжаешь приписывать мне утверждения, которые я не делал.
Читайте выше про языки для создания бизнес-правил. Это и есть языки высокого уровня, применимые в рамках предметной области, о которых я говорил. Любые другие языки, моделирующие элементы предметной области через дополнительные абстракции со своей (обусловленной особенностями языка) структурой — языки более низкого уровня, будь то хаскел, Java, си, асм, или байткод на перфокартах. Я понимаю, очень приятно смотреть на такие языки как на что-то "убогое" или "для быдлокодеров", но надо все же помнить, что предельно высокий уровень языка — там, где можно выразить термины предметной области наиболее кратко и точно, и угадайте, какие языки для этого лучше подходят — специально разработанные для заданной предметной области, или набор "сделай сам на коленке" из Java, си, итд. Не случайно тут битвы про account-ы и про идентификатор счета идут, такая свобода интерпретаций в конкретной заданной предметной области только во вред.
Здравствуйте, grosborn, Вы писали:
>> Я пытался поддержать мысль, но получил возражение. В недоумении.
G>Пытаюсь донести мысль, что в программировании больше синтеза, чем моделирования как такового.
Мысль ясна, но их не надо противопоставлять. Моделирование — тоже синтез. Нет такого что снэпшот мысли внезапно оказался моделью в ООП стиле.
>> А рисование формочек — это не совсем и программирование.
G>Аргумент Но вот только кода, выполняющего далекие от модели основной задачи функции, внезапно больше.
А это зависит от языка, от модели решения и их соответствия друг другу. Т.е. бывают такие языки и задачи, что решения могут быть довольно компактными и не содержать код, выполняющий далекие от решения задачи функции.
Здравствуйте, AndrewVK, Вы писали:
K>>Туплы — это и есть АлгТД. AVK>Нет. Туплы это просто набор значений, кортеж в РА. А АлгТД обязан иметь дискриминант.
Вообще в Хаскелле кортежи это:
data Pair a b = Pair a b
data Triple a b c = Triple a b c
и т.д.
А (,) и (,,) — это просто такие конструкторы вместо Pair и Triple. Они, кстати, так и описываются в инстансах.
> А это зависит от языка, от модели решения и их соответствия друг другу. Т.е. бывают такие языки и задачи, что решения могут быть довольно компактными и не содержать код, выполняющий далекие от решения задачи функции.
Эээ.... Я могу вспомнить только скрипты. Там нет кода не относящегося к решению задачи.
DG>>Это детали реализации. S>Это устройство архитектуры.
от того, что слово "хрен" заменить на слово "редька" смысл не изменится.
DG>>Счет-то все равно объектом остается с соответствующими сообщениями: S>Откуда это внезапно взялось?
Потому что если по счету нет возможности проводить операции, их смотреть тем или иным способом, а также вычислять тот или иной баланс, то это уже не счет.
При чем речь не про варианты — когда возможность отключена, не реализована, временно недоступна, недоступна в данных условиях и т.д., а вообще таких возможностей нет, даже теоретически.
DG>>- зарегистрировать еще одну операцию, S>На всякий случай, напомню, что "регистрация операции" работает с двумя счетами. Кому из них мы посылаем сообщение? Первому попавшемуся? Кто обязан проверять соответствие операции бизнес-правилам?
Кому удобнее, тому и посылаем. С каких это пор в ООП появилось требование однозначности способа выполнения действия?
DG>>- вывести текущее состояние по счету, S>Я уже писал о том, что понятие "текущее состояние" в бухгалтерии не существует. Существует "состояние на дату".
Операция "текущее состояние" — это частный случай операции "состояние на дату". Просто дата не фиксирована, а берется из текущего момента времени.
DG>>- вывести историю операций и т.д.
DG>>Например, когда заходишь в инет-банк, то со счетами работаешь как с объектами: выбираешь объект (счет, транзакцию) и посылаешь ему сообщение посредством нажатия соответствующей кнопки. S>Очень странно. Лично я, когда захожу в инет-банк, никаких сообщений счетам я не посылаю. Сообщения я посылаю исключительно серверу, а сервер мне отвечает.
Это уже другой уровень абстрагирования, соответственно и другие объекты. Если уж на то пошло, то ни каких сообщений ты серверу не посылаешь, а индуцируешь (или модулируешь) электромагнитный сигнал в проводе (или в воздухе) — если в качестве границы системы берется комната в которой ты находишься.
DG>>При этом не важно, как он реализован в js-е или на сервере: как идентификатор, как запись в базе, как еще что-то — для использования через gui инет-банка, счет удобнее воспринимать как объект. DG>>Основная моя мысль, что счет одновременно является и идентификатором, и объектом (еще чаще нечетким объектом — когда набор методов и набор состояния такого объекта зависит от контекста использования) S> Понятие "нечёткого объекта" для меня эквивалентно понятию "твёрдый газ".
Это лишь твои ментальные ограничения. И твои ментальные ловушки, когда ты пытаешься реальные явления ограничить рамками слов, которыми ты эти явления обозначаешь.
Здравствуйте, grosborn, Вы писали:
>> А это зависит от языка, от модели решения и их соответствия друг другу. Т.е. бывают такие языки и задачи, что решения могут быть довольно компактными и не содержать код, выполняющий далекие от решения задачи функции.
G>Эээ.... Я могу вспомнить только скрипты. Там нет кода не относящегося к решению задачи.
Наверное это тоже зависит от конкретных скриптов. Если взять js, то там традиционно толпится куча кода по обходу проблем совместимости браузеров.
(1) K>>Одним подавай язык для задания бизнес-правил, у них все во вполне конкретных терминах и все абстракции заранее проанализированы
(2) AVK>>Это не программисты уже в привычном понимании. K>>>Привычном для кого ? AVK>>Для людей, присутствующих в софтверном бизнесе.
(3) K>>Это какой такой софтверный бизнес, что программисты на языках высокого уровня перестали быть программистами ? AVK>>Нет, это не софтверный бизнес такой, это ты продолжаешь приписывать мне утверждения, которые я не делал.
K>Читайте выше про языки для создания бизнес-правил.
Если ты настаиваешь, я тебе продемонстрирую, где ты подменил мое высказывание. Сперва смотрим (1) — речь зашла о языках бизнес-правил, которые не создают новые абстракции. В (2) мое утверждение, раскрываю с учетом (1): "Написатели бизнес-правил на спецязыке без создания абстракций — не программисты в привычном понимании". А в (3) ты переиначиваешь мое высказывание, легким движением руки заменяя "языки бизнес-правил без абстракций" на языки высокого уровня. Это, батенька, называется подтасовка.
K>Я понимаю, очень приятно смотреть на такие языки
Какие такие? Давай конкретные примеры в студию.
Вот в нашей платформе (Парус Торнадо) есть несколько языков, имеющих отношение к бизнес-правилам. Например, язык метаданных платформы, описывающий прикладные сущности (текстовый декларативный язык + гуевый дизайнер). Но, вот что характерно, этот язык напрямую предназначен для создания новых абстракций. А вот есть еще язык (в какой то мере, это не текстовый язык) задания правил обработок (проводок) документов. В нем таки нет никаких средств создания новых абстракций, только использование существующих. И таки те, кто этим пользуется, нифига не программисты, а всякие внедренцы и админы.
K> как на что-то "убогое" или "для быдлокодеров"
Ты опять приписываешь мне то, чего я не писал.
... << RSDN@Home 1.2.0 alpha 5 rev. 61 on Windows 7 6.1.7601.65536>>
DG>>Основная моя мысль, что счет одновременно является и идентификатором, и объектом (еще чаще нечетким объектом — когда набор методов и набор состояния такого объекта зависит от контекста использования) S>А моя основная мысль, что счёт не ведёт себя как объект в ООП. Понятие "нечёткого объекта" для меня эквивалентно понятию "твёрдый газ".
Как минимум стоит тогда вернуться к основам.
Я утверждаю, что объект — это ментальная модель служающая для удобства описания происходящего, обладающая рядом характеристик (а дальше по любому классическому учебнику ООП). Если ты с этим не согласен, тогда приведи слова кого-нибудь из классиков, где утверждается, что объект должен реально сущестовать как объект, или у кого хотя бы говориться, что такое реальное существование объекта.
Соответственно, по этому определению, например, и linux-овый file и winapi-шный файл — являются объектами. И тред на форуме rsdn.ru тоже является объектом.
Но вот только кода, выполняющего далекие от модели основной задачи функции, внезапно больше.
