Re: Несколько вопросов вразброс
06.07.2012 09:53, Artem Chuprina пишет:
> Артём Н. -> debian-russian@lists.debian.org @ Thu, 05 Jul 2012 20:09:51 +0400:
>
> >> >> Я бы ещё добавил, что ОО-парадигма рождается из желания перейти от
> >> >> классической модели императивного вычислителя, как единого конечного
> >> >> автомата, к модели многих изолированных конечных автоматов, взаимодействующих
> >> >> через чётко ограниченные интерфейсы. Точно так же в электронике от "паука"
> >> >> на рассыпухе, пришли сначала к модульным схемам, а потом к ИС.
> >> АН> Ну и? Это естественный, эволюционный процесс. Разве должно быть иначе?
> >> Естественный эволюционный процесс развивается параллельно по нескольким
> >> веткам. В данном случае это существенно.
> АН> По каким? Я не очень понял, что здесь существенно...
> Существенно здесь то, что направлений улучшения возможно более одного, и
> естественный эволюционный процесс обычно более одного и задействует. В
> результате получается разнообразие видов, а не одна накачанная амеба.
Не соглашусь.
Эволюционный процесс предполагает разные условия среды и, следовательно, разные
ниши для видов (с разной ёмкостью).
В данном случае, тоже самое: есть "основное направление", в котором используются
ИС. И ещё менее ёмкие ниши, откуда ещё электронные лампы не ушли.
В контексте основного направления (без специфических требований) - модульная
архитектура и СБИС.
Также и ООП, в принципе, появилось в результате "эволюции". Т.е., оно, в
какой-то мере, оправданно? Хотя уже написали где и почему.
Возможно его суют не там, где нужно... Но для большинства задач оно же подходит?
(Даже, если говорить о том, что это задачи с нечётко формализованными
требованиями, как вы писали, получается, что большинство настоящих задач слишком
сложны, чтобы их чётко формализовать и выделить все требования, следовательно,
ООП, в общем-то оправдан?)
> >> >> В такой интерпретации ясно, что если в неком языке императивный
> >> >> вычислитель явно не просматривается, то и от ОО-модели этот язык не
> >> >> особо выиграет.
> >> АН> Почему не выиграет?
> >> Потому что их приткнуть либо некуда, либо незачем.
> АН> Для функциональных, опять же, понятно: есть функция. Объекты не
> АН> требуются. Инкапсуляция обеспечивается функцией. Наследование
> АН> заменяется агрегацией. Полиморфизм... Тоже может быть. Я очень
> АН> плохо знаком с функциональной парадигмой.
> Полиморфизм поведенческий, а агрегация плюс полиморфизм - это уже
> больше, чем наследование. Наследование оказывается как-то не очень
> нужным.
Так, получается, это тоже самое наследование, только "под другим углом"?
> >> АН> Объекты могут быть независимыми сущностями (собственно, так и есть,
> >> АН> если они строго через интерфейсы взаимодействуют). Как объект
> >> АН> реализован внутри - не важно (например, это может быть
> >> АН> функциональная программа), порядок их взаимодействия тоже не очень
> >> АН> важен (или он регулируется самими объектами). Ну, возможно назвать
> >> АН> это какой-нибудь сопрограммой, например, а не объектом. Но суть от
> >> АН> этого разве поменяется?
> >>
> >> Все это можно сделать. Увеличение пользы где? Если у тебя
> >> функциональная программа уже есть, то зачем тебе объект в виде
> >> функциональной программы? Чего тебе в языке до введения объектов не
> >> хватало?
> АН> Хз. Просто я толком не знаю других парадигм. Объект мне кажется
> АН> достаточно простым и ясным. Например, функция не хранит данные, как
> АН> объект...
> Тоже может. Слово closure (в русском переводе - замыкание) тебе не
> встречалось? Нет, функция на C такого не умеет, а на нормальных языках
> с функциями - умеют.
Как ни странно, замыкания поддерживает JS. :-) Естественно, встречалось. И
нередко используется.
Но, насколько я понимаю, это получается уже не "чистая функция"... Не знаю, и не
то это. В объекте привлекает то, что возможно изменять атрибуты... Хотя... Через
замыкания тоже возможно построить классы и объекты (что и делают).
Но, в том же JS, не самый очевидный для понимания типа наследования. На
прототипах. По сравнению с наследованием классов - это сложнее.
У класса - чётко определённый интерфейс, который виден через его описание. И
всегда известно, что будет делать объект. Даже если используется полиморфизм, у
объекта всё-равно есть тип. При прототипном наследовании, кажется, не всё так
однозначно...
И нет такой строгой системы классов. И строгой иерархии тоже нет (хотя и в
языках с наследованием классов, тоже нет иерархии, в общем случае, так что - фиг
его знает)...
Reply to: