Шаблоны и ООП

← →
euru (2003-06-20 12:03) [0]

Предлагаю обсудить две, на мой взгляд, связанные темы:

1. Нужны ли в языках программирования (в частности, в Delphi) шаблоны, подобные С++?
2. Методология, используемая в ООП, для описания какой-либо модели действительно ли наиболее корректно описывает эту модель?

Пару лет назад я бы на этьи вопросы ответил более-менее утвердительно. Но в последнее время я стал сомневаться.

Возможно, вопросы заданы не совсем корректно. Если это окажется так, я постараюсь их уточнить.

← →
Dimka Maslov (2003-06-20 12:38) [1]

1. В Delphi шаблоны не нужны, поскольку проблемы, решаемые в C++ при помощи шаблонов, легко можно обойти при помощи метаклассов. Если человеку лень набрать несколько строк кода - тогда уж извините.

2. Любое описание модели имеет определённый уровень абстракции. А ООП или СОП лишь способ описания. Корректность описания зависит от человека, который занимается моделированием. ООП позволяет лишь упрастить до некоторого предела описание отдельных моделей. Существует класс задач, в которых ООП будет только помехой.

← →
Mystic (2003-06-20 12:39) [2]

1. Шаблоны хороши в хорошо отлаженых спроектированных библиотеках (вроде STL). Зачастую же использование их в обычном проекте затрудняет понимание кода, привносит ошибки (из-за сложности отладки, ...), посему использовать их надо крайне осторожно (имхо).

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

← →
euru (2003-06-20 14:28) [3]

>Dimka Maslov
>1. В Delphi шаблоны не нужны, поскольку проблемы, решаемые в C++ >при помощи шаблонов, легко можно обойти при помощи метаклассов.

Какие такие метаклассы в Delphi?

>2. ...Корректность описания зависит от человека, который >занимается моделированием. ...

А ведь этот человек для моделирования использует некоторый подход. Раньше был структурный подход, теперь ориентированный на объекты и события. Лично я считаю ОО подход наиболее подходящим, но у меня вызывает сомнение вариант ООП, предлагаемый теорией (Буч и т.д.) и и ее реализацией (Delphi, C++ и т.д.)

>Mystic
>1. Шаблоны хороши в хорошо отлаженых спроектированных >библиотеках (вроде STL). ...

Если их использование затрудняет понимание кода и пользоваться ими надо осторожно, то, может быть, надо применить какой-то другой механизм, реализующий все преимущества шаблонов и минимизирующий их недостатки.

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

Под "наиболее корректным" я подразумевал не математическую корректность.

На этом форуме Кен примерно похожее спрашивал:
http://delphimaster.net/view/14-1056075783/

По-моему, ни про дом, ни про бабочку так и не дали удовлетворительного ответа. А ведь вроде бы пытались спроектировать по правилам. Может что-то не совсем так в этих правилах?

← →
uw (2003-06-20 14:34) [4]

>euru © (20.06.03 14:28)
>но у меня вызывает сомнение вариант ООП, предлагаемый теорией (Буч и т.д.) и и ее реализацией

Да уж. Интересно, кто-нибудь мз присутствующих проектировал систему с помощью UDL?

← →
euru (2003-06-20 14:58) [5]

>uw © (20.06.03 14:34)
>Да уж. Интересно, кто-нибудь мз присутствующих проектировал систему с помощью UDL?

А при чем здесь это? Такой вопрос похож, как если бы лет 10-15 назад сомневающихся в структурном подходе и предлагающих взглянуть на решение с другой точки зрения (используя ОО проектирование - ООП) спросили, пользовались ли они блок-схемами.

Я не же не утверждаю, что ООП некорректно. И люди, умеющие использовать UML, наверняка (при прочих равных условиях) работают гораздо эффективнее тех, кто не умеет (это впрочем верно и для блок-схем, и для других подходов).

← →
euru (2003-06-20 15:30) [6]

Неужели эта тема никого не заинтересовала?

← →
PVOzerski (2003-06-20 15:39) [7]

