Re: Несколько вопросов вразброс
Артём Н. -> debian-russian@lists.debian.org @ Sat, 07 Jul 2012 19:43:34 +0400:
>> >> >> Я бы ещё добавил, что ОО-парадигма рождается из желания перейти от
>> >> >> классической модели императивного вычислителя, как единого конечного
>> >> >> автомата, к модели многих изолированных конечных автоматов, взаимодействующих
>> >> >> через чётко ограниченные интерфейсы. Точно так же в электронике от "паука"
>> >> >> на рассыпухе, пришли сначала к модульным схемам, а потом к ИС.
>> >> АН> Ну и? Это естественный, эволюционный процесс. Разве должно быть иначе?
>> >> Естественный эволюционный процесс развивается параллельно по нескольким
>> >> веткам. В данном случае это существенно.
>> АН> По каким? Я не очень понял, что здесь существенно...
>> Существенно здесь то, что направлений улучшения возможно более одного, и
>> естественный эволюционный процесс обычно более одного и задействует. В
>> результате получается разнообразие видов, а не одна накачанная амеба.
АН> Не соглашусь.
АН> Эволюционный процесс предполагает разные условия среды и,
АН> следовательно, разные ниши для видов (с разной ёмкостью).
В пределе, вероятно, да. В процессе - нет. А поскольку мы всегда в
процессе...
АН> Возможно его суют не там, где нужно... Но для большинства задач оно
АН> же подходит? (Даже, если говорить о том, что это задачи с нечётко
АН> формализованными требованиями, как вы писали, получается, что
АН> большинство настоящих задач слишком сложны, чтобы их чётко
АН> формализовать и выделить все требования, следовательно, ООП, в
АН> общем-то оправдан?)
Проблема не в том, что задачи сложны, а в том, что людям лень думать так
называемой головой. Когда заказчик сам не знает, чего хочет, но хочет,
чтоб работало - да, ООП оправдан. И то не всегда. КАК ТОЛЬКО
архитектор системы может сделать с постановкой задачи что-то осмысленное
- скорее всего, ООП окажется не самым подходящим инструментом. Хотя с
этим подходом тоже можно решить задачу, почему нет? "Дрель с ударом"
тоже может делать отверстия под дюбели в бетоне. Только ею приходится
долбать одно отверстие 5 минут, а перфоратор справляется за 15 секунд.
Если дырок нужно набурить хотя бы три, не говоря про два десятка,
разница становится ОЧЕНЬ существенной. Но если ты не знаешь заранее,
что тебе надо будет сверлить - бетон, асбест или дерево, а взять можно
только один инструмент (хотя бы по массогабаритным ограничениям), то
лучше взять дрель - под перфоратор бура по дереву тупо нет. А если
можно взять два, то лучше дрель (можно без удара, читай, C, а не C++) и
перфоратор.
>> >> >> В такой интерпретации ясно, что если в неком языке императивный
>> >> >> вычислитель явно не просматривается, то и от ОО-модели этот язык не
>> >> >> особо выиграет.
>> >> АН> Почему не выиграет?
>> >> Потому что их приткнуть либо некуда, либо незачем.
>> АН> Для функциональных, опять же, понятно: есть функция. Объекты не
>> АН> требуются. Инкапсуляция обеспечивается функцией. Наследование
>> АН> заменяется агрегацией. Полиморфизм... Тоже может быть. Я очень
>> АН> плохо знаком с функциональной парадигмой.
>> Полиморфизм поведенческий, а агрегация плюс полиморфизм - это уже
>> больше, чем наследование. Наследование оказывается как-то не очень
>> нужным.
АН> Так, получается, это тоже самое наследование, только "под другим углом"?
Наоборот. Наследование, если смотреть на парадигму - это один из
(ограниченных) взглядов на полиморфизм.
>> >> АН> Объекты могут быть независимыми сущностями (собственно, так и есть,
>> >> АН> если они строго через интерфейсы взаимодействуют). Как объект
>> >> АН> реализован внутри - не важно (например, это может быть
>> >> АН> функциональная программа), порядок их взаимодействия тоже не очень
>> >> АН> важен (или он регулируется самими объектами). Ну, возможно назвать
>> >> АН> это какой-нибудь сопрограммой, например, а не объектом. Но суть от
>> >> АН> этого разве поменяется?
>> >>
>> >> Все это можно сделать. Увеличение пользы где? Если у тебя
>> >> функциональная программа уже есть, то зачем тебе объект в виде
>> >> функциональной программы? Чего тебе в языке до введения объектов не
>> >> хватало?
>> АН> Хз. Просто я толком не знаю других парадигм. Объект мне кажется
>> АН> достаточно простым и ясным. Например, функция не хранит данные, как
>> АН> объект...
>> Тоже может. Слово closure (в русском переводе - замыкание) тебе не
>> встречалось? Нет, функция на C такого не умеет, а на нормальных языках
>> с функциями - умеют.
АН> Как ни странно, замыкания поддерживает JS. :-) Естественно, встречалось. И
АН> нередко используется.
АН> Но, насколько я понимаю, это получается уже не "чистая функция"...
В функциональных языках - чистая. JS, а также Perl, Python etc. - языки
с _элементами_ функциональной парадигмы. Там функция - не first-class
entity, и количество возможных операций с нею сильно ограничено.
АН> Не знаю, и не то это. В объекте привлекает то, что возможно
АН> изменять атрибуты... Хотя... Через замыкания тоже возможно
АН> построить классы и объекты (что и делают). Но, в том же JS, не
АН> самый очевидный для понимания типа наследования. На прототипах. По
АН> сравнению с наследованием классов - это сложнее. У класса - чётко
АН> определённый интерфейс, который виден через его описание. И всегда
АН> известно, что будет делать объект. Даже если используется
АН> полиморфизм, у объекта всё-равно есть тип. При прототипном
АН> наследовании, кажется, не всё так однозначно... И нет такой
АН> строгой системы классов. И строгой иерархии тоже нет (хотя и в
АН> языках с наследованием классов, тоже нет иерархии, в общем случае,
АН> так что - фиг его знает)...
Обычно, если у языка есть выделенная парадигма, то большинство операций
проще как минимум для понимания, а чаще и для реализации, именно в ней.
Haskell - тоже типизированный язык, причем куда более типизированный,
чем JS, и там у всех сущностей (ну хорошо, у всех first-class сущностей,
у самих типов нету) обязательно есть типы. Что совершенно не мешает
строить полиморфизм, включая ad-hoc полиморфизм (т.е. добавляемый уже
после того, как сущности, к которым он применяется, полностью и
совершенно независимо определены). Т.е., в терминологии ООП, добавлять
общее поведение совершенно разнородным объектам. И всё вышеописанное
там делается совершенно не так, как в ООП. Вместо "этот объект может
делать то-то и то-то так-то и так-то" - "эта сущность является частным
случаем вон той абстракции при взгляде вот под таким углом, и вот этой
абстракции - при взгляде вот под этим углом". Это, собственно, более
широкий взгляд на полиморфизм.
Reply to: