06.07.2012 09:53, Artem Chuprina пишет: > Артём Н. -> debian-russian@lists.debian.org @ Thu, 05 Jul 2012 20:09:51 > +0400: > > >> >> Я бы ещё добавил, что ОО-парадигма рождается из желания перейти от > >> >> классической модели императивного вычислителя, как единого конечного > >> >> автомата, к модели многих изолированных конечных автоматов, > взаимодействующих > >> >> через чётко ограниченные интерфейсы. Точно так же в электронике от > "паука" > >> >> на рассыпухе, пришли сначала к модульным схемам, а потом к ИС. > >> АН> Ну и? Это естественный, эволюционный процесс. Разве должно быть > иначе? > >> Естественный эволюционный процесс развивается параллельно по нескольким > >> веткам. В данном случае это существенно. > АН> По каким? Я не очень понял, что здесь существенно... > Существенно здесь то, что направлений улучшения возможно более одного, и > естественный эволюционный процесс обычно более одного и задействует. В > результате получается разнообразие видов, а не одна накачанная амеба. Не соглашусь. Эволюционный процесс предполагает разные условия среды и, следовательно, разные ниши для видов (с разной ёмкостью). В данном случае, тоже самое: есть "основное направление", в котором используются ИС. И ещё менее ёмкие ниши, откуда ещё электронные лампы не ушли. В контексте основного направления (без специфических требований) - модульная архитектура и СБИС. Также и ООП, в принципе, появилось в результате "эволюции". Т.е., оно, в какой-то мере, оправданно? Хотя уже написали где и почему. Возможно его суют не там, где нужно... Но для большинства задач оно же подходит? (Даже, если говорить о том, что это задачи с нечётко формализованными требованиями, как вы писали, получается, что большинство настоящих задач слишком сложны, чтобы их чётко формализовать и выделить все требования, следовательно, ООП, в общем-то оправдан?)
> >> >> В такой интерпретации ясно, что если в неком языке императивный > >> >> вычислитель явно не просматривается, то и от ОО-модели этот язык не > >> >> особо выиграет. > >> АН> Почему не выиграет? > >> Потому что их приткнуть либо некуда, либо незачем. > АН> Для функциональных, опять же, понятно: есть функция. Объекты не > АН> требуются. Инкапсуляция обеспечивается функцией. Наследование > АН> заменяется агрегацией. Полиморфизм... Тоже может быть. Я очень > АН> плохо знаком с функциональной парадигмой. > Полиморфизм поведенческий, а агрегация плюс полиморфизм - это уже > больше, чем наследование. Наследование оказывается как-то не очень > нужным. Так, получается, это тоже самое наследование, только "под другим углом"? > >> АН> Объекты могут быть независимыми сущностями (собственно, так и есть, > >> АН> если они строго через интерфейсы взаимодействуют). Как объект > >> АН> реализован внутри - не важно (например, это может быть > >> АН> функциональная программа), порядок их взаимодействия тоже не очень > >> АН> важен (или он регулируется самими объектами). Ну, возможно назвать > >> АН> это какой-нибудь сопрограммой, например, а не объектом. Но суть от > >> АН> этого разве поменяется? > >> > >> Все это можно сделать. Увеличение пользы где? Если у тебя > >> функциональная программа уже есть, то зачем тебе объект в виде > >> функциональной программы? Чего тебе в языке до введения объектов не > >> хватало? > АН> Хз. Просто я толком не знаю других парадигм. Объект мне кажется > АН> достаточно простым и ясным. Например, функция не хранит данные, как > АН> объект... > Тоже может. Слово closure (в русском переводе - замыкание) тебе не > встречалось? Нет, функция на C такого не умеет, а на нормальных языках > с функциями - умеют. Как ни странно, замыкания поддерживает JS. :-) Естественно, встречалось. И нередко используется. Но, насколько я понимаю, это получается уже не "чистая функция"... Не знаю, и не то это. В объекте привлекает то, что возможно изменять атрибуты... Хотя... Через замыкания тоже возможно построить классы и объекты (что и делают). Но, в том же JS, не самый очевидный для понимания типа наследования. На прототипах. По сравнению с наследованием классов - это сложнее. У класса - чётко определённый интерфейс, который виден через его описание. И всегда известно, что будет делать объект. Даже если используется полиморфизм, у объекта всё-равно есть тип. При прототипном наследовании, кажется, не всё так однозначно... И нет такой строгой системы классов. И строгой иерархии тоже нет (хотя и в языках с наследованием классов, тоже нет иерархии, в общем случае, так что - фиг его знает)... -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ff85926.9090...@yandex.ru