Во-первых, шаблоны при их полноценнй реализации потребуют мощного препроцессора, что тормознет скорость компиляции. Заодно и организацию DCU-модулей усложнит. Во-вторых, метаклассами, я так понимаю, Dimka Maslov навал такие конструкции: type еMyMetaClass=class of tMyObject; В третьих, с помощью некоторой игры с include-файлами в Delphi все-таки удается использовать нечто вроде шаблонов (был материал на "Королевстве Delphi").

← →
Mike B. (2003-06-20 15:45) [8]

Я все-таки не понял, что значит "наиболее корректно".
А что касается ООП, то как мне кажется, первоначальной целью его создания было не моделирование чего-либо, а улучшение процесса разработки больших программных систем. Так что вопрос наверное, не совсем корректен. И связь между первым и вторым вопросом, тоже что-то не очень просматривается.

← →
Dimka Maslov (2003-06-20 16:17) [9]

>PVOzerski
Это не я, так сказано в Helpe:

A class-reference type, sometimes called a metaclass, is denoted by a construction of the form...

← →
euru (2003-06-20 16:27) [10]

>PVOzerski © (20.06.03 15:39)

Про шаблоны меня интересует их принципиальная необходимость (или ненужность) в любых языках, а не как они будут влиять на компиляцию, организацию модулей и т.д.

Пример. Функция, возвращающая абсолютное значение любого числового типа, в том числе и такого, который не предусмотрен языком (комплексные числа). Какие теоретические варианты (т.е. не пользуясь особенностями конкретного языка) можно предложить кроме шаблонов и перезагрузки функции.

И как здесь могу помочь эти метаклассы?

>Mike B. © (20.06.03 15:45)

Целью чего-то нового всегда (или в большинстве случаев) является улучшение чего-то старого. А для этого создается определенная методика. Например, придерживаясь этой методики попытались ответить на поставленные Кеном (см. выше) вопросы. И как-то не получилось. Почему?

А связь, мне кажется, есть. Все началось со второго вопроса. По мере ответа на него появился первый вопрос.

Для себя я на эти вопросы уже ответил. Но, как говорится, одна голова хорошо, а много лучше. Я ведь мог где-то и ошибиться в своих рассуждениях. Поэтому мне бы хотелось и обсудить их с вами.

. Методология, используемая в ООП, для описания какой-либо модели действительно ли наиболее корректно описывает эту модель?

← →
uw (2003-06-20 16:30) [11]

>euru © (20.06.03 14:58)

Я спросил, пользуется ли кто-то UML, а ты мне разясняешь, что такое ООП.

← →
euru (2003-06-20 16:39) [12]

>uw © (20.06.03 16:30)

Ну извини. Не понял я тебя. Мне на практике применять не приходилось.

← →
uw (2003-06-20 16:44) [13]

Кстати, я тоже промахнулся и написал не UML, а UDL.

← →
reonid (2003-06-20 16:53) [14]

ИМХО, эти темы как раз никак не связаны.

Шаблоны - это обобщённое (generic) программирование.
Концепция, перпендикулярная ООП и
с описанием моделей не имеющая ничего общего.

Её основная её задача - абстрагировать алгоритм от типов данных.
Для ООП же алгоритм всегда остаётся "за кадром", деталью реализации.

Для ООП важен вопрос - что (объект делает), неважно, как.
Для обобщённого программирования - как, неважно, что.

Таково моё скромное мнение.

← →
euru (2003-06-20 17:26) [15]

>reonid © (20.06.03 16:53)

И шаблоны, и ООП работают с абстрактными типами данных, только рассматривают их по-разному.

Шаблоны подходят к этим типам с процедурной точки зрения. Возьмем функцию Abs. С помощью шаблонов она будет реализована так:
template <T>; function Abs(Value: <T>): <T>; begin // Реализация функции end; var i: Integer; f: Double; begin i := Abs(i); // <T> - Integer f := Abs(f); // <T> - Double f := Abs(i); // <T> - Double (приведение типов) i := Abs(f); // <T> - Integer или exception end;

