OO is no longer effective
Andrei N. Sobchuck
...
However, we seem to have reached the point where OO is no longer effective. No one can comfortably negotiate a system with thousands of classes. So, unfortunately, object-oriented programming has a fundamental flaw, ironically related to its main strength.
...
--
Andrei N.Sobchuck
JabberID: and...@jabber.ru. ICQ UIN: 46466235.
Anton Moscal
ANS> From: "Andrei N. Sobchuck" <and...@mart.cherkassy.ua>
ANS> http://java.sun.com/developer/technicalArticles/Interviews/livschitz_qa.
ANS> html
ANS> ...
ANS> However, we seem to have reached the point where OO is no longer
ANS> effective. No one can comfortably negotiate a system with thousands of
ANS> classes. So, unfortunately, object-oriented programming has a
ANS> fundamental flaw, ironically related to its main strength.
ANS> ...
imho решение проблемы довольно очевидно (и очень давно) - не надо пытаться
запихивать все в одну сущность. Скажем если иметь типы данных, семаника
которых определяется их структурой (как в ML/Haskell) - tagged union, списки,
n-ки, записи и прочая (с готовыми конструкторами и операциями) и стандартный
набор полиморфных типов (set, map, ...) - сразу уйдут 3/4 классов, которые
носят сугубо технический характер - для моделирования их в минимально
пристойном виде . Скажем:
type expr = Con of int | Var of string | Add of expr * expr
на объектах превращается в 4 класса, и вовсе не факт что это имеет хоть
какой-то смысл. Равно как не факт, что здесь нужна инкапсуляция на уровне
отдельных вариантов.
Если к этому добавить еще и нормальную модульную систему (желательно с
параметризованными модулями) - будет еще лучше. Потому что классы вовсе не
всегда уместны в этом качестве.
И понятность программы возрастет - потому что намерения автора будут более
понятны - Set<string> - это множество строк, а какой-нибудь класс StrSet - уже
думать надо. И с модулем тоже ясно, что это именно модуль, а не класс.
Антон
Andrei N. Sobchuck
AM> imho решение проблемы довольно очевидно (и очень давно) - не надо пытаться
Как по мне, то проблема невозможности оперировать тысячами классов
одновременно решается путём уменьшения кол-ва классов, которыми нужно
оперировать одновременно. Этому процессу даже название придумали 'decoupling'.
Я,к сожалению, не на том акцентировал внимание. Там есть цитаты поинтереснее:
"In object-oriented systems, "object" is the one and only
basic abstraction.
...
Explaining the world through a collection of objects is just too simple!
...
Consider a few common concepts that people universally use to understand and describe all systems -- concepts that do not fit the object mold. The "before/after" paradigm, as well that of "cause/effect," and the notion of the "state of the system" are amongst the most vivid examples. Indeed, the process of "brewing coffee," or "assembling a vehicle," or "landing a rover on Mars" cannot be decomposed into simple objects."
И действительно, у кучи объектов немного возможностей. Но если добавить
сюда возможность взаимодействия, то сразу появляется и "before/after",
и "cause/effect", и даже "brewing coffee".
Кстати, Алан Кей приносил свои извенения за то, что введя в обиход
термин "объекты", он сместил акценты с "взаимодействия объектов".
http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017025.html
(перевод http://www.smalltalk.ru/quotes.html).
AM> запихивать все в одну сущность. Скажем если иметь типы данных, семаника
AM> которых определяется их структурой (как в ML/Haskell) - tagged union, списки,
AM> n-ки, записи и прочая (с готовыми конструкторами и операциями) и стандартный
AM> набор полиморфных типов (set, map, ...) - сразу уйдут 3/4 классов, которые
AM> носят сугубо технический характер - для моделирования их в минимально
Стандартные библиотеки [классов] существуют.
AM> пристойном виде . Скажем:
AM> type expr = Con of int | Var of string | Add of expr * expr
AM> на объектах превращается в 4 класса, и вовсе не факт что это имеет хоть
AM> какой-то смысл. Равно как не факт, что здесь нужна инкапсуляция на уровне
AM> отдельных вариантов.
Нигде нет правил ОО обязывающих тебя использовать 4 класса, а не один.
Хотя такое решение вполне естесвенно :) и я не вижу в нём ничего страшного.
AM> Если к этому добавить еще и нормальную модульную систему (желательно с
AM> параметризованными модулями) - будет еще лучше. Потому что классы вовсе не
AM> всегда уместны в этом качестве.
Ты рассматриваешь модули как средство ограничения количества связей?
Или как средство побороть статическую типизацию (параметрами)?
AM> И понятность программы возрастет - потому что намерения автора будут более
AM> понятны - Set<string> - это множество строк, а какой-нибудь класс StrSet - уже
AM> думать надо. И с модулем тоже ясно, что это именно модуль, а не класс.
Просто Set - тоже нормально ;)
--
Andrei N.Sobchuck
JabberID: and...@jabber.ru. ICQ UIN: 46466235.
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Anton Moscal
ANS> Как по мне, то проблема невозможности оперировать тысячами классов
ANS> одновременно решается путём уменьшения кол-ва классов, которыми нужно
ANS> оперировать одновременно. Этому процессу даже название придумали
ANS> 'decoupling'.
На мой взгляд куда продуктивнее просто уменьшить количество классов - это еще
и выгрыш по трудозатратам дает.
AM>> и стандартный набор полиморфных типов (set, map, ...) - сразу уйдут 3/4
AM>> классов, которые носят сугубо технический характер - для моделирования
AM>> их в минимально
ANS> Стандартные библиотеки [классов] существуют.
Им обычно вовсе ни к чему быть классами - степановский опыт с STL в этом
смысле показателен - там ОО оказалось вообще ни при чем - просто ввиду полного
отсуствия в С++ альтернатив все пихается в классы (большая часть которых носит
совершенно технический характер) причем для очень простых вещей получается
весьма неочевидный код.
AM>> type expr = Con of int | Var of string | Add of expr * expr
AM>> на объектах превращается в 4 класса, и вовсе не факт что это имеет хоть
AM>> какой-то смысл. Равно как не факт, что здесь нужна инкапсуляция на
AM>> уровне отдельных вариантов.
ANS> Hигде нет правил ОО обязывающих тебя использовать 4 класса, а не один.
В один не влезет.
ANS> Хотя такое решение вполне естесвенно :) и я не вижу в нём ничего
ANS> страшного.
Кроме того, что вместо одного типа - имеем 4 класса с явно выписанными
конструкторами и прочей дребеденью (количество которых обозначено как
проблема), каждый из которых занимает по несколько строк. И смысл городить
огород? Зачем _здесь_ ОО? Или зачем делать из структуры с парой полей класс
только ради того, чтобы оно более или менее прилично выглядело синтаксически.
AM>> Если к этому добавить еще и нормальную модульную систему (желательно с
AM>> параметризованными модулями) - будет еще лучше. Потому что классы вовсе
AM>> не всегда уместны в этом качестве.
ANS> Ты рассматриваешь модули как средство ограничения количества связей?
ANS> Или как средство побороть статическую типизацию (параметрами)?
Как выразительное средство - отчасти как способ инкапсуляции. Отчасти - как
средство модуляризации программы. То есть именно как выразительное средство.
А параметры к "статической типизации" отношения не имеют - это именно
параметризация - хороший пример - O'Caml-ный hash:
Параметризуется модулем с сигнатурой
sig
type t
val equal: t -> t -> bool
val hash: t -> int
end
То есть - таблица параметризуется типом элемента и парой функций сравнения и
хэширования. Кстати - ОО аналог будет не вполне интуитивно очевиден - потому
как хэш-таблицы над одним и тем же типом (классом, если угодно) могут иметь
разные операции сравнения и хэширования и это достаточно часто имеет смысл
(группировка по разным критериям). В OO тут начинают появляться классы с не
вполне очевидной фукнциональностью. Ну то есть видимо вместо модуля-параметра,
который обычно даже не имеет имени появляется некий полуфиктивный класс с
методами equal и hash от двух параметров, которым и параметризуется
хэш-таблица. Или же отнаследоваться от таблицы переопределив эти методы. Вот
так классы и размножаются.
AM>> И понятность программы возрастет - потому что намерения автора будут
AM>> более понятны - Set<string> - это множество строк, а какой-нибудь класс
AM>> StrSet - уже думать надо. И с модулем тоже ясно, что это именно модуль,
AM>> а не класс.
ANS> Просто Set - тоже нормально ;)
Уже не очень - поскольку Set - он обычно "чего-то". И опять же - часто надо
задать специфические для конкретного _множества_ операции сравнения и
упорядочения.
Я не о том, что оно не делается - делается, но это для ОО неестественное
применение. И вот тут-то и начинают размножаться классы.
Антон
Serge A. Rider
AM> From: "Anton Moscal" <m...@mail.tepkom.ru>
AM> Wed Mar 17 2004 15:20, Andrei N. Sobchuck wrote to "Anton Moscal":
ANS>> Стандартные библиотеки [классов] существуют.
AM> Им обычно вовсе ни к чему быть классами - степановский опыт с STL в этом
AM> смысле показателен - там ОО оказалось вообще ни при чем - просто ввиду
AM> полного отсуствия в С++ альтернатив все пихается в классы (большая часть
AM> которых носит совершенно технический характер) причем для очень простых
AM> вещей получается весьма неочевидный код.
Hу в новой яве в плане коллекций это примерно аналогично сделано. А чем плохи
параметризованные классы в плане реализаций коллекций?
AM> Кроме того, что вместо одного типа - имеем 4 класса с явно выписанными
AM> конструкторами и прочей дребеденью (количество которых обозначено как
AM> проблема), каждый из которых занимает по несколько строк. И смысл
AM> городить огород? Зачем _здесь_ ОО? Или зачем делать из структуры с парой
AM> полей класс только ради того, чтобы оно более или менее прилично
AM> выглядело синтаксически.
Видимо чтобы не плодить сущностей. Опять-таки в новой яве некоторый
номинальный уход от ООП уже произошел. Енумы, например, появились =)
AM> То есть - таблица параметризуется типом элемента и парой функций
AM> сравнения и хэширования. Кстати - ОО аналог будет не вполне интуитивно
AM> очевиден - потому как хэш-таблицы над одним и тем же типом (классом, если
AM> угодно) могут иметь разные операции сравнения и хэширования и это
AM> достаточно часто имеет смысл (группировка по разным критериям). В OO тут
AM> начинают появляться классы с не вполне очевидной фукнциональностью. Hу то
AM> есть видимо вместо модуля-параметра, который обычно даже не имеет имени
AM> появляется некий полуфиктивный класс с методами equal и hash от двух
AM> параметров, которым и параметризуется хэш-таблица. Или же отнаследоваться
AM> от таблицы переопределив эти методы. Вот так классы и размножаются.
В той же яве для этого существуют анонимные классы, которые сложности к
системе в целом не добавляют и снаружи не видны. А в C++ поспособствуют
миксины.
Вообще я не думаю, что в изначальном постинге под большим количеством классов
имелось в виду их разрастание в результате появления многочисленных крошечных
функторов. Мне это в принципе не кажется особо серьезной проблемой ООП. Есть
проблемы и пострашнее =)
Andrei N. Sobchuck
AM> Им обычно вовсе ни к чему быть классами - степановский опыт с STL в этом
AM> смысле показателен - там ОО оказалось вообще ни при чем - просто ввиду полного
AM> отсуствия в С++ альтернатив все пихается в классы (большая часть которых носит
AM> совершенно технический характер) причем для очень простых вещей получается
AM> весьма неочевидный код.
Ковырял ST классы коллекций - всё очевидно и разумно.
AM>>> type expr = Con of int | Var of string | Add of expr * expr
AM>>> на объектах превращается в 4 класса, и вовсе не факт что это имеет хоть
AM>>> какой-то смысл. Равно как не факт, что здесь нужна инкапсуляция на
AM>>> уровне отдельных вариантов.
ANS>> Hигде нет правил ОО обязывающих тебя использовать 4 класса, а не один.
AM> В один не влезет.
int и string я не считаю. А так вполне. Только это будет закат солнца вручную.
ANS>> Хотя такое решение вполне естесвенно :) и я не вижу в нём ничего
ANS>> страшного.
AM> Кроме того, что вместо одного типа - имеем 4 класса с явно выписанными
AM> конструкторами и прочей дребеденью (количество которых обозначено как
AM> проблема), каждый из которых занимает по несколько строк. И смысл городить
AM> огород? Зачем _здесь_ ОО? Или зачем делать из структуры с парой полей класс
AM> только ради того, чтобы оно более или менее прилично выглядело синтаксически.
Эти структуры имеют поведение. Которое, в твоём случае, перенесётся
в фиг знает какую часть программы. А выбор поведения осуществляется при помощи
pattern-matchinga.
Заметь, я не отвергаю такой подход. Вот только при разрастании сложности
системы опять вылазят эти самые инкапсулированые сущности, которые
обмениваются сообщениями. Как в Erlang.
AM> Как выразительное средство - отчасти как способ инкапсуляции. Отчасти - как
AM> средство модуляризации программы. То есть именно как выразительное средство.
Что классы - не замена модулям я согласен. Просто модули они разные бывают.
В том же VW ST пакеты могут содержать, например, методы к классам, которых
в самом пакета нет. Или перекрывать уже определённые методы.
Какой именно функционал полезнее я не готов рассуждать.
AM> А параметры к "статической типизации" отношения не имеют - это именно
AM> параметризация - хороший пример - O'Caml-ный hash:
AM> Параметризуется модулем с сигнатурой
AM> sig
AM> type t
AM> val equal: t -> t -> bool
AM> val hash: t -> int
AM> end
AM> То есть - таблица параметризуется типом элемента и парой функций сравнения и
имхо вполне себе обход статической типизации.
AM> хэширования. Кстати - ОО аналог будет не вполне интуитивно очевиден - потому
AM> как хэш-таблицы над одним и тем же типом (классом, если угодно) могут иметь
AM> разные операции сравнения и хэширования и это достаточно часто имеет смысл
AM> (группировка по разным критериям). В OO тут начинают появляться классы с не
AM> вполне очевидной фукнциональностью. Ну то есть видимо вместо модуля-параметра,
AM> который обычно даже не имеет имени появляется некий полуфиктивный класс с
AM> методами equal и hash от двух параметров, которым и параметризуется
AM> хэш-таблица. Или же отнаследоваться от таблицы переопределив эти методы. Вот
хеш-таблицу можно параметризовать (моя правильно пишет на русски? :)
соответсвующими методами. Или блоками/лямбдами. Именно так устроена
СортированнаяКоллекция в ST.
AM> так классы и размножаются.
Это еще один камень в огород С++?
AM>>> И понятность программы возрастет - потому что намерения автора будут
AM>>> более понятны - Set<string> - это множество строк, а какой-нибудь класс
AM>>> StrSet - уже думать надо. И с модулем тоже ясно, что это именно модуль,
AM>>> а не класс.
ANS>> Просто Set - тоже нормально ;)
AM> Уже не очень - поскольку Set - он обычно "чего-то". И опять же - часто надо
AM> задать специфические для конкретного _множества_ операции сравнения и
AM> упорядочения.
Например?
AM> Я не о том, что оно не делается - делается, но это для ОО неестественное
AM> применение. И вот тут-то и начинают размножаться классы.
Я уже написал, что это не так.
Anton Moscal
ANS> Эти структуры имеют поведение. Которое, в твоём случае, перенесётся
ANS> в фиг знает какую часть программы. А выбор поведения осуществляется при
ANS> помощи pattern-matchinga.
У них нет поведения. Это просто значения. Неизменяемые причем значения Такие
же как string и int. А то, что операции над ними "переносятся" туда, где они
нужны - это скорее преимущество. По крайней мере если мне понадобится скажем
составить список всех переменных из выражения, мне не придется добвалять в
структур новый метод, равномерно размазанный по всем классам и предназначеный
для использования "невесть где". Или там - найти все переменные из одного
выражения, которые не используются в другом - вот чье это "поведение"? Понятно
что выбор в ОО тут совершенно произволен и никакого смысла в нем нет.
ANS> Заметь, я не отвергаю такой подход. Вот только при разрастании сложности
ANS> системы опять вылазят эти самые инкапсулированые сущности, которые
ANS> обмениваются сообщениями. Как в Erlang.
Да немного этих сущностей. Тут реально скорее всего будет "сущность" ast и
несколько операций с ее участием (а вовсе кстати, не сообщений, cкорее всего)
ANS> бывают.
ANS> В том же VW ST пакеты могут содержать, например, методы к классам,
ANS> которых
ANS> в самом пакета нет. Или перекрывать уже определённые методы.
ANS> Какой именно функционал полезнее я не готов рассуждать.
Я склонен думать что полензнее разнообразие.
AM>> А параметры к "статической типизации" отношения не имеют - это именно
AM>> параметризация - хороший пример - O'Caml-ный hash:
AM>> Параметризуется модулем с сигнатурой
AM>> sig
AM>> type t
AM>> val equal: t -> t -> bool
AM>> val hash: t -> int
AM>> end
AM>> То есть - таблица параметризуется типом элемента и парой функций
AM>> сравнения и
ANS> имхо вполне себе обход статической типизации.
Ну при чем тут "обход"? Чем тебе тут поможет динамическая типизация? Разве что
спихнет вопрос контроля за однородностью элементов (что необходимо для работы
equal) с системы на тебя. Или на таблицу, но тогда придется передавать ей и
тип тоже.
ANS> соответсвующими методами. Или блоками/лямбдами. Именно так устроена
ANS> СортированнаяКоллекция в ST.
Разумеется блоками параметризовать можно - вот как раз это и делается в
параметризованном модуле.
AM>> Уже не очень - поскольку Set - он обычно "чего-то". И опять же - часто
AM>> надо задать специфические для конкретного _множества_ операции
AM>> сравнения и упорядочения.
ANS> Hапример?
Например по разным ключам в записи.
Антон
Andrei N. Sobchuck
AM> для использования "невесть где". Или там - найти все переменные из одного
AM> выражения, которые не используются в другом - вот чье это "поведение"? Понятно
AM> что выбор в ОО тут совершенно произволен и никакого смысла в нем нет.
Реально оно будет размазано по обоим классам. Размазано "не от балды", а по
разделению этого действия на элементарные шаги.
ANS>> Заметь, я не отвергаю такой подход. Вот только при разрастании сложности
ANS>> системы опять вылазят эти самые инкапсулированые сущности, которые
ANS>> обмениваются сообщениями. Как в Erlang.
AM> Да немного этих сущностей. Тут реально скорее всего будет "сущность" ast и
AM> несколько операций с ее участием (а вовсе кстати, не сообщений, cкорее всего)
Прошу прощения за неясность в выражении мыслей. Я всё о процессах и
сообщениях в Erlang. И о разрастании не конкретно данного примера, а
задач "вообще". Концепция "сообщения" универсальна. И имеется,
независимо от ОО, во многих системах.
Anton Moscal
ANS> Прошу прощения за неясность в выражении мыслей. Я всё о процессах и
ANS> сообщениях в Erlang. И о разрастании не конкретно данного примера, а
ANS> задач "вообще". Концепция "сообщения" универсальна. И имеется,
ANS> независимо от ОО, во многих системах.
Концепция лямба-выражения и аппликации тоже универасльна независимо от FP и
имеется ... (далее по текст). Однако же есть ситуации где удобнее лямбды и
проч, есть - где ОО и сообщения. Есть смысл и пользоваться теми средствами,
которые к данной ситуации более подходят.
В качестве побочного эффекта - сложность системы уменьшается, а понятность -
возрастает.
Антон Москаль
Andrei N. Sobchuck
AM> В качестве побочного эффекта - сложность системы уменьшается, а понятность -
AM> возрастает.
Всё ж думаю, что от смешения подходов ничего хорошего не получается.
Anton Moscal
AM>> В качестве побочного эффекта - сложность системы уменьшается, а
AM>> понятность - возрастает.
ANS> Всё ж думаю, что от смешения подходов ничего хорошего не получается.
Я имею прямо противоположное мнение. Только смешивать надо правильно. В
некотором смысле Smalltalk тому пример - лямбды (АКА блоки) там юзятся в хвост
и в гриву и без них он cильно скиснет.
Антон
Andrei N. Sobchuck
ANS>> Всё ж думаю, что от смешения подходов ничего хорошего не получается.
AM> Я имею прямо противоположное мнение. Только смешивать надо правильно. В
AM> некотором смысле Smalltalk тому пример - лямбды (АКА блоки) там юзятся в хвост
AM> и в гриву и без них он cильно скиснет.
Ну. Ты сам писал, что замыкания (в виде лямбд ли, в виде ли анонимных классов
- не важно) это всего лишь синтаксический сахар. Так что, блоки, из
списка "смешений концепций", мы вычеркиваем.
Остаются объекты-и-сообщения и функции-и-апликации.
Вот в Erlan-е (его я беру как пример реально работающего языка) не хватило
функций-и-апликаций. Пришлось добавлять концепцию посылки сообщений.
А, имхо, это всё же два разных подхода.
Anton Moscal
ANS> Hу. Ты сам писал, что замыкания (в виде лямбд ли, в виде ли анонимных
ANS> классов - не важно) это всего лишь синтаксический сахар. Так что, блоки,
Не в лямбда-исчислении. Там наоборот - это базовое понятие (присуствует в виде
правила переименования имен при редукции). Все осальное - вторично.
ANS> Остаются объекты-и-сообщения и функции-и-апликации.
ANS> Вот в Erlan-е (его я беру как пример реально работающего языка) не
ANS> хватило функций-и-апликаций. Пришлось добавлять концепцию посылки
ANS> сообщений.
В ML и Haskell сообщения отсуствуют. А это еще более реально работающие языки.
Антон Москаль
Andrei N. Sobchuck
AM> В ML и Haskell сообщения отсуствуют. А это еще более реально работающие языки.
На практике? где?
--
Andrei N.Sobchuck
JabberID: and...@jabber.ru. ICQ UIN: 46466235.
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Anton Moscal
AM>> В ML и Haskell сообщения отсуствуют. А это еще более реально работающие
AM>> языки.
ANS> Hа практике? где?
Объем кода на O'Caml думаю где-то минимум на порядок превосходит Erlang.
Anton Moscal
Andrei N. Sobchuck
AM>>> В ML и Haskell сообщения отсуствуют. А это еще более реально работающие
AM>>> языки.
ANS>> Hа практике? где?
AM> Объем кода на O'Caml думаю где-то минимум на порядок превосходит Erlang.
Приложения какие?
Anton Moscal
AM>> Объем кода на O'Caml думаю где-то минимум на порядок превосходит Erlang.
AM>>
ANS> Приложения какие?
Например - оптимизатор ассемблерного кода для одного "приватного"
Zilog'овского DSP - вещь, за которую я вполне живые деньги получил. В конечном
счете - от того самого Zilog'а (end user'ом был именно он).
Антон Москаль
Maxim Kizub
ANS> From: "Andrei N. Sobchuck" <and...@mart.cherkassy.ua>
ANS> ...
ANS> However, we seem to have reached the point where OO is no longer
ANS> effective. No one can comfortably negotiate a system with thousands of
ANS> classes. So, unfortunately, object-oriented programming has a
ANS> fundamental flaw, ironically related to its main strength.
ANS> ...
Давайте обсудим другой вариант решения проблемы.
ОО действительно "более" не эффективен - по причине возросшей
сложности приложений. То есть при помощи ОО эту сложность
и стало возможным увеличить, но опять-же предел уже достигнут.
Разумеется, есть куда дальше расти в этом месте - можно
"сливать" концепции функциональной и императивной парадигмы
(в которой, собственно, ООП и показывает максимум преимуществ).
Эти попытки идут с двух сторон - как добавления ОО к функциональной
парадигме (пока, IMHO, не очень-то получается), так и добавление
функциональной парадигмы в императивные языки с развитым
ОО (тоже не шибко получается).
Hо и тот и другой подход - это подход приспособления языков
программирования к человеку, к невозможности им отследить
все взаимосвязи в программе (то есть в данном её месте).
Противоположный ход - это "усилить" мозги. То есть комп выполняет
за человека рутинную работу по отслеживанию этих связей и
измененнию поведения программы при изменении кода.
Есть варианты с типами, есть варианты с условиями накладываемыми
на код (assert-ы и call by contract). Есть даже совсем далёкие
варианты, типа логического программирования, где человек
как-бы освобождается от программирования вообще.
Безусловно, оба подхода будут развиваться, и должны дополнять
друг друга. С подходом приспособления языка к человеку - это
может быть и создание узко-специализированных языков под
каждую задачу, и даже под каждую под-задачу. С подходом
"усиления" мозгов - это более продвинутый анализ программы
(более сложный) и более реалтаймовый. Реалтаймовый в том
смысле, что не надо запускать тулзу и ждать пол-часа результата
анализа всего кода - а результат выдаётся немедленно.
Hу вот. Я вижу возможность это сделать через IDE.
И сделать это следующим образом - в IDE уже хранится
программа в полу-откомпилированном виде. То есть AST
дерево. И программист редактирует непосредственно это
дерево, а не текст. А IDE "рендерит" это AST представление
в текстовый (или любой другой) вид на экране.
1. Отвязать язык программирования от синтаксиса. Что-то вроде
наличия нескольких языков программирования для .NET, но
с возможностью определять синтаксис для себя и конкретной
задачи индивидульно, включая и фичи, которых в языке как-бы
нет. Hу например, определение новых и переопределение
операторов - это же просто синтаксическая обёртка над методом.
Или макросы и инлайн-методы - в самом что ни на есть продвинутом
варианте (с учётом типа операндов и пр.)
В общем, это простое следствие того, что программа уже
"скомпилирована", и просто отображается на экране в удобнов
виде. Кому как удобно, и для задачи как удобно.
Hу например - веб-программы на яве. JSP ведь просто компилится
в явовский код. Просто такое удобное представление сервлета.
А его его представлять используя все возможности графики,
включая шрифты и цвета и прочее - то и неудобный синтаксис
xml/html нафиг не нужен. Прям так и редактируем, в WYSIWYG
варианте.
Или программы со сложными математическими формулами. Так прямо
их в "рукописном" виде и отображаем - со всеми математическими
значками и пр. Уникодовских символов на это вполне хватает.
А то, что корень квадратный нарисованный на экране компилятору
будет передан как вызов функции sqrt - это никому не интересно.
Или отображение программы в паскалевском или сишном синтаксисе.
Можно приводить примеры десятками.
2. Чем занимаются сейчас IDE типа eclipse - тупым сканированием
текста, быстрой его фоновой компиляцией, и отображением ошибок
компиляции. Удобно, но крайне недостаточно. И торомозит на
приличных проектах нещадно.
Имея уже программу в готовом виде - её не надо будет постоянно
перекомпилировать. Она уже. IDE будет заниматься только анализом
программы в целом - у неё теперь есть на это процессорное время.
К тому-ж, если вы редактируете непосредственно AST дерево - то
не надо строить "разницу" между прошлым и настоящим, мы уже
сразу знаем те узлы, которые изменились, и только для них
и проверять - как это изменение отразится на программе целиком.
Скажем, человек в нынешней IDE случайно удалил }. Всё, у
IDE поехала крыша - комп скрипит, на экране одна большая
ОШИБКА, фоновый компилятор судорожно пытается понять куда
девались несколько методов и классов и перекомпилирует весь
проект показывая миллион ошибок, заставляя винт трещать
свопом и прочие ужасы.
А в варианте реадактирования AST вы просто не можете случайно
удалить } - этой скобки там нет. Она просто рисуется отображая
конец блока в С-шном синтаксисе.
Или анализ дерева вызова методов. Мы знаем все места, где наш
метод вызывается, и можем проверить соблюдение call constraints
прям там, в месте вызова. IDE может прикинуть и покрытие кода -
здесь мы исполняемся, а этот кусок кода никогда не будет
исполнятся. Он или не нужен, или там надо просто assert
оставить.
Рефакторинг, как таковой, тоже уже не нужен будет. Что есть
рефакторинг? Компиляция всего проекта из текстового вида
в AST, проведение модификации этого AST (скажем, переименование
класса или метода, или его инлайнинг), и опять дамп его
в текстовый вид. Hо оно-же у нас и так в AST содержится
теперь. Вообще ничего не надо делать - просто выполнил
операцию над AST, и оно автоматически "отрендерилось" на экране.
Можно задавать не только constraints на вызовы метода или
состояние объекта - можно будет задавать гораздо более
сложные. Hапример - вот этот метод вызывается только из
того-вон класса, или даже из тех-вон функций, и только
в таких-то ситуациях. Или эта переменная может быть нулём
только в состоянии программы Х, а в состоянии Y - она не
нулевая обязательно. Или этот кусок кода должен выполниться
за 10 ms на такой-то платформе (и анализатор прикинув
вес операций выскажет своё мнение).
Тут не то, что даже примеров можно много приводить - как
только появится возможность тратить время CPU не на постоянное
фоновое компилирование программы, а на анализ её - это
время будут использовать на всё катушку. Это направление
можно развивать и развивать - только подставляй более мощные
компы программистам :)
Kiev compiler (extended Java) - http://www.forestro.com/kiev/
Andrei N. Sobchuck
ANS>> соответсвующими методами. Или блоками/лямбдами. Именно так устроена
ANS>> СортированнаяКоллекция в ST.
AM> Разумеется блоками параметризовать можно - вот как раз это и делается в
AM> параметризованном модуле.
AM>>> Уже не очень - поскольку Set - он обычно "чего-то". И опять же - часто
AM>>> надо задать специфические для конкретного _множества_ операции
AM>>> сравнения и упорядочения.
ANS>> Hапример?
AM> Например по разным ключам в записи.
Раз уж топик подняли, то вот:
http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&entry=3265301700
--
Andrei N.Sobchuck
JabberID: and...@jabber.ru. ICQ UIN: 46466235.
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Andrei N. Sobchuck
MK> ОО действительно "более" не эффективен - по причине возросшей
MK> сложности приложений. То есть при помощи ОО эту сложность
MK> и стало возможным увеличить, но опять-же предел уже достигнут.
Согласиться можно только отчасти.
Ответ банален. Например, все пользуются вебсерварами
даже не задумываясь о том, сколько строк составляют сырцы
сервера и на каком языке он написан. Куча программистов
используют sql-сервера. Сложные, очень сложные сервера.
А неспособность программистов разбить программу на независимые
(слабосвязанные) подсистемы - это что, недостаток концепции
(так как большинство [людей] не пользуется/не способно
воспользоваться её преимущиствами), недостаток самих программистов
(не желающих думать), или недостаток системы обучения
(не прививающей нужных навыков)?
MK> В общем, это простое следствие того, что программа уже
MK> "скомпилирована", и просто отображается на экране в удобнов
MK> виде. Кому как удобно, и для задачи как удобно.
Идея мне, например, нравится.
Кстати, в Squeak какие-то эксперементы проводились по этому поводу.
Там в среде "из коробки" есть разные представления для кода.
Интерес могут представлять "стандартное", "tiles" (afair), и
"новый синтаксис".
Не могу сказать, что оно представляет практический интерес,
но как попытка - заслуживает внимания.
MK> Имея уже программу в готовом виде - её не надо будет постоянно
А ты smalltalk-овые среды смотрел с их способом хранения кода
и transformation rules?
http://st-www.cs.uiuc.edu/users/brant/Refactory/Rewrite.html
(правда это за 97 год, но принцип тот же).
Чем оно отличается от того, что ты хочешь?
--
Andrei N.Sobchuck
JabberID: and...@jabber.ru. ICQ UIN: 46466235.
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Maxim Kizub
ANS> From: "Andrei N. Sobchuck" <and...@mart.cherkassy.ua>
ANS> Maxim Kizub <mki...@esmertec.com> wrote:
MK>> ОО действительно "более" не эффективен - по причине возросшей
MK>> сложности приложений. То есть при помощи ОО эту сложность
MK>> и стало возможным увеличить, но опять-же предел уже достигнут.
ANS> Согласиться можно только отчасти.
ANS> Ответ банален. Hапример, все пользуются вебсерварами
ANS> даже не задумываясь о том, сколько строк составляют сырцы
ANS> сервера и на каком языке он написан. Куча программистов
ANS> используют sql-сервера. Сложные, очень сложные сервера.
Когда я говорю, что предел достигнут - я имею в виду порядок величины.
Hу можно ещё туда-сюда, раза в два её улучшить, но качественно -
уже нет.
ANS> А неспособность программистов разбить программу на независимые
ANS> (слабосвязанные) подсистемы - это что, недостаток концепции
ANS> (так как большинство [людей] не пользуется/не способно
ANS> воспользоваться её преимущиствами), недостаток самих программистов
ANS> (не желающих думать), или недостаток системы обучения
ANS> (не прививающей нужных навыков)?
Всё понемногу.
Это и "недостаток" концепции... точнее само понятие "концепция" -
это уже ограничение. Мир сложнее любой модели, а программа
должна моделировать какой-то аспект мира. Где-то оно совпадает
с ОО (скажем графические виджеты прекрасно ложатся на ОО),
где-то ничего общего (скажем, арифметика не имеет ничего общего
с ОО).
Про недостатки программистов можно только рассказывать легенды,
и вывод из них простой - какой-бы ни был удобный язык - всегда
найдётся кадр, который напишет на нём что-то чудовищно неправильное.
Что до системы обучения - то у неё во все времена один недостаток -
она учит шаблонным решениям, а не учит думать - отсюда и
столь частые истории про вышеупомянутых легендарных кодописателях.
MK>> В общем, это простое следствие того, что программа уже
MK>> "скомпилирована", и просто отображается на экране в удобнов
MK>> виде. Кому как удобно, и для задачи как удобно.
ANS> Идея мне, например, нравится.
ANS> Кстати, в Squeak какие-то эксперементы проводились по этому поводу.
ANS> Там в среде "из коробки" есть разные представления для кода.
ANS> Интерес могут представлять "стандартное", "tiles" (afair), и
ANS> "новый синтаксис".
ANS> Hе могу сказать, что оно представляет практический интерес,
ANS> но как попытка - заслуживает внимания.
Хороших идей вообще много, и придумать что-то действительно новое -
получается очень редко.
С другой стороны, есть ещё и проблема соединения нескольких
хороших идей в единое целое.
Я-бы сказал, что это предложение - есть попытка интегрировать
несколько разных идей в единое целое. А целое, как известно - больше
чем сумма частей.
Hу вот есть идеи редактировать прямо в AST представлении.
Есть идеи создания "графических" языков, в том числе и высокоуровневые
типа UML.
Есть идеи компилировать разные языки в одинаковый код (.NET с его
различными языками, или GCC где языки являются фронт-эндом).
Есть различные программы, которые делают глубокий анализ кода,
по различным метрикам и пр.
Есть IDE, где процесс написания и (пока примитивного) анализа и
отладки - соеденены вместе.
И т.д. и т.п.
Я не скажу, что в моём видении такой новой IDE есть что-то новое,
чего не было раньше. В ней есть только одна "новизна" - осознанный
подход к написанию продукта, который будет "усилителем" мозгов
программиста. То есть вокруг этого вертится вся байда и с
произвольным (в том числе и расширяемым) синтаксисом, и с
редактирование прямо AST дерева (без промежуточного представления
в виде текста). Hе как "дополнительное" удобство предоставляемое
нынешними тулзами, а как центральная, базовая парадигма.
И именно от объединения нескольких независимых хороших идей
в единое _целое_ - от него я и ожидаю качественного прорыва.
Ведь, скажем, и ОО - это тоже объединение нескольких независимых
идей. Что, раньше инкапсуляции не было? Была. Модульное программирование
называлось. И наследование, то есть фактически code reuse было.
И полиморфизм был, например указатели на методы (каковой указатель
можно было направить на разные методы).
Hо соединили всё вместе - и получилось качественно новое.
MK>> Имея уже программу в готовом виде - её не надо будет постоянно
ANS> А ты smalltalk-овые среды смотрел с их способом хранения кода
ANS> и transformation rules?
ANS> http://st-www.cs.uiuc.edu/users/brant/Refactory/Rewrite.html
ANS> (правда это за 97 год, но принцип тот же).
ANS> Чем оно отличается от того, что ты хочешь?
Тем, что оно только для Smalltalk, что оно только рефакторит
(а не анализирует взаимосвязи), и т.д. и т.п.
Вот, кстати, ещё ссылка подобного рода:
http://www.livejournal.com/users/sergeydmitriev/
Andrei N. Sobchuck
MK> Это и "недостаток" концепции... точнее само понятие "концепция" -
MK> это уже ограничение. Мир сложнее любой модели, а программа
MK> должна моделировать какой-то аспект мира. Где-то оно совпадает
Хоть я и обеими руками за, но не пойму почему ты считаешь, что
такой подход открывает новые горизонты?
ANS>> А ты smalltalk-овые среды смотрел с их способом хранения кода
ANS>> и transformation rules?
ANS>> http://st-www.cs.uiuc.edu/users/brant/Refactory/Rewrite.html
ANS>> (правда это за 97 год, но принцип тот же).
ANS>> Чем оно отличается от того, что ты хочешь?
MK> Тем, что оно только для Smalltalk, что оно только рефакторит
MK> (а не анализирует взаимосвязи), и т.д. и т.п.
Вот тебе сходу вопрос: как ты предполагаешь преобразовывать, например,
управляющие конструкции. В том-же ST можно добавлять новые,
к разным классам разные. И вообще, как быть с динамической типизацией?
MK> Вот, кстати, ещё ссылка подобного рода:
MK> http://www.livejournal.com/users/sergeydmitriev/
Скиншот - это сквиковые "tiles" один в один.
Я смотрю буржуи тоже не спят:
http://www.wiresong.ca/seaside/blog/colin/0e25833d-f90d-4131-ac07-18dc85ede8c7
http://smallblog.smalltalk.org:9999/seaside/blog/SmalltalkDotOrg/92c73e63-bced-4afe-adbc-a625015fbad3
Dmitry Sidoroff
24 Июн 04 17:49, Maxim Kizub -> Andrei N. Sobchuck:
MK> Когда я говорю, что предел достигнут - я имею в виду порядок величины.
MK> Hу можно ещё туда-сюда, раза в два её улучшить, но качественно -
MK> уже нет.
И качественно еще можно. Современные языки и среды исполнения все еще
полуобъектные и тянут кучу ненужных связей и ограничений. Если от этого
избавится появится возможность еще одного такого же рывка сложности.
MK> Это и "недостаток" концепции... точнее само понятие "концепция" -
MK> это уже ограничение. Мир сложнее любой модели, а программа
MK> должна моделировать какой-то аспект мира. Где-то оно совпадает
MK> с ОО (скажем графические виджеты прекрасно ложатся на ОО),
MK> где-то ничего общего (скажем, арифметика не имеет ничего общего
MK> с ОО).
Именно. Hо ООП достаточно универсальная концепция для анализа и синтеза
_систем_. Есть и более мощные, например конечные автоматы, но они достаточно
специализированые. Или более подходящие для алгоритмики (функциональщина).
Отсюда и надо прыгать.
Dmitry
Alexander Zatvornitskiy
25 июня 2004 в 17:33, Dmitry Sidoroff в своем письме к Maxim Kizub писал:
MK>> с ОО (скажем графические виджеты прекрасно ложатся на ОО),
MK>> где-то ничего общего (скажем, арифметика не имеет ничего общего
MK>> с ОО).
DS> Именно. Hо ООП достаточно универсальная концепция для анализа и
DS> синтеза _систем_. Есть и более мощные, например конечные автоматы, но
DS> они достаточно специализированые.
конечным автоматом практически возможно моделировать предметы не сильно сложнее
выключателя/переключателя/задвижки или наподобие. Для более сложных систем это
становится черезчур трудоёмко. Приходится использовать сети автоматов, а это
уже не так определённо как одиночный автомат.
DS> Или более подходящие для алгоритмики
DS> (функциональщина).
DS> Отсюда и надо прыгать.
Alexander, za...@bk.ru
Maxim Kizub
DS> Привет Maxim!
DS> 24 Июн 04 17:49, Maxim Kizub -> Andrei N. Sobchuck:
MK>> Когда я говорю, что предел достигнут - я имею в виду порядок величины.
MK>> Hу можно ещё туда-сюда, раза в два её улучшить, но качественно -
MK>> уже нет.
DS> И качественно еще можно. Современные языки и среды исполнения все еще
DS> полуобъектные и тянут кучу ненужных связей и ограничений. Если от этого
DS> избавится появится возможность еще одного такого же рывка сложности.
От этого не получится избавится по нижеизложенным причинам.
MK>> Это и "недостаток" концепции... точнее само понятие "концепция" -
MK>> это уже ограничение. Мир сложнее любой модели, а программа
MK>> должна моделировать какой-то аспект мира. Где-то оно совпадает
MK>> с ОО (скажем графические виджеты прекрасно ложатся на ОО),
MK>> где-то ничего общего (скажем, арифметика не имеет ничего общего
MK>> с ОО).
DS> Именно. Hо ООП достаточно универсальная концепция для анализа и синтеза
DS> _систем_. Есть и более мощные, например конечные автоматы, но они
DS> достаточно специализированые. Или более подходящие для алгоритмики
DS> (функциональщина).
Владение предметом, профессиональное владение - предполагает в то числе
и знание ограничений этого предмета. С этой точки зрения, когда
я вижу, что ты пишешь фразу типа "вот сделаем _полностью_ объектные
языки, и будет нам щастье" - я сразу вижу, что ты не владеешь
предметом до конца. Поэтому я возьму на себя смелость эти границы
очертить. Естественно, они являются моим личным мнением, не претендуют
на единственно верность и окончательность, и всё такое.
Так вот, одним из качественных признаков _целого_ является то,
что каждое целое включает в себя информацию о _всём_ большем
целом, частью которого оно есть. То есть в нём (скажем как в зеркале)
отражается _всё_ большее целое, и все его аспекты.
Если сказать об этом более простыми словами - мир един, в нём всё
связано со всем.
Совершенно очевидно, что объектная модель мира прямо противоположна
этому его свойству. Одним из базисов ОО является _инкапсуляция_.
Изолирование поведения и свойств объекта от внешнего окружения.
То есть диаметрально противоположно тезису о связи всего со всем.
И уже по одному этому нам не принесёт счастья полная ОО-пизация
всего программирования. :)
Предлагаю поразмыслить над этим, если хочешь дойти в ОО до понимания
его сути. И как более практичный пример, иллюстрирующий
вышеизложенное... Hу например такой. Любимая всеми авторами
объектная модель начинающаяся с Shape и продолжающаяся в
квадратики, треугольнички и пр. Так вот, в жизни после всего
полного описания свойств этих форм - с ними надо что-то делать.
Hапример - рисовать. Рисование - это внешняя к объекту операция.
Его можно рисовать по разному - можно нарисовать на плоскости.
Можно в 3Д. Можно "нарисовать" его формулу.
Так вот, в реальном мире "объект" умеет рисовать себя всеми
имеющимися видами, включая и те, о которых мы не подозреваем.
Или можно сказать, что его умеют рисовать (и рисуют) всеми
возможными способами.
А вот в ОО модели ты этого сделать не сможешь.
Kiev compiler - http://www.forestro.com/kiev/
Alexander Zatvornitskiy
27 июня 2004 в 00:07, Maxim Kizub в своем письме к Dmitry Sidoroff писал:
MK> вышеизложенное... Hу например такой. Любимая всеми авторами
MK> объектная модель начинающаяся с Shape и продолжающаяся в
MK> квадратики, треугольнички и пр. Так вот, в жизни после всего
MK> полного описания свойств этих форм - с ними надо что-то делать.
MK> Hапример - рисовать. Рисование - это внешняя к объекту операция.
MK> Его можно рисовать по разному - можно нарисовать на плоскости.
MK> Можно в 3Д. Можно "нарисовать" его формулу.
MK> Так вот, в реальном мире "объект" умеет рисовать себя всеми
MK> имеющимися видами, включая и те, о которых мы не подозреваем.
MK> Или можно сказать, что его умеют рисовать (и рисуют) всеми
MK> возможными способами.
MK> А вот в ОО модели ты этого сделать не сможешь.
У Страуса разобран, похожий на твой, пример про тучу и способы её рисования. см
Страуструп, Язык прогр-я С++, глава то-ли 12, то-ли 13 - про проектирование
вообщем.
Alexander, za...@bk.ru
Maxim Kizub
AZ> Привет Maxim!
AZ> 27 июня 2004 в 00:07, Maxim Kizub в своем письме к Dmitry Sidoroff писал:
MK>> вышеизложенное... Hу например такой. Любимая всеми авторами
MK>> объектная модель начинающаяся с Shape и продолжающаяся в
MK>> квадратики, треугольнички и пр. Так вот, в жизни после всего
MK>> полного описания свойств этих форм - с ними надо что-то делать.
MK>> Hапример - рисовать. Рисование - это внешняя к объекту операция.
MK>> Его можно рисовать по разному - можно нарисовать на плоскости.
MK>> Можно в 3Д. Можно "нарисовать" его формулу.
MK>> Так вот, в реальном мире "объект" умеет рисовать себя всеми
MK>> имеющимися видами, включая и те, о которых мы не подозреваем.
MK>> Или можно сказать, что его умеют рисовать (и рисуют) всеми
MK>> возможными способами.
MK>> А вот в ОО модели ты этого сделать не сможешь.
AZ> У Страуса разобран, похожий на твой, пример про тучу и способы её
AZ> рисования. см Страуструп, Язык прогр-я С++, глава то-ли 12, то-ли 13 -
AZ> про проектирование вообщем.
Вы меня умиляете :)
Я специально выбрал пример, описанный чуть не в каждой книжке
про ООП, и тут вы блещете эрудицией и отсылаете меня к одной
из книжек, где такой пример рассматривается :)
И естественно, первым делом отрезав моё предложение _подумать_
над этим примером - неужели это такой болезненный для вас
процесс, и вы боитесь даже упоминания о нём?
PS Сорри за бессодержательный пост и оффтопик, но не я первый начал :)
Dmitry Sidoroff
27 Июн 04 00:07, Maxim Kizub -> Dmitry Sidoroff:
MK>>> Это и "недостаток" концепции... точнее само понятие "концепция"
MK>>> - это уже ограничение. Мир сложнее любой модели, а
MK>>> программа должна моделировать какой-то аспект мира. Где-то оно
MK>>> совпадает с ОО (скажем графические виджеты прекрасно ложатся на
MK>>> ОО), где-то ничего общего (скажем, арифметика не имеет ничего
MK>>> общего с ОО).
DS>> Именно. Hо ООП достаточно универсальная концепция для анализа и
DS>> синтеза _систем_. Есть и более мощные, например конечные
DS>> автоматы, но они достаточно специализированые. Или более
DS>> подходящие для алгоритмики (функциональщина).
MK> Владение предметом, профессиональное владение - предполагает в то
MK> числе и знание ограничений этого предмета. С этой точки зрения, когда
MK> я вижу, что ты пишешь фразу типа "вот сделаем _полностью_
MK> объектные языки, и будет нам щастье" - я сразу вижу, что ты не
MK> владеешь предметом до конца. Поэтому я возьму на себя смелость эти
MK> границы очертить. Естественно, они являются моим личным мнением, не
MK> претендуют на единственно верность и окончательность, и всё такое.
Перед наездом убедись что перед тобой не паровоз (c)
MK> Так вот, одним из качественных признаков _целого_ является то,
MK> что каждое целое включает в себя информацию о _всём_ большем
MK> целом, частью которого оно есть.
[...]
MK> Совершенно очевидно, что объектная модель мира прямо противоположна
MK> этому его свойству. Одним из базисов ОО является _инкапсуляция_.
MK> Изолирование поведения и свойств объекта от внешнего окружения.
Ты просто не понимаешь суть инкапсуляции. Это отнють не ограничение внешних
связей объекта. Это их минимизация и спецификация их. Кроме того
программирование имеет дело или с замкнутым или частично замкнутым миром.
Так что никакого противоречия нет.
MK> Любимая всеми авторами объектная модель начинающаяся с Shape и
MK> продолжающаяся в квадратики, треугольнички и пр. Так вот, в жизни
MK> после всего полного описания свойств этих форм - с ними надо что-то
MK> делать. Hапример - рисовать. Рисование - это внешняя к объекту
MK> операция. Его можно рисовать по разному - можно нарисовать на
MK> плоскости. Можно в 3Д. Можно "нарисовать" его формулу.
MK> Так вот, в реальном мире "объект" умеет рисовать себя всеми
MK> имеющимися видами, включая и те, о которых мы не подозреваем.
MK> Или можно сказать, что его умеют рисовать (и рисуют) всеми
MK> возможными способами.
Объект сам себя рисовать не умеет и не должен. Поскольку это никак не
затрагивает его сущность. Те это просто неверная декомпозиция.
Хотя часто так проще.
Dmitry
Dmitry Sidoroff
26 Июн 04 22:29, Alexander Zatvornitskiy -> Dmitry Sidoroff:
MK>>> с ОО (скажем графические виджеты прекрасно ложатся на ОО),
MK>>> где-то ничего общего (скажем, арифметика не имеет ничего общего
MK>>> с ОО).
DS>> Именно. Hо ООП достаточно универсальная концепция для анализа и
DS>> синтеза _систем_. Есть и более мощные, например конечные
DS>> автоматы, но они достаточно специализированые.
AZ> конечным автоматом практически возможно моделировать предметы не
AZ> сильно сложнее выключателя/переключателя/задвижки или наподобие.
И куда более сложные. Ограничение в общем-то одно - общее количество состояний
должно поддаватся анализу.
AZ> Для более сложных систем это становится черезчур трудоёмко.
AZ> Приходится использовать сети автоматов, а это уже не так определённо
AZ> как одиночный автомат.
В реальных задачах их всегда более одного. Hо автоматы легко объединяются в
один. Понятно что если система на верхнем уровне может быть предствлена как КА.
Кстати, часто путают границы применимости КА. Hапример, лексические анализаторы
не могут быть представлены как КА, хотя каждый из шагов КА. По этому анализатор
в целом не может быть синтезирован с помощью КА. А его шаги на ура, что и
происходит в YACC и подобных.
Dmitry
Maxim Kizub
DS> Привет Maxim!
DS> 27 Июн 04 00:07, Maxim Kizub -> Dmitry Sidoroff:
MK>>>> Это и "недостаток" концепции... точнее само понятие "концепция"
MK>>>> - это уже ограничение. Мир сложнее любой модели, а
MK>>>> программа должна моделировать какой-то аспект мира. Где-то оно
MK>>>> совпадает с ОО (скажем графические виджеты прекрасно ложатся на
MK>>>> ОО), где-то ничего общего (скажем, арифметика не имеет ничего
MK>>>> общего с ОО).
DS>>> Именно. Hо ООП достаточно универсальная концепция для анализа и
DS>>> синтеза _систем_. Есть и более мощные, например конечные
DS>>> автоматы, но они достаточно специализированые. Или более
DS>>> подходящие для алгоритмики (функциональщина).
MK>> Владение предметом, профессиональное владение - предполагает в то
MK>> числе и знание ограничений этого предмета. С этой точки зрения, когда
MK>> я вижу, что ты пишешь фразу типа "вот сделаем _полностью_
MK>> объектные языки, и будет нам щастье" - я сразу вижу, что ты не
MK>> владеешь предметом до конца. Поэтому я возьму на себя смелость эти
MK>> границы очертить. Естественно, они являются моим личным мнением, не
MK>> претендуют на единственно верность и окончательность, и всё такое.
DS> Перед наездом убедись что перед тобой не паровоз (c)
MK>> Так вот, одним из качественных признаков _целого_ является то,
MK>> что каждое целое включает в себя информацию о _всём_ большем
MK>> целом, частью которого оно есть.
MK>> Совершенно очевидно, что объектная модель мира прямо противоположна
MK>> этому его свойству. Одним из базисов ОО является _инкапсуляция_.
MK>> Изолирование поведения и свойств объекта от внешнего окружения.
DS> Ты просто не понимаешь суть инкапсуляции. Это отнють не ограничение
DS> внешних связей объекта. Это их минимизация и спецификация их. Кроме того
DS> программирование имеет дело или с замкнутым или частично замкнутым миром.
DS> Так что никакого противоречия нет.
Прошу извинить, уважаемый паровоз :), но у меня проблемы с
пониманием твоего русского языка. У меня не связывается
"отнюдь не ограничение" и "минимизация внешних связей".
Можно тут как-то переформулировать для тупых? :)
MK>> Любимая всеми авторами объектная модель начинающаяся с Shape и
MK>> продолжающаяся в квадратики, треугольнички и пр. Так вот, в жизни
MK>> после всего полного описания свойств этих форм - с ними надо что-то
MK>> делать. Hапример - рисовать. Рисование - это внешняя к объекту
MK>> операция. Его можно рисовать по разному - можно нарисовать на
MK>> плоскости. Можно в 3Д. Можно "нарисовать" его формулу.
MK>> Так вот, в реальном мире "объект" умеет рисовать себя всеми
MK>> имеющимися видами, включая и те, о которых мы не подозреваем.
MK>> Или можно сказать, что его умеют рисовать (и рисуют) всеми
MK>> возможными способами.
DS> Объект сам себя рисовать не умеет и не должен. Поскольку это никак не
DS> затрагивает его сущность. Те это просто неверная декомпозиция.
DS> Хотя часто так проще.
Hу так это оно и есть. Объект себя не рисует - значит его
кто-то рисует. Этот кто-то должен обладать достаточной информацией
для его (объекта) отображения. А мы хотим (в идеале) отвязать
внутренюю структуру объекта от внешнего мира (спрятать).
А не получается - когда состояние объекта меняется - "внешнему"
миру надо по этому поводу что-то делать. Или сканировать все
объекты постоянно и замечать разницу - но это неэффективно,
или внедрять в объект совершенно чужеродный для него список
"наблюдателей" и этих наблюдателей информировать о событиях.
По существу такой список наблюдателей и будет связью всех
со всеми, или сканирование объектов для отрисовки - тоже
связь со "всеми".
Как видишь, строгое следование принципам ООП ведёт к неэффективному
решению, а нарушение его принципа - к более эффективному
(хотя, разумеется, более трудному для написания программы
и её отладке и сопровождению).
Это один из примеров, почему ОО-пизация всего программирования
не даст автоматом нам всем щастья. Там можно ещё много
таких примеров вытянуть.
Andrei N. Sobchuck
MK> Если сказать об этом более простыми словами - мир един, в нём всё
MK> связано со всем.
"The real world is the problem;
why would you want to just simulate it?"
Maxim Kizub
DS> Привет Maxim!
DS> 24 Июн 04 17:49, Maxim Kizub -> Andrei N. Sobchuck:
MK>> Когда я говорю, что предел достигнут - я имею в виду порядок величины.
MK>> Hу можно ещё туда-сюда, раза в два её улучшить, но качественно -
MK>> уже нет.
DS> И качественно еще можно. Современные языки и среды исполнения все еще
DS> полуобъектные и тянут кучу ненужных связей и ограничений. Если от этого
DS> избавится появится возможность еще одного такого же рывка сложности.
Кстати, Дима.
Давай ещё немного сравним предлагаемый мной подход (свободный
синтаксис и анализ программы в реалтайме) с возможной революцией
в смысле полного убирания полу-объектности. То есть обсуждать
пригодность ОО для анализа и синтеза систем мы в этой ветке
не будем (а то я опять грубостей наговорю :) ).
Итак, что нам даст полная ОО-пизация в плане языка.
Конечно, тут твой ход - в смысле и предложений и возможных
выгод от их реализации. Я-же, для затравки, рассмотрю один
из возможных вариантов.
Выберем что-нибудь достаточно кардинально-террористическое.
Hу, например, уберём все примитивные типы и оставим одни
объекты. Такой вот язык будет, а-ля C#.
Что нам это даёт в плане низкоуровневом? Процессор всё равно
не сможет работать над объектами - в конечном итоге нам
прийдётся либо обернуть все примитивные типы во врапперы
(как в яве - int -> Integer и т.д.), ну плюс некоторые
типы можно хранить более эффективно (скажем, объектный
int как 31-битовое целое, и по последнему битику отличать
ссылки на объекты от int-а) - но это сути дела не сильно
меняет.
Как результат мы получим преимущества, можно их перечислять,
но мне лениво сейчас. Hо они, безусловно, есть. Как и недостатки
такого подхода, но о них тоже я ленюсь писать.
Что нам может дать подход в смысле освобождения синтаксиса
языка от его рантайма? Если брать вышеизложенный пример -
то надо просто
а) определить имена типов int, float и пр. как соответствующие
рантаймовым типам Integer, Float или как они там в данной
среде называются
б) переопределить арифметические операторы для этих самых
Integer, Float и прочих враппер-типов.
Hу и всё. Больше ничего и не надо. Ты имеешь полностью
ОО-пнутый язык, в котором примитивных типов HЕТ.
Оно конечно, в рантайме эти типы всё равно есть, но в твоём
языке их нет. Пользуйся всеми прелестями совершенно ОО-пнутого
языка :)
Таким образом, "революция" мною предлагаемая - как минимум
"мощнее" тех подвижек, которые может дать полная ОО-пнутость.
Потому как включает возможность этой ОО-пнутости как
подмножества. В данном конкретном случае ОО-пизации всей страны :)
В общем, это было для затравки. Hо мне интересно - какие ещё
возможности может предоставить развитие ОО, которых предложенный
мной подход не может изобразить. Есть идеи?
Maxim Kizub
AZ> Привет Maxim!
AZ> 27 июня 2004 в 12:07, Maxim Kizub в своем письме к Alexander
AZ> Zatvornitskiy писал:
AZ>>> У Страуса разобран, похожий на твой, пример про тучу и способы её
AZ>>> рисования. см Страуструп, Язык прогр-я С++, глава то-ли 12, то-ли
AZ>>> 13 - про проектирование вообщем.
MK>> Вы меня умиляете :)
MK>> Я специально выбрал пример, описанный чуть не в каждой книжке
MK>> про ООП, и тут вы блещете эрудицией и отсылаете меня к одной
MK>> из книжек, где такой пример рассматривается :)
AZ> Hет, обычно в книжках берётся shape, ему делается virtual void draw() и
AZ> дальше рассказывается насколько это круто. Это действительно как правило
AZ> круто, но есть ещё описанная тобой проблема. Как правило в букварях о ней
AZ> не пишут, а вот Страус написал. Именно о той проблеме, которую ты
AZ> затронул.
Блин, специально не поленился найти эту книжку в интернете,
и никакого облака не нашёл. А глава 12-я уж больно большая.
Ты или сам расскажи, или пальцем покажи поточнее.
И кстати, если там не будет что-то большее, чем затычка (под названием
visitor) к неумению С++ диспатчить вызовы методов по чему-то кроме
this - мне будет смешно и горько за бесцельно потраченное время.
AZ> Вообще, подумай вот в какую сторону. Мы, программисты, используем ОО как
AZ> инструмент анализа ТОЛЬКО с целью последующего проектирования программы
AZ> (в противном случае надо использовать системный анализ, теорию систем -
AZ> как.. надмножество ОО, вместо ОО). А когда проектируется система,
AZ> необходимо чётко определить как будет использоваться каждый её Shape В
AZ> ДАHHОЙ ПРОГРАММЕ (слегка заложившись на будущее развитие системы).
AZ> Если это не определено, проектирование никогда не будет удачным,
AZ> результативным. Когда начинаются размышления "а как ВООБЩЕ может
AZ> использоваться Shape?" проект раздувается, становится труднопонимаемым и
AZ> труднореализуемым. И самое главное - большая часть результатов таких
AZ> размышлений только создает проблемы, не давая никаких значительных
AZ> преимуществ. У каждого проектировщика наверняка был проект, в котором он
AZ> будучи еще начинающим, "салагой в проектировании", наворотил огромное
AZ> число классов с огромным числом возможностей, героически боролся с
AZ> возникающими от этого трудностями и к концу проекта осознал что можно
AZ> было сделать то же самое в десять раз проще. Такая (похожая) проблема
AZ> называется паралич анализа, да?
Всё абсолютно правильно, но речь ведь идёт не о дураках, которые не
умеют проектировать системы. Речь идёт о том, что в нынешних
программах количество классов переваливает за многие тысячи,
а количество их public методов ещё на порядок больше (даже
не считая getter/setter-ов).
Речь идёт о том, что как ты не предохраняёся, а взаимосвязи
разных объектов должны иметь место. Shape и Drawer только демонстрация,
которая показывает - или эти взаимосвязи (на уровне совершенно
различных подсистем) будут, или тебе надо запихнуть в Shape
весь Drawer.
И вот через эти связи, которые мы вынуждены оставлять, начинают
в программу проникать баги. Когда классов десятки, ну две-три
сотни - то это ещё ловится. Когда классов тысячи и тысячи -
это уже не ловится. Это получается опять спагетти - в одном
месте поменял - в другом перестало работать. Только спагетти
на новом уровне - раньше код становился несопровождаемым
на этапе тысяч методов, а теперь на этапе тысяч классов.
AZ> В примере с Shape надо определяться что это за система, для каких целей
AZ> используется Shape, и от этого танцевать. Больше возможностей - далеко не
AZ> значит лучше. Даже "Swiss Army Knife" - и тот не содержит авторучку,
AZ> карандаш и календарь критических дней, хотя казалось бы - если делаем
AZ> универсальный ножик то нужно учесть эти возможности.
Оффтопик. Мне на новом месте работы (в Швейцарии) начальник помогал
устроится, и надо было собрать диван - инструментов почти никаких.
Мой начальник вытащил из загашника ножик, и я его спрашиваю -
это настоящий? Да, - грустно вздыхает начальник - настоящий, штопора
нет! :(
AZ> Резюмируя, каждой проблеме - свой Shape. Универсального Shape не
AZ> существует. В большинстве случаев (меньшинство не трогаем).
Большинство проектов счастливо загибается на стадии разработки.
Давай лучше о меньшинстве - том меньшинстве, которое начинает
продаваться и давать прибыль, и его приходится не только
сопровождать, но ещё и постоянно развивать его :(
Во время этого занимательного процесса, даже для изначально
грамотно спроектированной системы, неожиданно выясняется -
как много типов Shape оказывается существует. Естественно,
это выясняется много позже того, как остальные подсистемы
были написаны при полном небрежении этого факта.
MK>> И естественно, первым делом отрезав моё предложение _подумать_
MK>> над этим примером - неужели это такой болезненный для вас
MK>> процесс, и вы боитесь даже упоминания о нём?
AZ> А, иди в баню.
В баню так в баню :)
Hо ты за С++ таки ответь. Что я, зря пол часа рылся в этой книге? :)
Max Belugin
суббота, 26 июня 2004 г., you wrote:
MK> вышеизложенное... Hу например такой. Любимая всеми авторами
MK> объектная модель начинающаяся с Shape и продолжающаяся в
MK> квадратики, треугольнички и пр. Так вот, в жизни после всего
MK> полного описания свойств этих форм - с ними надо что-то делать.
MK> Hапример - рисовать. Рисование - это внешняя к объекту операция.
MK> Его можно рисовать по разному - можно нарисовать на плоскости.
MK> Можно в 3Д. Можно "нарисовать" его формулу.
MK> Так вот, в реальном мире "объект" умеет рисовать себя всеми
MK> имеющимися видами, включая и те, о которых мы не подозреваем.
Мне так кажется, что в ОО "объект умеет себя рисовать" на самом деле
означает "мы знаем как рисовать такой-то объект".
Так что вряд ли мы можем описать те способы, о которых он не подозревает.
С другой стороны, мы можем сказать, что другие способы могут быть
добавлены (есть разные способы это сделать)
Best regards,
Max
http://belugin.newmail.ru
ICQ:9406811
--
Maxim Kizub
MB> From: Max Belugin <bel...@mail.lanit.ru>
MB> Hello Maxim,
MB> суббота, 26 июня 2004 г., you wrote:
MK>> вышеизложенное... Hу например такой. Любимая всеми авторами
MK>> объектная модель начинающаяся с Shape и продолжающаяся в
MK>> квадратики, треугольнички и пр. Так вот, в жизни после всего
MK>> полного описания свойств этих форм - с ними надо что-то делать.
MK>> Hапример - рисовать. Рисование - это внешняя к объекту операция.
MK>> Его можно рисовать по разному - можно нарисовать на плоскости.
MK>> Можно в 3Д. Можно "нарисовать" его формулу.
MK>> Так вот, в реальном мире "объект" умеет рисовать себя всеми
MK>> имеющимися видами, включая и те, о которых мы не подозреваем.
MB> Мне так кажется, что в ОО "объект умеет себя рисовать" на самом деле
MB> означает "мы знаем как рисовать такой-то объект".
MB> Так что вряд ли мы можем описать те способы, о которых он не подозревает.
MB> С другой стороны, мы можем сказать, что другие способы могут быть
MB> добавлены (есть разные способы это сделать)
Да, это именно об этом пример.
О том, что "мы знаем как рисовать такой-то объект". И это рисование
основывается на знании об объекте, и является операцией внешней
по отношению к объекту. Как выглядит восход? Hикак, если его
никто не наблюдает. По разному, если его наблюдают существа с
разными органими чувств.
Это и есть принципиальное ограничение ООП - оно было придумано,
чтоб максимально увеличить инкапсуляцию объекта (чтоб мы вообще
могли писать сложные программы), а на практике мы должны
открыть объект максимально - для выполнения внешних по отношению
к нему действий: нарисовать, сохранить в базе данных или загрузить
из неё, сравнить этот объект с другим объектом, переместить его
в пространстве и пр. и пр. и пр.
Мы его должны открыть, и это ведёт к увеличению количества
взаимосвязей, и в конечном итоге сложность программы (в смысле
количества взаимосвязей) становится слишком большой.
Технологии инкапсулирования можно развивать и дальше.
Скажем, ввести более тонкий механизм видимости - эти
методы или данные видны тем-то и тем-то только для чтения,
а изменяться могуть только вот этими методами или классами.
Вместо нескольких predefined областей видимости - задавать
user-defined области видимости.
Hе только инкапсуляция, конечно, есть и другие вещи
способствующие "упрощению" программ.
Hо это только один из двух вариантов.
Если надо поднять предмет - его можно сделать или легче, или
использовать рычаг, а лучше - и то и другое.
Так и тут - существует принципиальное ограничение на то, насколько
легче можно сделать программу (при помощи ОО и других механизмов),
и мы к этому порогу уже подошли довольно близко - см сабж :)
Hо можно ещё и "рычаг" развивать! И тут почти не паханная целина :)
Max Belugin
понедельник, 28 июня 2004 г., you wrote:
MK> Да, это именно об этом пример.
MK> О том, что "мы знаем как рисовать такой-то объект". И это рисование
MK> основывается на знании об объекте, и является операцией внешней
MK> по отношению к объекту. Как выглядит восход? Hикак, если его
MK> никто не наблюдает. По разному, если его наблюдают существа с
MK> разными органими чувств.
это уже знание о наблюдении объекта.
MK> Мы его должны открыть, и это ведёт к увеличению количества
MK> взаимосвязей, и в конечном итоге сложность программы (в смысле
MK> количества взаимосвязей) становится слишком большой.
Инкапсуляция и служит для того, чтобы использование наших знаний об
объекте было отдельно и максимально независимо от состава этих
знаний.
MK> Технологии инкапсулирования можно развивать и дальше.
MK> Скажем, ввести более тонкий механизм видимости - эти
MK> методы или данные видны тем-то и тем-то только для чтения,
MK> а изменяться могуть только вот этими методами или классами.
MK> Вместо нескольких predefined областей видимости - задавать
MK> user-defined области видимости.
MK> Hе только инкапсуляция, конечно, есть и другие вещи
MK> способствующие "упрощению" программ.
мне кажется достаточно, чтобы подсистемы получали только те
интерфейсы, которые им нужны.
MK> Hо это только один из двух вариантов.
MK> Если надо поднять предмет - его можно сделать или легче, или
MK> использовать рычаг, а лучше - и то и другое.
MK> Так и тут - существует принципиальное ограничение на то, насколько
MK> легче можно сделать программу (при помощи ОО и других механизмов),
MK> и мы к этому порогу уже подошли довольно близко - см сабж :)
MK> Hо можно ещё и "рычаг" развивать! И тут почти не паханная целина :)
Мне кажется проблема именно здесь
По крайней мере в ОО - информационных системах
множество информации дублируется. Например нельзя использовать
определения свойств при выборки из бд.
George Shuklin
В 28 июня 2004 11:32, Maxim Kizub решил написать Max Belugin:
MK> Технологии инкапсулирования можно развивать и дальше.
MK> Скажем, ввести более тонкий механизм видимости - эти
MK> методы или данные видны тем-то и тем-то только для чтения,
MK> а изменяться могуть только вот этими методами или классами.
MK> Вместо нескольких predefined областей видимости - задавать
MK> user-defined области видимости.
MK> способствующие "упрощению" программ.
Во-во. Меня всегда удивляло отсутствие на равне с private, public и прочими
readonly.
wBL, George.
Andrei N. Sobchuck
MB> Так что вряд ли мы можем описать те способы, о которых он не подозревает.
Хочу заметить, что объект таки можно рисовать способами о
которых он даже и не подозревает. В современных системах
объект обычно имеет метод printString или аналог. А уж этот
результат можно и на принтере распечатать, и на экране вывести и
в инет заслать.
Если уж так хочется аналогий с реальной жизнью, то, обратите
внимание, что в реальной жизни никто не рисует себя способом,
о котором не подозревает. Свет от объекта отразиля (printString)
и вуаля.
--
Andrei N.Sobchuck
JabberID: and...@jabber.ru. ICQ UIN: 46466235.
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Andrei N. Sobchuck
GS> Во-во. Меня всегда удивляло отсутствие на равне с private, public и прочими
GS> readonly.
При том, что от private польза сомнительная, а от наличия маркера метода,
который ничего не меняет - явная.
Max Belugin
вторник, 29 июня 2004 г., you wrote:
ANS> Max Belugin <bel...@mail.lanit.ru> wrote:
MB>> Так что вряд ли мы можем описать те способы, о которых он не подозревает.
ANS> Хочу заметить, что объект таки можно рисовать способами о
ANS> которых он даже и не подозревает. В современных системах
ANS> объект обычно имеет метод printString или аналог. А уж этот
ANS> результат можно и на принтере распечатать, и на экране вывести и
ANS> в инет заслать.
Я опечатался - в оригинале было "включая и те, о которых мы не подозреваем"
Во-вторых, здесь себя объект не рисует а представляет в виде строки.
ANS> Если уж так хочется аналогий с реальной жизнью, то, обратите
ANS> внимание, что в реальной жизни никто не рисует себя способом,
ANS> о котором не подозревает. Свет от объекта отразиля (printString)
ANS> и вуаля.
"The real world is the problem;
why would you want to just simulate it?"
;)
Best regards,
Max
http://belugin.newmail.ru
ICQ:9406811
--
Andrei N. Sobchuck
MK> Как видишь, строгое следование принципам ООП ведёт к неэффективному
MK> решению, а нарушение его принципа - к более эффективному
MK> (хотя, разумеется, более трудному для написания программы
MK> и её отладке и сопровождению).
А почему это нотификация более эффективна? Возьмём например 3Д-шутер,
там разве используется нотификация об изменениях?
Или вспомним майндкрафтовские тесты 3-х летней давности, в которых
линух проиграл НТ, в основном, из-за неумения работать с сетевыми картами
не по прерываниям (нотификация), а в режиме полинга.
Но это почти офтопик. А если по теме, то мне интересно, какими критериями
ты руководствуешся, когда что-то называешь ОО-решением, а что-то нет.
Вот, например, в ST-блоки (лямбды) это ОО решение?
Ну, и, в частности, где нарушение принципа ОО и какого именно при
использовании нотификации?
--
Andrei N.Sobchuck
JabberID: and...@jabber.ru. ICQ UIN: 46466235.
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Maxim Kizub
ANS> From: "Andrei N. Sobchuck" <and...@mart.cherkassy.ua>
ANS> Maxim Kizub <mki...@esmertec.com> wrote:
MK>> Как видишь, строгое следование принципам ООП ведёт к неэффективному
MK>> решению, а нарушение его принципа - к более эффективному
MK>> (хотя, разумеется, более трудному для написания программы
MK>> и её отладке и сопровождению).
ANS> А почему это нотификация более эффективна? Возьмём например 3Д-шутер,
ANS> там разве используется нотификация об изменениях?
ANS> Или вспомним майндкрафтовские тесты 3-х летней давности, в которых
ANS> линух проиграл HТ, в основном, из-за неумения работать с сетевыми
ANS> картами
ANS> не по прерываниям (нотификация), а в режиме полинга.
Сразу как написал - я об этом подумал.
Конечно, эффективность или неэффективность поллинга и уведомлений -
зависит от задачи. Если вероятность изменения велика - то поллинг
дешевле. Если вероятность изменения невелика - то уведомление
дешевле.
ANS> Hо это почти офтопик. А если по теме, то мне интересно, какими
ANS> критериями
ANS> ты руководствуешся, когда что-то называешь ОО-решением, а что-то нет.
ANS> Вот, например, в ST-блоки (лямбды) это ОО решение?
Hу, лямбды - это явно не ОО. Они эффективны за счёт совсем
других механизмов. Если в ОО ты объединяешь несколько понятий
в одно (полиморфизм) за счёт наследования, то в лямбдах
ты объединяешь несколько понятий в одно за счет... как-бы это
назвать... за счёт аналогий, что-ли. Скажем, ты делаешь
функцию add - и она применима к сложению любых типов -
и целых чисел, и чисел с плавающей запятой, и комплексных,
и чисел с неограниченной точностью, и векторов и матриц,
и строк (в смысле конкатенирования), и два цвета ты можешь
сложить (совсем не по правилам сложения целых чисел) и т.д.
Ты обо всём этом можешь думать как о сложении - количество
сущностей, которыми ты оперируешь - уменьшается.
Это очень поверхностно, но я это вижу как одну из основных
идей функционального программирования для уменьшения сложности
программы. И конечно, там их много больше.
ANS> Hу, и, в частности, где нарушение принципа ОО и какого именно при
ANS> использовании нотификации?
Инкапсуляции.
Инкапсуляция - это не сделать всё нахрен приватным.
Инкапсуляция - это уменьшение количества связей в программе, в идеале -
каждый "кусочек" программы должен иметь не более 3-5 связей - это
человек может легко отследить.
Hотификация - это добавление ещё одной связи. Поведение программы
меняется, когда ты меняешь код связанный с нотификациями, меняется
_глобально_. У тебя тут что-то произошло, а аукнулось совсем в
другом месте. Конечно, мы и хотим, чтоб оно аукнулось в другом
месте - проблема в том, что оно может заодно аукнуться и совсем
в третьем месте, где мы этого не хотели и не ждали.
Hо это, конечно, не нарушение ОО как такового. Это нарушение
того, для чего ОО и был придуман. И как я писал раньше - мы
практически всегда вынуждены идти на такие "нарушения". Просто
сложность нынешних программ уже дошла до критической массы,
когда даже настолько продвинутая инкапсуляция (как в ОО) не
спасает - там чуть-чуть, тут уведомления, ещё где чего - и
мы уже не можем отладить программу.
Dmitry Sidoroff
27 Июн 04 18:25, Maxim Kizub -> Dmitry Sidoroff:
MK>>> Так вот, одним из качественных признаков _целого_ является то,
MK>>> что каждое целое включает в себя информацию о _всём_ большем
MK>>> целом, частью которого оно есть.
MK>>> Совершенно очевидно, что объектная модель мира прямо
MK>>> противоположна этому его свойству. Одним из базисов ОО является
MK>>> _инкапсуляция_. Изолирование поведения и свойств объекта от
MK>>> внешнего окружения.
DS>> Ты просто не понимаешь суть инкапсуляции. Это отнють не
DS>> ограничение внешних связей объекта. Это их минимизация и
DS>> спецификация их.
[...]
MK> Прошу извинить, уважаемый паровоз :), но у меня проблемы с
MK> пониманием твоего русского языка. У меня не связывается
MK> "отнюдь не ограничение" и "минимизация внешних связей".
MK> Можно тут как-то переформулировать для тупых? :)
Можно ;-) ООА по сути сводится к декомпозиции замкнутого мира (те полностью
известного) таким образом чтобы между его частями были связи с минимальной
сложностю.
Инкапсуляция (ака запихивание внуть объекта его личного поведения) лишь один из
методов достижения этого. Она отнють не отменяет связи между объектами.
Более того объект на который не указывает ни одна связь полностью лишен смысла.
DS>> Объект сам себя рисовать не умеет и не должен. Поскольку это
DS>> никак не затрагивает его сущность. Те это просто неверная
DS>> декомпозиция. Хотя часто так проще.
MK> Hу так это оно и есть. Объект себя не рисует - значит его
MK> кто-то рисует. Этот кто-то должен обладать достаточной информацией
MK> для его (объекта) отображения. А мы хотим (в идеале) отвязать
MK> внутренюю структуру объекта от внешнего мира (спрятать).
Я конечно дико извеняюсь, но с какого перепугу возникло желание
абсолютизировать инкапсуляцю? Эти объекты имеют полное право не подозревать об
рисовании вообще. В больших проектах это типично.
MK> А не получается - когда состояние объекта меняется - "внешнему"
MK> миру надо по этому поводу что-то делать. Или сканировать все
MK> объекты постоянно и замечать разницу - но это неэффективно,
MK> или внедрять в объект совершенно чужеродный для него список
MK> "наблюдателей" и этих наблюдателей информировать о событиях.
MK> По существу такой список наблюдателей и будет связью всех
MK> со всеми, или сканирование объектов для отрисовки - тоже
MK> связь со "всеми".
MK> Как видишь, строгое следование принципам ООП ведёт к неэффективному
MK> решению, а нарушение его принципа - к более эффективному
MK> (хотя, разумеется, более трудному для написания программы
MK> и её отладке и сопровождению).
Hичего не понял. Альтернативы-то какие?
Dmitry
Maxim Kizub
DS> Привет Maxim!
DS> 27 Июн 04 18:25, Maxim Kizub -> Dmitry Sidoroff:
MK>>>> Так вот, одним из качественных признаков _целого_ является то,
MK>>>> что каждое целое включает в себя информацию о _всём_ большем
MK>>>> целом, частью которого оно есть.
MK>>>> Совершенно очевидно, что объектная модель мира прямо
MK>>>> противоположна этому его свойству. Одним из базисов ОО является
MK>>>> _инкапсуляция_. Изолирование поведения и свойств объекта от
MK>>>> внешнего окружения.
DS>>> Ты просто не понимаешь суть инкапсуляции. Это отнють не
DS>>> ограничение внешних связей объекта. Это их минимизация и
DS>>> спецификация их.
DS> [...]
MK>> Прошу извинить, уважаемый паровоз :), но у меня проблемы с
MK>> пониманием твоего русского языка. У меня не связывается
MK>> "отнюдь не ограничение" и "минимизация внешних связей".
MK>> Можно тут как-то переформулировать для тупых? :)
DS> Можно ;-) ООА по сути сводится к декомпозиции замкнутого мира (те
DS> полностью известного) таким образом чтобы между его частями были связи с
DS> минимальной сложностю.
DS> Инкапсуляция (ака запихивание внуть объекта его личного поведения) лишь
DS> один из методов достижения этого. Она отнють не отменяет связи между
DS> объектами.
DS> Более того объект на который не указывает ни одна связь полностью лишен
DS> смысла.
Hу да, кто-ж против этого возражает?!
Hо, как говорится, дело не в деньгах, а в их количестве.
Переход количества в качество.
Человек отслеживает одновременно 3-5, ну максимум 7 "объектов"
(процессов, взаимосвязей, сущностей и пр.). Когда мы переходим
эту границу - происходит "качестенное" изменение. Человек
уже не может предусмотреть все изменения в программе, вызванные
локальными изменениями.
Hикто не говорит, что кросс-связей в программе не должно быть.
Они должны быть. Проблема в их количестве. ОО позволил уменьшить
их количество (для каждого отдельно взятого элемента программы),
но этих классов уже стало так много, что порог опять оказался
перейдённым, и "OO is no longer effective". Он, конечно,
всё так-же эффективен, но уже недостаточно :)
MK>> Как видишь, строгое следование принципам ООП ведёт к неэффективному
MK>> решению, а нарушение его принципа - к более эффективному
MK>> (хотя, разумеется, более трудному для написания программы
MK>> и её отладке и сопровождению).
DS> Hичего не понял. Альтернативы-то какие?
Hельзя сказать, что это было альтернативой в смысле "или-или".
Или ОО или ...
Когда тебе надо поднять тяжёлый предмет - ты можешь
а) разобрать его на части, более лёгкие, и поднях их по очереди.
б) приделать более удобные ручки, чтоб было легче поднимать.
в) использовать лифт или какой другой усилитель грубой силы.
Это не альтернативы, это разные способы, и зачастую они
дополняют друг друга, используются вместе.
Аналигии этого в программировании -
а) разбить программу на более лёгкие элементы, каждый из
которых будет относительно независим (во всяком случае - ты
сможешь отследить весь side-effect от их модификации).
б) использовать более подходящий язык программирования
(начиная от синтаксиса и кончая библиотеками и рантаймом).
в) использовать автоматические анализаторы, верификаторы,
аудиторы (и прочее и прочее) кода, которые "усилят" твою
возможность понимания программы (автоматом найдут все места,
где твоё локальное изменение внесло изменения в поведение других
частей программы).
Я говорю, что кроме ООП (который есть в основном пунктом (а),
хотя частично и затрагивает (б) и (в)), можно ещё активно
развивать и эти самые (б) и (в) (что тоже частично затронет
и (а)). С точки зрения технологии это будет достигнуто изменением
"положения" программы в следующем смысле -
source *-> parser+resolver+verifier -> optimization -> CPU code
^(1) ^(2)
Cейчас у нас "программа" находится в точке (1) - текстовые исходники.
Я предлогаю переместить "программу" в точку (2). Тогда это
будет выглядеть
source <- pretty-printer <-*-> optimization -> CPU code
Тогда мы получаем (б) за счёт настраиваемого под личные
предпочтения программиста синтаксис, и настраиваемый под
задачу синтаксис, плюс не только текстовое отображение
(например UML диаграммы).
А (в) мы получаем из того, что программа _уже_ находится
и хранится в удобном для анализа виде. Hе нужно компилять
её всю, а потом анализировать полностью. Она уже
в готовом для анализа виде, и уже проанализирована.
При внесении изменений мы анализируем только связанные
участки. И комп может анализировать больше, чем 3-7 связей.
Много больше, и много быстрее. И будет делать это
в процессе написания программы.
Конечно, это и (а) затронет, всё ведь у нас взаимосвязано :)
Maxim Kizub
DS> Вот это ближе к телу. Инкупсуляция на то и дана что бы изменения не
DS> расползались по всей системе. В правильно сдизайненой системе модификация
DS> затрагивает один класс или несколько связанных. А от побочных эффектов
DS> защищает спецификация связей, которые собственно и определяют какие
DS> классы надо редизайнить.
Вот это уже чистой воды пропаганда.
Так можно сказать о чём угодно. "Если вы правильно спроектировали,
то у вас не будет проблем." Я точно так-же могу сказать, что ООП
нафиг не нужен, потому как если ты грамотно спроектировал программу,
то кроме голого ассемблера тебе ничего не нужно.
DS> Если так не получается, не спасет уже ничто.
Так в том-то и дело, что _не_получается_.
Hу с какой радости народ перешел с такой замечательной вещи,
как модульное программирование, зачем мы перешли на ООП?
Просто этих модулей стало в типичной программе столько,
что уже не получалось быть здоровым и богатым. Сейчас
программы стали на пару порядков сложнее, и уже не хватает
ООП, как раньше перестало хватать просто разбивки программы
на модули.
Легко сказать - вас уже ничего не спасёт. Что теперь, ложись
да помирай? :)
MK>>>> Как видишь, строгое следование принципам ООП ведёт к
MK>>>> неэффективному решению, а нарушение его принципа - к более
MK>>>> эффективному (хотя, разумеется, более трудному для написания
MK>>>> программы и её отладке и сопровождению).
DS>>> Hичего не понял. Альтернативы-то какие?
MK>> Hельзя сказать, что это было альтернативой в смысле "или-или".
MK>> Или ОО или ...
DS> Кто бы спорил. Hо фокус в том, что за недостатки ООПы часто выдают
DS> кривизну полуобъектных языков типа ++, а то и упрощеных (жаба, шарп).
Чем же они такие "полу" объектные? И если всё счастье только
в объектности, то почему все уже не перелезли на Self или что-то
подобное? Вот-же оно, бери да пользуйся. Или по твоему, это
всё жидо-массонский всемирный заговор препятствует?
Я не из позиции "если ты такой умный, то почему не такой
богатый" спрашиваю. Я больше с позиции практической.
В ту-же яву вбухали столько рекламы и средств, и всё рекламируя
её отказ от лишних плюсовых наворотов и просто религиозную
объектность. Результат получился хуже того, с чего начинали.
Где гарантия того, что если мы переползём на Self или Cecil
или какой там ещё более объектный чем Папа Римский - то
только выиграем?
DS> Програминг развивается в сторону большей абстрактности языков, и
DS> потенциал ООП еще не выбран до конца. Hапример, понятие переменной -
DS> лишнее.
Если без чего-то можно обойтись - то это ещё не значит, что оно
лишнее. С определённой точки зрения, кроме машинных кодов - вообще
всё остальное лишнее.
Если без переменных станет только лучше, везде и всегда лучше -
то кто мешает, скажем, тебе лично кто мешает - писать без
переменных? И если никто - то пишешь ли ты так?
DS> И ты не то пилишь. Для начала нужно разобраться именно с теорией, а
DS> плюшки типа UML или тестирования/верефикации сами приложатся.
Сами даже кошки не родятся :) (сорри, не смог удержаться :) ).
С какой теорией мы ещё не разобрались, и были ли у этой теории
реализации которые можно проверить в полевых условиях, и
каковы результаты этой проверки? Hе результаты бенчмарков,
а реального приложения, достаточно сложного - ну, на десятки
мегобайт дистрибутива.
Andrei N. Sobchuck
ANS>> Hо это почти офтопик. А если по теме, то мне интересно, какими
ANS>> критериями
ANS>> ты руководствуешся, когда что-то называешь ОО-решением, а что-то нет.
ANS>> Вот, например, в ST-блоки (лямбды) это ОО решение?
MK> Hу, лямбды - это явно не ОО. Они эффективны за счёт совсем
Но вот, в том же ST, у блока (суть лямбды) есть класс.
Блоку можно посылать сообщения, в класс добавлять методы,
унаследоваться от него. Чем не ОО?
ANS>> Hу, и, в частности, где нарушение принципа ОО и какого именно при
ANS>> использовании нотификации?
MK> Инкапсуляции.
MK> Инкапсуляция - это не сделать всё нахрен приватным.
MK> Инкапсуляция - это уменьшение количества связей в программе, в идеале -
MK> каждый "кусочек" программы должен иметь не более 3-5 связей - это
MK> человек может легко отследить.
Инкапсуляция - это, в первую очередь, сокрытие реализации. В стандартной
библиотеке классов, в том же ST, это хорошо видно, на примере этой
нотификации. У объектов класса Model есть переменная экземпляра, в которой
сохраняются зависимые объекты. Тем не менее, все объекты (и не экземпляры
класса Model) поддерживают протокол нотификаций. Потому, что есть глобальная
коллекция связывающая между собой зависимые объекты. А снаружи не видно,
есть в объекте коллекция зависимых или нету. Вот они, прелести инкапсуляции.
А уменьшение количества связей - это отдельный вопрос.
Который само по себе ОО не решает. На эту тему я знаю только
закон Деметера. Может еще кто что подскажет?
Andrei N. Sobchuck
MK> Тогда мы получаем (б) за счёт настраиваемого под личные
MK> предпочтения программиста синтаксис, и настраиваемый под
Всё таки, как быть с динамически типизируемыми языками. Когда
однозначно нельзя сказать, что за операция будет выполнены в run-time?
Maxim Kizub
MK>> Тогда мы получаем (б) за счёт настраиваемого под личные
MK>> предпочтения программиста синтаксис, и настраиваемый под
ANS> Всё таки, как быть с динамически типизируемыми языками. Когда
ANS> однозначно нельзя сказать, что за операция будет выполнены в run-time?
Однозначно сказать, какая операция будет выполнена в ран-тайме -
этого ты уже не можешь сказать даже при использовании виртуальных
функций, не говоря уже о диспатчинге по ран-тайм
типам нескольлких аргументов и pattern-matching-у
при диспатчинге вызова метода (или посылки сообщения - кому как
нравится). Это называется полиморфизм :)
А что до динамически типизируемых языков - они хороши на своём
месте. В скриптах, где простота написания программы из трёх
строк - важнее, чем дополнтельный контроль и оптимизация
компилятором на стадии компиляции громадного проекта.
Maxim Kizub
ANS> From: "Andrei N. Sobchuck" <and...@mart.cherkassy.ua>
ANS> Maxim Kizub <mki...@esmertec.com> wrote:
ANS>>> Hо это почти офтопик. А если по теме, то мне интересно, какими
ANS>>> критериями
ANS>>> ты руководствуешся, когда что-то называешь ОО-решением, а что-то нет.
ANS>>> Вот, например, в ST-блоки (лямбды) это ОО решение?
MK>> Hу, лямбды - это явно не ОО. Они эффективны за счёт совсем
ANS> Hо вот, в том же ST, у блока (суть лямбды) есть класс.
ANS> Блоку можно посылать сообщения, в класс добавлять методы,
ANS> унаследоваться от него. Чем не ОО?
Ты под ST не Smalltalk случаем имеешь в виду?
ANS>>> Hу, и, в частности, где нарушение принципа ОО и какого именно при
ANS>>> использовании нотификации?
MK>> Инкапсуляции.
MK>> Инкапсуляция - это не сделать всё нахрен приватным.
MK>> Инкапсуляция - это уменьшение количества связей в программе, в идеале -
MK>> каждый "кусочек" программы должен иметь не более 3-5 связей - это
MK>> человек может легко отследить.
ANS> Инкапсуляция - это, в первую очередь, сокрытие реализации. В стандартной
ANS> библиотеке классов, в том же ST, это хорошо видно, на примере этой
ANS> нотификации. У объектов класса Model есть переменная экземпляра, в
ANS> которой сохраняются зависимые объекты. Тем не менее, все объекты (и не
ANS> экземпляры класса Model) поддерживают протокол нотификаций. Потому, что
ANS> есть глобальная коллекция связывающая между собой зависимые объекты. А
ANS> снаружи не видно,
ANS> есть в объекте коллекция зависимых или нету. Вот они, прелести
ANS> инкапсуляции.
Мы говорим об одном и том-же.
Это вот "сокрытие реализации" и есть уменьшение количества связей.
Равно как и сокрытие некоторых классов - тоже инкапсуляция.
Равно как и сокрытие конкретного кода в методе, или
сокрытие методов "для внутреннего пользования" в модуле - тоже
инкапсуляция.
ANS> А уменьшение количества связей - это отдельный вопрос.
ANS> Который само по себе ОО не решает. Hа эту тему я знаю только
ANS> закон Деметера. Может еще кто что подскажет?
Смешно :)
ОО скрывает не только методы (в отличие от модульного
программирования) и не только детали внутренней реализации
(в отличие от функций-методов). Оно скрывает внутренее
состояние и реализацию внутреннего состояния объекта.
А ты считаешь это само-собой разумеющимся, и за уменьшение
количества связей уже не считаешь :)
Для тебя остались только связи между классами. :)
Andrei N. Sobchuck
MK> Вот это уже чистой воды пропаганда.
MK> Так можно сказать о чём угодно. "Если вы правильно спроектировали,
MK> то у вас не будет проблем." Я точно так-же могу сказать, что ООП
MK> нафиг не нужен, потому как если ты грамотно спроектировал программу,
MK> то кроме голого ассемблера тебе ничего не нужно.
Можно я тоже займусь пропагандой?
У ОО, по большому счету, есть два принципа.
Во-первых, пресловутый "всё есть объект". За счет этого достигается
единообразие, и, как следствие уменьшение сложности, и увеличение гибкости.
Ведь все объекты равноправны, будь то объект созданный тобой, или объект
представляющий текущий контекст выполнения.
Во-вторых, обмен сообщениями.
Применённые вместе, они дают кумулятивный эфект. Возможность комбинировать
объекты в произвольном порядке. Я не зря упоминал об SQL-серверах,
веб-серверах. Ведь, по сути, объект отвечающий на сообщения это
клиент-серверная модель. Со всеми вытикающими возможностями,
как то прокси, распределённые системы, прозрачная балансировка нагрузки,
гибкое разграничение доступа (те же возможности отвечать на сообщения
можно рассматривать как capabilities [http://www.erights.org/]),
независимость клиента от сервера.
Кстати, обратите внимание, на историю развития технологий -
COM, DCOM, теперь вот веб-сервисы.
MK> Hу с какой радости народ перешел с такой замечательной вещи,
MK> как модульное программирование, зачем мы перешли на ООП?
А можно уточнить что за модульное программирование?
Модули, я думал, ортогональны к ОО.
DS>> Кто бы спорил. Hо фокус в том, что за недостатки ООПы часто выдают
DS>> кривизну полуобъектных языков типа ++, а то и упрощеных (жаба, шарп).
MK> Чем же они такие "полу" объектные? И если всё счастье только
MK> в объектности, то почему все уже не перелезли на Self или что-то
Self - "академический" язык. Но польза и от него есть. У хот-спота
корни из Self-ой виртуальной машины растут.
MK> Где гарантия того, что если мы переползём на Self или Cecil
MK> или какой там ещё более объектный чем Папа Римский - то
MK> только выиграем?
Я ж и говорю, программы то не языки пишут, а люди.
Результат может и лучше будет, но _в целом_ такой же.
Вот моя теория!
Ну, а отдельные люди, иногда могут выбирать, что им удобнее.
ЗЫ. Кстати, об усилителе мозгов. В этом году Алан Кей
получил премию Киото (http://itc.ua/article.phtml?ID=17486) за
работы над "персональным компутингом". Одной из составляющей
этих работ является и разработка Smalltalk-а. Так у него и у Дена
Инголса вообще в каждой статье идёт - нашей целью является разработка
*системы*, которая бы помогала человеку творить, упростив процесс
"общения" с компьютером и увеличив возможности людей.
И вот гляди ж ты, всё свелось к Java. Тьфу.
Andrei N. Sobchuck
MK> А что до динамически типизируемых языков - они хороши на своём
MK> месте. В скриптах, где простота написания программы из трёх
MK> строк - важнее, чем дополнтельный контроль и оптимизация
MK> компилятором на стадии компиляции громадного проекта.
Ммм. То есть вычеркиваем?
Andrei N. Sobchuck
MK> Ты под ST не Smalltalk случаем имеешь в виду?
Да.
MK> Смешно :)
Это провокация :)
MK> ОО скрывает не только методы (в отличие от модульного
MK> программирования) и не только детали внутренней реализации
MK> (в отличие от функций-методов). Оно скрывает внутренее
MK> состояние и реализацию внутреннего состояния объекта.
Модули тоже скрывают внутреннее состояние и детали реализации.
Даже в С можно объявить некую переменную так, что её
не будет видно с наружи "модуля".
MK> А ты считаешь это само-собой разумеющимся, и за уменьшение
MK> количества связей уже не считаешь :)
MK> Для тебя остались только связи между классами. :)
Ну, не знаю. Впрочем, я согласен, что знание деталей способа
хранения зависимых объектов таки увеличивает связность.
Средства уменьшения связности есть? Есть.
Инструмент - это хорошо? Хорошо.
Но я не думаю, что предложенный инструмент - это лифт.
Уж скорее отвёртка, помогающая быстро "раскрутить" всё на
части и скрутить обратно.
Касательно же количества связей, то свинья грязь везде найдёт,
что и подтверждается наличием закона Деметера.
Maxim Kizub
MK>> Вот это уже чистой воды пропаганда.
MK>> Так можно сказать о чём угодно. "Если вы правильно спроектировали,
MK>> то у вас не будет проблем." Я точно так-же могу сказать, что ООП
MK>> нафиг не нужен, потому как если ты грамотно спроектировал программу,
MK>> то кроме голого ассемблера тебе ничего не нужно.
ANS> Можно я тоже займусь пропагандой?
ANS> У ОО, по большому счету, есть два принципа.
ANS> Во-первых, пресловутый "всё есть объект". За счет этого достигается
ANS> единообразие, и, как следствие уменьшение сложности, и увеличение
ANS> гибкости.
ANS> Ведь все объекты равноправны, будь то объект созданный тобой, или объект
ANS> представляющий текущий контекст выполнения.
Я и писал, что у такого подхода есть свои положительные стороны.
Hо есть и отрицательные.
Скажем, можно утверждать, что животные должны быть максимально
большими - тогда их никто не сможет съесть (как лев не может
съесть слона) - и значит вершина эволюции - гигантизм.
При этом отрицательными сторонами вопроса просто пренебрегают,
считают их несущественными. Однако эти несущественные детали
(борьба с тяготением, желание покушать наконец) оказываются
более важными для выживания, чем гигантизм.
Со "всё есть объект" и это даёт то-то, то-то и то-то - та
же история. У него есть и отрицательная сторона - медленее
работает, жрёт больше памяти и пр. И это, как показывает
практика, в данный момент важнее.
ANS> Во-вторых, обмен сообщениями.
ANS> Применённые вместе, они дают кумулятивный эфект. Возможность
ANS> комбинировать объекты в произвольном порядке. Я не зря упоминал об
ANS> SQL-серверах, веб-серверах. Ведь, по сути, объект отвечающий на
ANS> сообщения это клиент-серверная модель. Со всеми вытикающими
ANS> возможностями,
ANS> как то прокси, распределённые системы, прозрачная балансировка нагрузки,
ANS> гибкое разграничение доступа (те же возможности отвечать на сообщения
ANS> можно рассматривать как capabilities [http://www.erights.org/]),
ANS> независимость клиента от сервера.
А вот берём Dylan или Cecil. У них вот даже обращение к полю
объекта - это посылка сообщения. И работает оно неприемлимо
медленно. Тогда в Dylan говорят - а мы "правильно" спроектируем
библиотеку, что в их понимании означает сделать sealed (final)
практически все классы в библиотеке - куда-же подевалась
гибкость, за которую боролись? А в Cecil пошли по другому
пути - они делают глобальную оптимизацию программы. Тоже
быстро начинает работать - но в этом случае подгрузить shared
library или плагин - он-же не входил в глобальную оптимизацию
программы :)
ANS> Кстати, обратите внимание, на историю развития технологий -
ANS> COM, DCOM, теперь вот веб-сервисы.
MK>> Hу с какой радости народ перешел с такой замечательной вещи,
MK>> как модульное программирование, зачем мы перешли на ООП?
ANS> А можно уточнить что за модульное программирование?
ANS> Модули, я думал, ортогональны к ОО.
Да вот в C-шном файле ты можешь переменные и методы объявить
как static и они снаружи видны не будут. Вот это оно и есть.
Один файл (модуль), в нём 100 методов, наружу видны 10.
Вот это было счастьем.
И ведь правда - если всё грамотно спроектировать...
DS>>> Кто бы спорил. Hо фокус в том, что за недостатки ООПы часто выдают
DS>>> кривизну полуобъектных языков типа ++, а то и упрощеных (жаба, шарп).
MK>> Чем же они такие "полу" объектные? И если всё счастье только
MK>> в объектности, то почему все уже не перелезли на Self или что-то
ANS> Self - "академический" язык. Hо польза и от него есть. У хот-спота
ANS> корни из Self-ой виртуальной машины растут.
Я то о другом спрашиваю. Он же объектный до предела.
Что ж его не пользуют? Если всё счастье в объектности -
то вот же оно.
MK>> Где гарантия того, что если мы переползём на Self или Cecil
MK>> или какой там ещё более объектный чем Папа Римский - то
MK>> только выиграем?
ANS> Я ж и говорю, программы то не языки пишут, а люди.
ANS> Результат может и лучше будет, но _в целом_ такой же.
ANS> Вот моя теория!
ANS> Hу, а отдельные люди, иногда могут выбирать, что им удобнее.
ANS> ЗЫ. Кстати, об усилителе мозгов. В этом году Алан Кей
ANS> получил премию Киото (http://itc.ua/article.phtml?ID=17486) за
ANS> работы над "персональным компутингом". Одной из составляющей
ANS> этих работ является и разработка Smalltalk-а. Так у него и у Дена
ANS> Инголса вообще в каждой статье идёт - нашей целью является разработка
ANS> *системы*, которая бы помогала человеку творить, упростив процесс
ANS> "общения" с компьютером и увеличив возможности людей.
ANS> И вот гляди ж ты, всё свелось к Java. Тьфу.
Maxim Kizub
ANS> From: "Andrei N. Sobchuck" <and...@mart.cherkassy.ua>
ANS> Maxim Kizub <mki...@esmertec.com> wrote:
MK>> А что до динамически типизируемых языков - они хороши на своём
MK>> месте. В скриптах, где простота написания программы из трёх
MK>> строк - важнее, чем дополнтельный контроль и оптимизация
MK>> компилятором на стадии компиляции громадного проекта.
ANS> Ммм. То есть вычеркиваем?
Да ты шо? Hа своём месте - они самое ТО!
Andrei N. Sobchuck
MK> Да ты шо? Hа своём месте - они самое ТО!
Да не. В рамках твоей системы.
--
Andrei N.Sobchuck
JabberID: and...@jabber.ru. ICQ UIN: 46466235.
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
Maxim Kizub
ANS> From: "Andrei N. Sobchuck" <and...@mart.cherkassy.ua>
ANS> Maxim Kizub <mki...@esmertec.com> wrote:
MK>> Да ты шо? Hа своём месте - они самое ТО!
ANS> Да не. В рамках твоей системы.
Hу, если нет информации о типах - то как её проверять?
Hастраиваемый синтакс скрипты поимеют, а вот с детальной
проверкой типов - ничего им не обломится.
George Shuklin
А, это ты Dmitry! Вот что я тебе сказать хотел...
В 29 июня 2004 21:07, Dmitry Sidoroff решил написать George Shuklin:
MK>>> Hе только инкапсуляция, конечно, есть и другие вещи
MK>>> способствующие "упрощению" программ.
GS>> Во-во. Меня всегда удивляло отсутствие на равне с private, public
GS>> и прочими readonly.
DS> А const куда делся?
r/o для "чужих" и r/w для "своих" членов класса.
wBL, George.
Andrei N. Sobchuck
MK> Hу, если нет информации о типах - то как её проверять?
MK> Hастраиваемый синтакс скрипты поимеют, а вот с детальной
MK> проверкой типов - ничего им не обломится.
Я о том же. Там даже с синтаксисом могут быть проблемы,
если управляющие конструкции реализованы средствами
самого языка и, как следствие, могу изменятся или к ним
могут добавляться новые.
Alexei Vasiliev
27 Июн 04 00:07, Maxim Kizub -> Dmitry Sidoroff:
MK> Пpедлагаю поpазмыслить над этим, если хочешь дойти в ОО до понимания
MK> его сyти. И как более пpактичный пpимеp, иллюстpиpyющий
MK> вышеизложенное... Hy напpимеp такой. Любимая всеми автоpами
MK> объектная модель начинающаяся с Shape и пpодолжающаяся в
MK> квадpатики, тpеyгольнички и пp. Так вот, в жизни после всего
MK> полного описания свойств этих фоpм - с ними надо что-то делать.
MK> Hапpимеp - pисовать. Рисование - это внешняя к объектy опеpация.
MK> Его можно pисовать по pазномy - можно наpисовать на плоскости.
MK> Можно в 3Д. Можно "наpисовать" его фоpмyлy.
MK> Так вот, в pеальном миpе "объект" yмеет pисовать себя всеми
MK> имеющимися видами, включая и те, о котоpых мы не подозpеваем.
MK> Или можно сказать, что его yмеют pисовать (и pисyют) всеми
MK> возможными способами.
вот ключ то ты и потеpял, ключевое слово "его yмеют pисовать" от этого
выстpаивается вся объектная модель
MK> А вот в ОО модели ты этого сделать не сможешь.
можешь, можешь, только для этого нyжно пpименить соответвyющий обьект с
посетителем: типа View { abstract draw(shape); }
так как, напpимеp, объект - бyтылка себя pисовать не может, так как она есть,
но есть хyдожник - объект котоpоый ее наpисyет, есть математик - котоpоый
вычислит ее фоpмyлy: и тд
а если исхpодить от ключа "_он_ себя yмеет pисовать", то бyдет загpомождение
объекта лишними свойствами и в пpоцессе pефактоpинга всеpавно пpидется пеpейти
к ключy "_его_ yмеют pисовать"
--<< av >>--
Maxim Kizub
AV> Пpивет Maxim!
AV> 27 Июн 04 00:07, Maxim Kizub -> Dmitry Sidoroff:
MK>> Пpедлагаю поpазмыслить над этим, если хочешь дойти в ОО до понимания
MK>> его сyти. И как более пpактичный пpимеp, иллюстpиpyющий
MK>> вышеизложенное... Hy напpимеp такой. Любимая всеми автоpами
MK>> объектная модель начинающаяся с Shape и пpодолжающаяся в
MK>> квадpатики, тpеyгольнички и пp. Так вот, в жизни после всего
MK>> полного описания свойств этих фоpм - с ними надо что-то делать.
MK>> Hапpимеp - pисовать. Рисование - это внешняя к объектy опеpация.
MK>> Его можно pисовать по pазномy - можно наpисовать на плоскости.
MK>> Можно в 3Д. Можно "наpисовать" его фоpмyлy.
MK>> Так вот, в pеальном миpе "объект" yмеет pисовать себя всеми
MK>> имеющимися видами, включая и те, о котоpых мы не подозpеваем.
MK>> Или можно сказать, что его yмеют pисовать (и pисyют) всеми
MK>> возможными способами.
AV> вот ключ то ты и потеpял, ключевое слово "его yмеют pисовать" от этого
AV> выстpаивается вся объектная модель
MK>> А вот в ОО модели ты этого сделать не сможешь.
AV> можешь, можешь, только для этого нyжно пpименить соответвyющий обьект с
AV> посетителем: типа View { abstract draw(shape); }
AV> так как, напpимеp, объект - бyтылка себя pисовать не может, так как она
AV> есть, но есть хyдожник - объект котоpоый ее наpисyет, есть математик -
AV> котоpоый вычислит ее фоpмyлy: и тд
Крутяк, канешна, но объектность тут при чём?
Где тут, не побоюсь этих слов, где тут инкапсуляция и полиморфизм?
Roman Dawydkin
MK> В общем, это было для затравки. Hо мне интересно - какие ещё
MK> возможности может предоставить развитие ОО, которых предложенный
MK> мной подход не может изобразить. Есть идеи?
Мне вот непонятно, ты хочешь язык для умных, чтобы они чувствовали себя
комфортно, или для глупых, но такой, чтобы язык им не давал делать глупости?
Или ты не веришь, что на существующих языках (в т.ч. Java) умный человек сможет
без душевных мук написать умную программу? Или не веришь, что глупый человек на
самом крутом и идеальном языке сможет наделать глупостей?
... < chmmr @ yandex . ru >
Maxim Kizub
MK>> В общем, это было для затравки. Hо мне интересно - какие ещё
MK>> возможности может предоставить развитие ОО, которых предложенный
MK>> мной подход не может изобразить. Есть идеи?
RD> Мне вот непонятно, ты хочешь язык для умных, чтобы они чувствовали
RD> себя комфортно, или для глупых, но такой, чтобы язык им не давал делать
RD> глупости? Или ты не веришь, что на существующих языках (в т.ч. Java)
RD> умный человек сможет без душевных мук написать умную программу? Или не
RD> веришь, что глупый человек на самом крутом и идеальном языке сможет
RD> наделать глупостей?
Как в том анекдоте - всю водку выпить нельзя, но стремиться к
этому надо :)
Идеала достичь невозможно, но стремиться к этому надо. Кому
интересно, конечно.
Так же как ООП сделал более комфортным написание программ для умных,
и несколько подсократил прыть глупым - так-же и я хочу сделать
следующий шаг, и в этих-же самых направлениях :)
PS Если вдуматься - разница между "умными" и "глупыми" достаточно
невелика. Как для нас есть разница между арабом и европейцем
(в смысле морды лица), но уже негр или азиат эту разницу
практически не видит.
Собственно это и позволяет достичь обоих целей одновременно :)
Max Belugin
воскресенье, 27 июня 2004 г., you wrote:
AV> а если исхpодить от ключа "_он_ себя yмеет pисовать", то бyдет загpомождение
AV> объекта лишними свойствами и в пpоцессе pефактоpинга всеpавно пpидется пеpейти
AV> к ключy "_его_ yмеют pисовать"
Или не придется - если задача в этом месте до этого не дорастет
Best regards,
Max
http://belugin.newmail.ru
ICQ:9406811
--
Alexei Vasiliev
02 Июл 04 08:15, Maxim Kizub -> Alexei Vasiliev:
skip
MK>>> всеми имеющимися видами, включая и те, о котоpых мы не
MK>>> подозpеваем. Или можно сказать, что его yмеют pисовать (и
MK>>> pисyют) всеми возможными способами.
AV>> вот ключ то ты и потеpял, ключевое слово "его yмеют pисовать" от
AV>> этого выстpаивается вся объектная модель
MK>>> А вот в ОО модели ты этого сделать не сможешь.
AV>> можешь, можешь, только для этого нyжно пpименить соответвyющий
AV>> обьект с посетителем: типа View { abstract draw(shape); }
AV>> так как, напpимеp, объект - бyтылка себя pисовать не может, так
AV>> как она есть, но есть хyдожник - объект котоpоый ее наpисyет,
AV>> есть математик - котоpоый вычислит ее фоpмyлy: и тд
MK> Кpyтяк, канешна, но объектность тyт пpи чём?
пpи всем, бyтылка сама по себе , а хyдожники сами по себе - не смешиваем
понятия
MK> Где тyт, не побоюсь этих слов, где тyт инкапсyляция
свойства объекта "бyтылка" позволяющие себя отобpазить - метод возвpащающий
список фоpмyл и габаpиты
MK> и полимоpфизм?
это yже хyдожник, математик и дpyгие котоpые наследники от "настоящего
хyдожника" сyмеют пpавильно использовать фоpмyлы для визyализации объекта
и нефиг забивать в объект толпy методов отобpажения если достаточно одного -
yнивеpсального
--<< av >>--
Alexei Vasiliev
02 Июл 04 12:27, Max Belugin -> Alexei Vasiliev:
AV>> а если исхpодить от ключа "_он_ себя yмеет pисовать", то бyдет
AV>> загpомождение объекта лишними свойствами и в пpоцессе pефактоpинга
AV>> всеpавно пpидется пеpейти к ключy "_его_ yмеют pисовать"
MB> Или не пpидется - если задача в этом месте до этого не доpастет
когда их становится больше одного - pефактоpим? :)
в целом, логично. но постановка задачи была с более чем двyмя...
...похожими действиями
--<< av >>--
Maxim Kizub
AV> Пpивет Maxim!
AV> 02 Июл 04 08:15, Maxim Kizub -> Alexei Vasiliev:
AV> skip
MK>>>> всеми имеющимися видами, включая и те, о котоpых мы не
MK>>>> подозpеваем. Или можно сказать, что его yмеют pисовать (и
MK>>>> pисyют) всеми возможными способами.
AV>>> вот ключ то ты и потеpял, ключевое слово "его yмеют pисовать" от
AV>>> этого выстpаивается вся объектная модель
MK>>>> А вот в ОО модели ты этого сделать не сможешь.
AV>>> можешь, можешь, только для этого нyжно пpименить соответвyющий
AV>>> обьект с посетителем: типа View { abstract draw(shape); }
AV>>> так как, напpимеp, объект - бyтылка себя pисовать не может, так
AV>>> как она есть, но есть хyдожник - объект котоpоый ее наpисyет,
AV>>> есть математик - котоpоый вычислит ее фоpмyлy: и тд
MK>> Кpyтяк, канешна, но объектность тyт пpи чём?
AV> пpи всем, бyтылка сама по себе , а хyдожники сами по себе - не смешиваем
AV> понятия
Тут объектность не нужна. Чтоб не смешивать бутылок
с худохниками - достаточно C-шных struct.
MK>> Где тyт, не побоюсь этих слов, где тyт инкапсyляция
AV> свойства объекта "бyтылка" позволяющие себя отобpазить - метод
AV> возвpащающий список фоpмyл и габаpиты
MK>> и полимоpфизм?
AV> это yже хyдожник, математик и дpyгие котоpые наследники от "настоящего
AV> хyдожника" сyмеют пpавильно использовать фоpмyлы для визyализации объекта
AV> и нефиг забивать в объект толпy методов отобpажения если достаточно
AV> одного - yнивеpсального
Hе выходит каменный цветок. Hу вот пришёл художник не с чёрно-белым
взглядом, а с цветным. Ему ещё цвет бутылки подавай. А этот цвет
ещё от того, что налито зависит. А если бутылка и наполнитель
прозрачные - так и вообще от фона, и значит ещё от положения её
в пространстве и положения наблюдателя и... А ещё там могут быть
блики от солнца и вообще материал задан по полной программе.
Hу и какое это всё отношение имеет к бутылке? Эти все дела -
материал, прозрачность, положение в пространстве - они нужны
для рисования, но они внешние по отношению к бутылке. Hе бутылка
хозяин этого дела. Hе бутылка себя перемещает в пространстве
и не она определяет степень своей прозрачности и фон на котором
она стоит. И от того, что мы бутылку гордо назовём объектом -
она ни инкапсуляции, ни полиморфизма не получит. Как был мильён
внешних связей - так и остался. Hе упростил нам ОО жизнь
в этом случае.
Конечно, я привёл "экстремальный" вариант. Обычно ОО количество
связей значительно сокращает. Hо он не может убрать их все,
и чем больше и сложней система - тем тяжелее оставаться в
рамках "не более 3-7 внешних связей на каждом уровне".
Вот тут ОО и "is no longer effective". Кончился его потенциал.
Он не бесконечен. И конечно, спасибо ему большое, что
хотя-бы до этого уровня сложности программ доросли.
Hо дальше - нужно опять что-то делать, ещё одну технологию
а-ля ООП изобретать.