Статья про развитие идей ООП. Жду комментариев.
От: Voblin Россия http://maslyaew.narod.ru/
Дата: 08.05.03 08:54
Оценка: 34 (7)
Может быть, кому-нибудь будет интересно.
http://voblin.nm.ru/objects_classes.dhtml
Сразу вопрос: стоит ли это опубликовать в RSDN?
Re: Статья про развитие идей ООП. Жду комментариев.
От: MadCoders Россия  
Дата: 08.05.03 09:28
Оценка:
Здравствуйте, Voblin, Вы писали:

V>Может быть, кому-нибудь будет интересно.

V>http://voblin.nm.ru/objects_classes.dhtml
V>Сразу вопрос: стоит ли это опубликовать в RSDN?

ну, написано неплохо, даже хорошо.
Мне понравилось, только по-моему, необходимо перед определением Объекта и экземпляра,дать определение класса.т.е. ты говоришь, что
Объект, экземпляр – информационная сущность, которой можно оперировать как единым целым.

что это за информационная сущность, мне кажеться. что
Класс является информационной сущностью,
а уже объектами класса можно оперировать как единым целым.


после определения класса стоит сказать, что можно создавать множество элементов, обладающих свойствами этого класса, и как раз эти элементы и являются Объектами.
т.е. можно привести жизненный пример:
у нас есть понятие сапожник,
если мы говорим, что Петя- сапожник, то все понимают, что Петя:
1)Мужского пола
2)Много материться

Ну вообще это только мое мнение.
...Почему разум становится более ленивым по мере развития технологий? Он привыкает к ним и не заботится о разработке новых...
Re[2]: Статья про развитие идей ООП. Жду комментариев.
От: Voblin Россия http://maslyaew.narod.ru/
Дата: 08.05.03 09:55
Оценка:
Здравствуйте, MadCoders, Вы писали:

MC>Мне понравилось, только по-моему, необходимо перед определением Объекта и экземпляра,дать определение класса.т.е. ты говоришь, что

MC> Объект, экземпляр – информационная сущность, которой можно оперировать как единым целым.

MC>что это за информационная сущность, мне кажеться. что

MC>Класс является информационной сущностью,
MC>а уже объектами класса можно оперировать как единым целым.

Изюминка в том и состоит, что отталкиваюсь я не от определения класса. Понятие класса появляется только в разделе "классификация". Если отталкиваться от понятия класса, то получится обычное, известное всем с пелёнок ООП, и ничего интересного не произойдёт.
Re: Статья про развитие идей ООП. Жду комментариев.
От: Аноним  
Дата: 08.05.03 10:00
Оценка:
Здравствуйте, Voblin, Вы писали:

V>Может быть, кому-нибудь будет интересно.

V>http://voblin.nm.ru/objects_classes.dhtml