А вот если бы элементарные типы данных рассматривались как объекты, то шаблоны не нужны:
// Общий класс всех элементарных типов Generic = class end; // Общий класс всех числовых типов Numeric = class(Generic) end; // Класс целочисленный типов Integer = class(Numeric) end; // Класс типов чисел с плавающей запятой Double = class(Numeric) end; function Abs(Value: Numeric): Numeric; begin ebd; var i: Integer; f: Double; begin i := Abs(i); // <T> - Integer f := Abs(f); // <T> - Double f := Abs(i); // <T> - Double (приведение типов) i := Abs(f); // <T> - Integer или exception end;

Шаблоны не используются. Т.е. грубо говоря, шаблоны - это подмножество объектов.

Вроде бы и связь указал.

← →
Mike B. (2003-06-20 17:55) [16]

>euru © (20.06.03 16:27)
На вопросы поставленые Кеном, ответить в рамках ООП и не получится, потому что он сам должен здесь выбрать что для него важно - тот факт что дом строится из кирпичей, или тот, что он сосотит из стен, фундамента и т.д., а уже стены в свою очередь из кирпичей, раствора и т.д., т.е. сначала он должен построить некую концептуальную модель в голове, с той степенью детализации, с которой это необходимо, а уж потом отобразить это дело на структуру классов, что опять-таки можно сделать по разному. ООП как метод тут вобщем то и ни причем.
ООП это методология программирования, а не моделирования, вот в чем по-моему изъян в ваших рассуждениях

← →
Mike B. (2003-06-20 18:07) [17]

Хотя конечно, любую программу можно рассматривать как модель каког-либо реального или идеального процесса, но тогда, наверное тоже вопрос должен по другому ставиться

← →
Кен (2003-06-21 06:47) [18]

> Mike B. © (20.06.03 17:55)
> >euru © (20.06.03 16:27)
> На вопросы поставленые Кеном, ответить в рамках ООП и не
> получится, потому что он сам должен здесь выбрать что для
> него важно - тот факт что дом строится из кирпичей, или
> тот, что он сосотит из стен, фундамента и т.д., а уже стены
> в свою очередь из кирпичей, раствора и т.д., т.е. сначала
> он должен построить некую концептуальную модель в голове,
> с той степенью детализации, с которой это необходимо, а
> уж потом отобразить это дело на структуру классов, что опять-таки
> можно сделать по разному. ООП как метод тут вобщем то и
> ни причем.
> ООП это методология программирования, а не моделирования,
> вот в чем по-моему изъян в ваших рассуждениях
А если допустим я как Даль ? Словарь пишу. И должен описать все возможные варианты. Вопрос в том, как сделать так, чтобы к одному и тому же предмету вели все возможные пути.
И Дом.Кирпич и Дом.Стена.Кирпич .

Да ещё плюс, чтобы к самому предмету можно было обращаться по всем возможным названиям. Кирпич, brick, какие-нибудь слэнговые названия и т. д.

Думаю решение может быть таким. Но может кто предложит и другие варианты ?

← →
Mike B. (2003-06-21 10:03) [19]

> Кен © (21.06.03 06:47)
Тогда сначала придумай модель содержащую "все возможные пути". Придумаешь сообщи.

← →
euru (2003-06-21 10:28) [20]

>Mike B. © (20.06.03 17:55)
Под понятием ООП я подразумевал объектно-ориентированное проектирование, а не программирование. Реализация всех ОО языки (из тех, которые я знаю) наиболее близка концепции, выраженной Бучем и Со.

>На вопросы поставленые Кеном, ответить в рамках ООП и не получится...

А если выйти за рамки, то можно ответить? Если теория не может дать конкретного ответа, может быть в ней есть какой-то изъян?

← →
Mike B. (2003-06-21 11:14) [21]

> euru © (21.06.03 10:28)
Любая теория имеет свои ограничения, как и любая модель в рамках этой теории. Если хорошенько подумать, то окажется что иерархия объетов это не единственный и не самый верхний уровень абстракции при проектировании программной системы, и требовать от нее стопроцентно адекватного отображения объектов реального мира смысла нет. Это в лучшем случае модель модели реального мира, той которая существует у тебя в голове, на бумаге в том или ином виде и т.д.

← →
euru (2003-06-21 11:49) [22]

>Mike B. © (21.06.03 11:14)
Я попробую интерпретировать твой ответ, применив его к какой-нибудь другой области.
Например, физика. Конец XIX века. Исходя из постулатов классической физики получается, что наша Вселенная уже давно должна была умереть "тепловой смерью". И вот сидят физики и рассуждают, что любая теория ограниченна и все равно не получится адекватно отобразить теоретическую модель природы на реальные объекты и процессы этой природы, так что чего мучаться - живы и ладно... Но ведь они же не остановились, они модифицировали классическую теорию, чтобы их модель более корректно отображала реальный мир. Наверняка эта теория также имеет свои ограничения, и со временем и ее будут модифицировать, чтобы учесть новые условия.

Так может и в нашей области нужно сделать кое-какие модификации, чтобы можно было как можно более адекватнее описывать реальные объекты и процессы?

← →
Mike B. (2003-06-21 11:59) [23]

> euru © (21.06.03 11:49)
В примере с физикой уже речь идет не об адекватности, а о частичной некорректности модели, которая и была исправлена (до поры до времени пока не вылезет следующий глюк). Но при этом заметь, средства создания этих моделей (математика, эксперимент) принципиального изменения не претерпели. ООП - средство, программа - модель, как ты эту модель построишь зависит от тебя

← →
euru (2003-06-21 12:18) [24]

>Mike B. © (21.06.03 11:59)
1. В математике такая же ситуация была с представлением комплексных чисел. Кстати, их введение в физике все-таки отразилось, так как стало проще манипулировать с некоторыми моделями.

2. ООП - не совсем средство, это модель, как нужно проектировать модели, основанная на нашем представлении, как это должно выглядеть. Естественно, если выбрать какую-то конкретную модель ООП, то ее можно рассматривать в качестве средства, и на основании которой строить модели.

← →
Mike B. (2003-06-21 12:23) [25]

> euru © (21.06.03 12:18)
1. Поподробнее ,я не в курсе.
2. По-моему ты сам себя запутал. Я тогда так скажу: для решения твоих задач с бабочками в сущности все равно, используешь ты ООП, структурное программирование или выдумал что-то свое, главное, чтобы полученная модель вела себя в соответсвии с твоими представлениями об адекватности.

← →
euru (2003-06-21 13:49) [26]

Mike B. © (21.06.03 12:23)
1. Поподробнее про историю комплексных чмсел или про их использование в физике?

2. Возможно, я и запутался (хотя пока не вижу где). Просто на этой ветке я пытаюсь выяснить, какой должна быть модель проектирования, чтобы она наиболее адекватно отражала моделируемый объект. Причем чтобы моделирование было как можно более однозначно, а не приводило к мучительным размышлением, какой вариант мне выбрать, чтобы избежать как можно больше последствий. А на той ветке я пытаюсь подойти снизу к той же теме: у меня есть определенные объекты и отношения между ними и внутри них, какой тогда должна быть модель, чтобы она наиболее адекватно описывала эти объекты

← →
Mike B. (2003-06-21 13:59) [27]

> euru © (21.06.03 13:49)
1. Про представление комплексных чисел, хотя это не по теме, можно и не писать
2. Мне кажется, что ты вместо того чтобы, попытаться построить модель, описывающую объект, хочешь добиться того, чтобы она была полностью подобна объекту, т.е. вместо того чтобы моделировать бабочку, ты хочешь написать объект, который в некотором смысле сам будет бабочкой :), что в общем то ни к чему.
Про ООП - это скорее модель программной системы, которая в свою очередь, может моделировать реальный объект, а может и не моделировать. Так что говорить об адекватност издесь можно только применительно к процессу разработки програмного обеспечения, а не моделированию чего-либо

← →
euru (2003-06-21 14:33) [28]