Есть сильное подозрение, что в каких-нибудь исследовательских языках
все это давно рассмотрено и реализовано.
IMHO, в одном из диалектов LISP-а что-то подобное есть.
А в промышленные языки такое все-равно не пойдет — слишком сложно и для реализации,
и для использования.
Элементарные-то вещи реализовать в основных языках (С++, Java, C#, VB) не могут,
а тут такая революция.

V>Сразу вопрос: стоит ли это опубликовать в RSDN?


Конечно!
Re[2]: Статья про развитие идей ООП. Жду комментариев.
От: Voblin Россия http://maslyaew.narod.ru/
Дата: 08.05.03 10:31
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Есть сильное подозрение, что в каких-нибудь исследовательских языках

А>все это давно рассмотрено и реализовано.
Не удивлюсь.

А>IMHO, в одном из диалектов LISP-а что-то подобное есть.

Где-то когда-то всплывал CLOS.
По-моему, предлагаемое решение больше касается "обычных" языков программирования нежели языков логического программирования тип LISP и Prolog.

А>А в промышленные языки такое все-равно не пойдет — слишком сложно и для реализации,

А>и для использования.
Капля камень точит.
Реализация, конечно, сложновата, но, по-моему, овчинка выделки сторит.
Не добежим, так согреемся

А>Элементарные-то вещи реализовать в основных языках (С++, Java, C#, VB) не могут,

А>а тут такая революция.
А что делать?

V>Сразу вопрос: стоит ли это опубликовать в RSDN?

А>Конечно!
Попробую.
Re[3]: Статья про развитие идей ООП. Жду комментариев.
От: Аноним  
Дата: 08.05.03 11:15
Оценка:
Здравствуйте, Voblin, Вы писали:

V>Где-то когда-то всплывал CLOS.


Так он и сейчас есть (и компиляторы, и IDE, и библиотеки), а что толку? Кто на нем пишет?

V>По-моему, предлагаемое решение больше касается "обычных" языков программирования нежели языков логического программирования тип LISP и Prolog.


Что там такого в LISP-е логического?
Вполне "нормальньй" язык (относительно конечно), только возможностей много.
Вот никто и не пользуется — боятся, видимо.

V>Не добежим, так согреемся


Разве что.
Будет ли пользоваться успехом язык, в котором есть только одна фича (по сравнения, скажем с C#),
но зато полно недостатков — нет такой мощной поддержки, кучи библиотек (стандартных и сторонних),
серьезного компилятора и средства разработки, поддержки средств моделирования (например от Rational)
и т.п. и т.д. Можно продолжать бесконечно...

Сейчас наоборот наблюдается деградация языков программирования к более простым вариантам
(видимо программист пошел совсем недалекий).
Наглядный пример Java и VB — полные ничтожества в языковом плане, никаких понят... тьфу возможностей,
однако ведь лидеры промышленной разработки.
Где все разработки 70-х, 80-х годов — вычисляемые типы, контракты, пред- и постусловия, частично параметризованные функции,
лямбды, замыкания и т.д.?
Даже примитивный С++ с его жалкими темплейтами оказался слишком сложен — и вот вам С#!

Если же кого-то интересуют навороченные языковые возможности, то есть тот же CLOS, Smalltalk, SML, Haskell
(последний вроде как уже есть под .NET — H#).
Re[4]: Статья про развитие идей ООП. Жду комментариев.
От: joker6413  
Дата: 08.05.03 12:50
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Сейчас наоборот наблюдается деградация языков программирования к более простым вариантам

А>(видимо программист пошел совсем недалекий).

А по моему все логично. Индустрия развивается, задачи формализуются, приоритеты расставляются... Вспомните операционные системы 70-х, 80-х годов... убожество, с которым пытались справится с помощью навороченных языков. А проблема-то была в другом! В ублюдочных runtime и платформе ...

А>Наглядный пример Java и VB — полные ничтожества в языковом плане, никаких понят... тьфу возможностей,

А>однако ведь лидеры промышленной разработки.

Дык, они могут себе позволить быть ублюдочными... т.к. базируются на мощных платформах. Можно пойти дальше — я встречал проекты (как правило учет), в которых были реализованны системы метаданных (считай расширенная платформа). На абсолютно ублюдочном xml писались системы учета огромных складов, отделов кадров и т.д.

А>Где все разработки 70-х, 80-х годов — вычисляемые типы, контракты, пред- и постусловия, частично параметризованные функции,

А>лямбды, замыкания и т.д.?

И зачем это все? Жалкие попытки проэмулировать возможности COM...

А>Если же кого-то интересуют навороченные языковые возможности, то есть тот же CLOS, Smalltalk, SML, Haskell

А>(последний вроде как уже есть под .NET — H#).

Какие концептуальные задачи вы будете решать этими инструментами?

Игорь
Re[4]: Статья про развитие идей ООП. Жду комментариев.
От: Voblin Россия http://maslyaew.narod.ru/
Дата: 08.05.03 13:28
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Будет ли пользоваться успехом язык, в котором есть только одна фича (по сравнения, скажем с C#),

А>но зато полно недостатков — нет такой мощной поддержки, кучи библиотек (стандартных и сторонних),
А>серьезного компилятора и средства разработки, поддержки средств моделирования (например от Rational)
А>и т.п. и т.д. Можно продолжать бесконечно...
Стоп-стоп-стоп. Речь идёт не только и не столько о том, что неплохо было бы выдумать новый язык программирования и среду разработки к нему. Конечно, хочется слепить что-то по-быстрому для опытов, но создавать какой-то сверхмощный коробочный продукт и двигать его на роль индустриального стандарта... Об этом речь пока что не идёт.

Вопрос в том, имеет ли право на жизнь подход, основанный не на однозначной, а на множественной классификации, когда:


А>Сейчас наоборот наблюдается деградация языков программирования к более простым вариантам

А>(видимо программист пошел совсем недалекий).
Предложенная парадигма не проще и не сложнее обычного ООП. Она просто другая.
Re[5]: Статья про развитие идей ООП. Жду комментариев.
От: Voblin Россия http://maslyaew.narod.ru/
Дата: 08.05.03 13:30
Оценка:
Здравствуйте, joker6413, Вы писали:

А>Сейчас наоборот наблюдается деградация языков программирования к более простым вариантам

А>(видимо программист пошел совсем недалекий).

J>А по моему все логично. Индустрия развивается, задачи формализуются, приоритеты расставляются... Вспомните операционные системы 70-х, 80-х годов... убожество, с которым пытались справится с помощью навороченных языков. А проблема-то была в другом! В ублюдочных runtime и платформе ...


Давайте не будем разводить спор о том, какое средство разработки лучше. Это бессмысленно.
Re[6]: Статья про развитие идей ООП. Жду комментариев.
От: joker6413  
Дата: 08.05.03 13:52
Оценка:
Здравствуйте, Voblin, Вы писали:

V>Давайте не будем разводить спор о том, какое средство разработки лучше. Это бессмысленно.


Да я вобщем-то и не собирался... хороший — плохой, главное кто живой, а кто мертвый .

Игорь
Re[5]: Статья про развитие идей ООП. Жду комментариев.
От: joker6413  
Дата: 08.05.03 14:03
Оценка:
Здравствуйте, Voblin, Вы писали:

V>Стоп-стоп-стоп. Речь идёт не только и не столько о том, что неплохо было бы выдумать новый язык программирования и среду разработки к нему. Конечно, хочется слепить что-то по-быстрому для опытов, но создавать какой-то сверхмощный коробочный продукт и двигать его на роль индустриального стандарта... Об этом речь пока что не идёт.


Да я и не собирался затевать гнилой базар по поводу — "да зачем все это надо я ж на turbo pascal и так фсе напишу"...

V>Вопрос в том, имеет ли право на жизнь подход, основанный не на однозначной, а на множественной классификации, когда:


Вот только я так и не понял сути — судя по картинке мы отказываемся от одиночного наследования в пользу множественного, плодим singletonы и вуаля — все по новому? В чем новизна?

Игорь
Re[6]: Ну при чём здесь singleton?
От: Voblin Россия http://maslyaew.narod.ru/
Дата: 08.05.03 14:48
Оценка: 9 (1)
Здравствуйте, joker6413, Вы писали:

J>Вот только я так и не понял сути — судя по картинке мы отказываемся от одиночного наследования в пользу множественного, плодим singletonы и вуаля — все по новому? В чем новизна?


Если под этим понятием скрывается паттерн проектирования "Одиночка".

Новизна — в сознательном отказе от концепции наследования и в том, что при этом мы получаем даже бОльшую возможность обобщения, бОльшую гибкость в плане полиморфизма, начинаем говорить с реляционными БД на одном языке, значительно улучшается расширяемость систем, отпадает необходимость всяких уродств типа абстрактных классов и темплэйтов и, в конце концов, можем делать объектную модель похожей на реальное положение вещей

Просьба: не надо меня размазывать по стенке за нелюбовь к темплэйтам. Я знаю что это такое и умею применять, но каждый раз после того, как такое случается, с чувством омерзения иду мыть руки. А потом иду смотреть, не добавила ли моя невинная шалось к размеру exeшника лишних килобайт 100
Re: Статья про развитие идей ООП. Жду комментариев.
От: Akzhan Россия http://www.akzhan.midi.ru/devcorner/
Дата: 08.05.03 16:07
Оценка:
Здравствуйте, Voblin, Вы писали:

V>Может быть, кому-нибудь будет интересно.

V>http://voblin.nm.ru/objects_classes.dhtml
V>Сразу вопрос: стоит ли это опубликовать в RSDN?

Недостаток данного подхода именно в черзвычайной гибкости. Очевидно, это приведёт в строгому и сложному механизму органичения/разрешения/последовательности наследования.

Достаточно хорошим подходом является так называемый Class mixing. Объявляются так называемые классы-примеси, которые соответствуют строго определённым контрактам. И результирующие классы строятся с использованием классов-примесей, дающих необходимый вкус (flavour).

Типичная mixing library, на мой взгляд, это ATL/WTL.
С уважением,
Акжан, http://www.akzhan.midi.ru/devcorner/ — мой уголок разработчика
Re[2]: Статья про развитие идей ООП. Жду комментариев.
От: Voblin Россия http://maslyaew.narod.ru/
Дата: 08.05.03 17:05
Оценка:
Здравствуйте, Akzhan, Вы писали:

A>Недостаток данного подхода именно в черзвычайной гибкости. Очевидно, это приведёт в строгому и сложному механизму органичения/разрешения/последовательности наследования.

Конечно, если не предпринимать каких-то очень специальных действий, ничто не помешает создавать объекты самых бессмысленных сочетаний. Ну да, можно создать помесь кошки и собаки. Ну да, по команде "Голос" оно гавкнет и мяукнет...

Думаю, в сочетании со строгой типизацией катастроф не будет. Ведь в любом же языке программирования есть возможность написать что-то вроде "а = 1/0".

A>Достаточно хорошим подходом является так называемый Class mixing. Объявляются так называемые классы-примеси, которые соответствуют строго определённым контрактам. И результирующие классы строятся с использованием классов-примесей, дающих необходимый вкус (flavour).


A>Типичная mixing library, на мой взгляд, это ATL/WTL.


Где можно прочитать про Class mixing?
Yandex и Google вываливают кучу мусора
Re[3]: Статья про развитие идей ООП. Жду комментариев.
От: swinger  
Дата: 08.05.03 17:20
Оценка:
Здравствуйте, Voblin, Вы писали:

V>Где можно прочитать про Class mixing?

V>Yandex и Google вываливают кучу мусора

Александреску, Буч. Ключевое слово — "стратегия".
Re: Статья про развитие идей ООП. Жду комментариев.
От: Boris Гондурас  
Дата: 08.05.03 22:10
Оценка:
Здравствуйте, Voblin, Вы писали:

Я тут на досуге средствами C# и с системным подходом пытался моделировать структуры простейших геологических систем. Теперь есть ощущение, что средствами ООП сделать это (по крайней мере логично) нереально.
Ваши идеи выглядят очень привлекательно. Очень заинтересован в их развитии.
Конкретных комментариев, к сожалению, пока дать не могу, т.к. нет еще оформившихся мысел.

Удачи
... << RSDN@Home 1.0 beta 6a >>
Re[3]: Статья про развитие идей ООП. Жду комментариев.
От: Akzhan Россия http://www.akzhan.midi.ru/devcorner/
Дата: 09.05.03 10:36
Оценка: 6 (1)
Здравствуйте, Voblin, Вы писали:

A>Типичная mixing library, на мой взгляд, это ATL/WTL.

V>Где можно прочитать про Class mixing?

смотрите тему Mixin-Based Programming in C++ и тому подобные.

например, http://c2.com/cgi/wiki?MixIn
http://www.ddj.com/documents/ddj0101i/
http://citeseer.nj.nec.com/bracha90mixinbased.html
С уважением,
Акжан, http://www.akzhan.midi.ru/devcorner/ — мой уголок разработчика
Re[4]: Mixins - вариант множественного наследования?
От: Voblin Россия http://maslyaew.narod.ru/
Дата: 10.05.03 15:06
Оценка:
Здравствуйте, Akzhan, swinger

Насколько я понял из Ваших ссылок, механизм примесей по своей сути является вариантом множественного наследования и применяется там, где "лобовое" множественное наследование либо не поддерживается языком либо его не хочется применять.

То, что предлагаю я, вообще обходися без наследования. То есть в самом прямом смысле — мы можем обойтись безо всякой иерархии классов. Составление "коктейля", содержащего все необходимые "примеси" происходит по мере необходимости.

В простейшем случае объект может являться смесью, составленной из любого произвольного сочетания объявленных в программе классов.

В более сложном случае (для этого нужно приложить соответствующее усилие при программировании) мы можем наложить условие, что, например, объект может быть либо Male, либо Female, а и тем и другим одновременно быть не может. Да простят меня представители сексуальных меньшинств

Насколько я понял, ни в одном из существующих языков программирования нет возможности породить экземпляр более чем двух классов. Например, вот так:

 ' VB
 Dim MyObj As (Person, Male)


 // C++
 (Person, Male) *MyObj;


То, что описано в статье, мало того что позволяет так делать (подумаешь, ещё одна спорная "фича", к тому же потенциально весьма опасная), но и основывает на этом механизме технологию проведения безусловно самой главной фазы OOD — описание задачи в виде системы классов.
Re[5]: Mixins - вариант множественного наследования?
От: Akzhan Россия http://www.akzhan.midi.ru/devcorner/
Дата: 10.05.03 15:51
Оценка: 9 (1)
Здравствуйте, Voblin, Вы писали:

V>
V> ' VB
V> Dim MyObj As (Person, Male)
V>


В варианте mixin architecture это выглядит так же, но более строго. Поэтому все возможные ошибки ловятся ещё на этапе компиляции. Единственное разлчие — невозможность динамического изменения типа — мутации. Другое дело, что я считаю мутации объектов вредной техникой с точки зрения поддержки кода. Но если нужны мутации, то надо использовать паттерн объект-стратегия.

class CMyObject : 
  public CCompoundObject, CPersonT<CMyObject>, CMaleT<CMyObject>
{
};

CMyObject myObj;
С уважением,
Акжан, http://www.akzhan.midi.ru/devcorner/ — мой уголок разработчика
Re[5]: Mixins - вариант множественного наследования?
От: Kluev  
Дата: 11.05.03 08:11
Оценка: 41 (4) +1
Здравствуйте, Voblin, Вы писали:

V>То, что предлагаю я, вообще обходися без наследования. То есть в самом прямом смысле — мы можем обойтись безо всякой иерархии классов. Составление "коктейля", содержащего все необходимые "примеси" происходит по мере необходимости.


V>В простейшем случае объект может являться смесью, составленной из любого произвольного сочетания объявленных в программе классов.


V>В более сложном случае (для этого нужно приложить соответствующее усилие при программировании) мы можем наложить условие, что, например, объект может быть либо Male, либо Female, а и тем и другим одновременно быть не может. Да простят меня представители сексуальных меньшинств


V>Насколько я понял, ни в одном из существующих языков программирования нет возможности породить экземпляр более чем двух классов. Например, вот так:


V>
V> ' VB
V> Dim MyObj As (Person, Male)
V>


V>
V> // C++
V> (Person, Male) *MyObj;
V>


Почему же нет возможности? Немного смекалки и все будет

typedef const char cchar_t;

// примесь обьекта
template <class I, class T>
struct Part : I {
    T& self() { return *static_cast<T*>(this); }
};

// Абстрактный фрукт
struct IFruit {
    cchar_t* kind() { return _IFruit_kind(); }
protected:
    virtual cchar_t* _IFruit_kind() = 0;
};

// Абстрактный цветной обьект
struct IColored {
    cchar_t* color_get() { return _IColored_color_get(); }
    void color_set( cchar_t *color ) { _IColored_color_set( color ); }
protected:
    virtual cchar_t* _IColored_color_get() = 0;
    virtual void _IColored_color_set( cchar_t* ) = 0;
};

// цветной фрукт (подразумевается наличие в классе IColored и IFruit)
struct IColoredFruit {
    cchar_t* name() { return _IColoredFruit_name(); }
protected:
    virtual cchar_t* _IColoredFruit_name() = 0;
};

// яблоко
template <class T>
class Apple : public Part<IFruit,T> {
    cchar_t* _IFruit_kind() { return "apple"; }
};

// манго
template <class T>
class Mango : public Part<IFruit,T> {
    cchar_t* _IFruit_kind() { return "mango"; }
};

// абстрактный цветной обьект. реализация
template <class T>
class Colored : public Part<IColored,T> {
    std::string    _m_color;

    cchar_t* _IColored_color_get() { return _m_color.c_str(); }
    void _IColored_color_set( cchar_t *color ) { _m_color = color; }
};

// цветной фрукт
template <class T>
class ColoredFruit : public Part<IColoredFruit,T> {
    cchar_t* _IColoredFruit_name() {
        static char buf[80];
        sprintf( buf, "%s %s", self().IColored::color_get(), self().IFruit::kind() );
        return buf;

    }
};

// а теперь будем химичить
struct MyApple :
    Apple<MyApple>,
    Colored<MyApple>,
    ColoredFruit<MyApple>
{
};

struct MyMango :
    Mango<MyMango>,
    Colored<MyMango>,
    ColoredFruit<MyMango>
{
};

void test() {
    MyApple a;
    MyMango m;

    a.color_set( "green" );
    m.color_set( "red" );

    cchar_t *a_name = a.name(); // green apple
    cchar_t *m_name = m.name(); // red mango
}


Как видите интерфейсы IFruit, IColored, IColoredFruit не связаны узами наследования однако все работает
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.