>Mike B. © (21.06.03 13:59)
Я не о моделях говорю, я о методах построения объектов.
Пример. Пытаясь найти что-нибудь по этой теме, я наткнулся на сайт, где были слайды, как правильно проектировать объекты. Вот одна из задач. Есть птицы, они умеют летать. Тогда класс, описвающий птиц, будет выглядеть так:
TBird = class procedure fly(); end;
Но пингвины летать не умеют. Поэтому, говорят нам, здесь ошибка, и предлагают другой вариант:
TUnflyingBird = class end; TPinguin = class(TUnflyingBird) end; TBird = class(TUnflyingBird) procedure fly(); end;
Пока вопрос касается летабельности, все нормально. Но через некоторое время захотят расширить эту модель, добавив водоплавательность, потм хищность и т.д. А эти свойства у разных видов птиц могут комбинироваться по-разному. И что теперь делать с этой моделью? Получается опять неправильно (некорректно) спроектировали модель.

Пример из области программирования. Библиотеки VCL, OWL, MFC, Forms в .NET. По-моему какие-то они не такие - гибкости в них маловато.

← →
Mike B. (2003-06-21 14:47) [29]

Я на прошлой неделе уже давал эту ссылку, возможно тебе будет интересно почитать
http://voblin.nm.ru/objects_classes.dhtml
Утверждение птицы умеют летать в отношении птиц вообще неверно(пример пингвины, страусы) поэтому получается, что "летабельность" должна добавляться ниже по иерархии классов примерно так
TBird
ТFlyingBird= class(TBird) - здесь будет "летабельность"
TUnFlyingBird= class(TBird) - здесь нет

← →
Mike B. (2003-06-21 15:01) [30]

> Но через некоторое время захотят расширить эту модель, добавив водоплавательность, потм хищность и т.д. А эти свойства у разных видов птиц могут комбинироваться по-разному. И что теперь делать с этой моделью? Получается опять неправильно (некорректно) спроектировали модель.

А тут сделай абстрактный класс - а в дочерних публикуй свойства какие надо, какие не надо оставляй скрытыми, примерно так.

← →
euru (2003-06-21 16:06) [31]

Классная статья! Это именно то, что я хотел сказать. На 80% она совпадает с моим представлением о проектировании объектов, а с 20% надо еще разобраться - скорее всего я чего-то недопонял.

Где-то в феврале этого года я уже кидал программку, посвященную этой тематике, и обсуждения пытался устроить, но меня не поняли (сам виноват).
Вот ссылка на эту программу:
http://www.delphimaster.ru/cgi-bin/download.pl?get=1044520123&n=2

Сейчас я пытаюсь написать другую версию ее же (применил несколько другой подход). Сейчас немного подчищу ее и тоже выложу.

Кстати, используя подход в статье, проще смоделировать Гусеницу-Бабочку.

← →
euru (2003-06-21 16:38) [32]

Выложил:
http://www.delphimaster.ru/cgi-bin/download.pl?get=1056198989&n=2

← →
Кен (2003-06-22 06:35) [33]

Насчёт птиц.

А ведь в жизни мы определяем птицу не по одному какому то свойству, а по их совокупности.
Например птицы могут, летать, иметь крылья, класть яйца, плавать. и т. д.
Если наш объект имеет 80% этих свойства, то он TПтица.
Тут есть вероятность ошибки. Но так и человек может ошибиться. И назвать какую-нибудь летучую рыбу, или летучую мышь птицей.

Но у человека есть ещё обработчик ошибки (конструктор), который может список свойств дополнять всё новыми и новыми. Ошиблись с пингвином - запоминаем : живёт в Антарктиде+имеет перья=ТПтица.
Ошиблись со страусом - запоминаем ещё ...
И т. д.

А зачем вообще нужно обзывать объект ТПтица или как то ещё ?
А затем, что определив объект как ТПтица, мы сможем предполагать у него наличие других свойств свойственных ТПтице.

← →
reonid (2003-06-22 15:48) [34]

Что-то это мне напоминает спор реалистов с номиналистами.

В окружающем нас мире нет никаких моделей.
Есть, назовём их так, сущности реального мира.

Когда нам надо что-то с этими сущностями сделать –
т.е. перед нами стоит некоторая задача,
мы изучаем сущность, определяем, какие её характеристики
существенны для данной задачи, а какие – нет.
Это и есть, грубо говоря, построение модели.
Модель всегда подразумевает наличие задачи, цели.
То, что обсуждаете вы – как сделать описание сущности,
универсальное для всех задач. Это невозможно. В принципе.

Потом, сущности реального мира часто могут
выступать в качестве, которые изначально не было им присуще.
Например, тот же кирпич может выступить
в качестве оружия. А затем в качестве вещдока. Это ведь не значит, что каждому объекту «кирпич»
необходим в качестве атрибута номер уголовного дела.

← →
Кен (2003-06-23 05:47) [35]

> Потом, сущности реального мира часто могут
> выступать в качестве, которые изначально не было им присуще.
>
> Например, тот же кирпич может выступить
> в качестве оружия. А затем в качестве вещдока. Это ведь
> не значит, что каждому объекту «кирпич»
> необходим в качестве атрибута номер уголовного дела.
Для ТОружие в числе прочих определений есть и такое как тупой, тяжёлый предмет.
У кирпича свойства тупости и тяжести выставлены в True;, значит он однозначно является наследником от TOружие.

Далее, поскольку мы теперь знаем, что ТОружие.Кирпич , то мы можем сказать, что кирпичём можно проделать все те действия, которые можно проделать с помощью ТОружия. Убить, нанести тяжкие телестные повреждения, лёгкие телестные повреждения, угрожать и т. д.

← →
euru (2003-06-23 10:40) [36]

>reonid © (22.06.03 15:48)
>То, что обсуждаете вы – как сделать описание сущности, >универсальное для всех задач. Это невозможно. В принципе.

Создать универсальное для всех задач описание сущности действительно невозможно. Да и не нужно это. Более того, не нужно это делать и внутри какой-то отдельной задачи. Но нужна возможность, позволяющая модифицировать либо описание сущности (тогда у всех сущностей, созданных на основе этого описания, появятся новые свойства), либо саму сущность (тогда только у этой сущности появятся новые свойства).

Примеры. Возьмем иерархию классов в VCL.
1. Допустим, у нас есть работающая программа. Вся визуальная часть ее построена на стандартных компонентах. Через год поменялись требования этой визуальной части - нужно, чтобы все кнопки меняли цвет, когда над ними находится курсор мыши. Стандартный класс TButton никак визуально не реагирует на такую ситуацию. Лучшим решением, по-моему, было бы, если бы можно было это сделать на уровне класса TButton. Какие возражения?
2. У класса TEdit есть свойство PasswordChar. Но ведь это свойство не присуще всем полям ввода. Оно нужно только в определенном месте программы. Зачем же его привязывать ко всем полям ввода? Или свойства Dock и Drag - тоже ведь не часто используются.

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

← →
euru (2003-06-24 10:12) [37]

Вот еще одна ссылка:
http://www.alexus.ru/russian/articles.htm

← →
Игорь Шевченко (2003-06-24 10:48) [38]

← →
Anatoly Podgoretsky (2003-06-24 11:00) [39]

← →
euru (2003-06-24 12:07) [40]

>Игорь Шевченко © (24.06.03 10:48)
Почему?

>Anatoly Podgoretsky © (24.06.03 11:00)
А если еще нужен будет, к примеру, такой объект как кирпич для забивания гвоздей? Тогда по аналогии создадим класс:
ТКирпичДляГвоздей = class(ТКирпич)
А потом окажется, что его можно применить в качестве оружия. От какого тогда класса наследовать?
ТОружейныйКирпичДляГвоздей = class(ТКирпич)
или
ТОружейныйКирпичДляГвоздей = class(ТОружейныйКирпич)
или
ТОружейныйКирпичДляГвоздей = class(ТКирпичДляГвоздей)
А потом добавится еще какое-нибудь свойство.

Пример тому в VCL. Как сделать так, чтобы все визуальные компоненты реагировали, когда над ними находится курсор мыши?

Шаблоны и ООП Найти похожие ветки