Есть класс А, у которого имеются потомки класс В и класс C.
Есть также класс D, одна из операций которого выглядит так

то есть класс D должен работать с наследниками класса A.
Теперь пишу такой код

Компилятор ругается на последнюю строчку



как мне научить класс D работать с разными потомками класса А?

Это сообщение отредактировал(а) Нитонисе - 2.11.2010, 19:20

дело в том, что B и C являются А, но А не является ни B, ни C (Ту134 - самолет, но самолет - не обязательно Ту134)
в чем полиморфизм? в том, что принимая аргументом A* и вызывая виртуальную функцию, будут работать методы B или C, в зависимости от типа.

так:

baldina,  так получается что работает метод, реализованный в классах В и С. Это не совсем то, что мне нужно. Мне нужно чтобы работал метод, реализованный в D.

Добавлено @ 19:45
То есть изначально метод класса D не знает какой именно потомок класса А будет его аргументом. Действует позднее связывание, тип аргумента определяется по факту переданного в метод указателя.

Это сообщение отредактировал(а) Нитонисе - 2.11.2010, 19:46

Класс D вообще никак не участвует в наследовании, поэтому требование просто не корректное.



Пример который тебе показали, на 100% соответствует этому

Пример-то верный, только он немного не в тему. Мне надо чтобы метод D::method(A*) работал с собственными данными класса D, а по типу своего аргумента определял как именно с ними нужно работать. 
Я так понял у меня изначально постановка задачи неверная. Нужно сделать по примеру, который расписал baldina, а в реализации метода D::method(A*) выполнять проверку типа аргумента. Если указатель на B - то один набор операций, если это указатель на С - второй набор операций.

Не очень хорошая идея делать проверки. Зачем вам тогда полиморфизм ?
Вам нужно чтобы все производные классы (в вашем случае A и B) умели возвращать данные через одинаковые методы, тогда вы сможете сделать следующее (немного переделал пример для понятности):




Это сообщение отредактировал(а) Artemon - 2.11.2010, 20:58

Не, тут дело в том, что проблемы вызвать нужную функцию из семейства А,В,С нет. Есть проблема правильно выполнить метод D::(A*). То есть в зависимости от того, какой фактический указатель передается в метод, я выполняю разные операции.

Зачем тогда вообще нужны классы A и B

Передавайте в метод класса D элемент из перечисления

enum EActions
{
 eAction1 = 0,
 eAction2,
 eAction3
};

void method (EActions a) 
       { 
            switch(a)
                     {
                      case eAction1:
                                            data += 1; 
                                            break;
                     case eAction2:
                                           data += 2;
                                           break;
                     }
       }

Я пример упростил, но в реальной программе из потомков класса А берутся некоторые данные при выполнении D::method(A*).

Все уже сказано выше, лично мне добавить нечего.

не все   (хотя пример с GetData очень близок по сути к отсутствующему)

http://liveworkspace.org/code/ca23ab383de6...54a82098539f3d6

Это сообщение отредактировал(а) mes - 3.11.2010, 10:51

mes, пример хороший и правильный. к сожалению, он вряд ли поможет ТС, а может и навредит, потому что 
 
где B и C имеют общего предка, скорее всего следствие ошибок проектирования.
те редкие случаи, когда это действительно нужно, возникают на более высоком уровне абстракции, когда про полиморфизм в С++ ясно все и понятны его недостатки.
если я неправ, хотелось бы не технический, а жизненный пример 
  из жизни самолетов   

Перенесите разные части того, что нужно исполнять в классе D в классы B и C (в виде виртуальной функции, описанной в классе A), и вызывайте ее из D::method(A*)

Это было бы неудобно, так как метод соотносится с классом D и работает с его данными. Работать данными метода D в классах В и С - как-то не корректно.

Тогда штудируйте различный паттерны, что вам больше подойдет. Начать можно с Visitor и MultiMethod

т.е. D, B и C связаны по смыслу, так? можно использовать дружбу.
но т.к. разработчик всех трех (четырех) классов один и может целиком влиять на проект, лучше изменить дизайн. например: почему B и C не могут использовать общедоступный интерфейс D?

Добавлено через 1 минуту и 52 секунды
я бы даже усилил: B и C связаны с D. при этом A не связан с D? или связан с чем-то более общим, чем D, но это не отражено в проекте?

baldina, возможно архитектура классов у меня и не оптимальная, надо подумать, но интересовала именно техническая реализация моей задумки (пусть и не лучшей).

Что касается задачи - D производит некоторые вычисления, для которого требуются различные потомки А. При чем от конкретного типа потомка зависит алгоритм вычислений, при это из этих самых потомков А берутся некоторые данные. Результаты вычисления хранятс в D.

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

ну тогда может поделитесь задачей, а не условными классами А,Б,Ц,Д.. ?
может кто подскажет что в таком случае подойдет.. 

Задача техническая.
Цель - расчет балки - определение в ней внутренних усилий от нагрузки.
Класс А - это класс Нагрузка.
Классы В и С - это производные от класса Нагрузка - ТочечнаяНагрузка и ЛинейнаяНагрузка.
Класс D - это, собственно балка.
Таким образом запись Балка::РасчитатьУсилия(Нагрузка*) - вычисляет усилия в балке от аргумента. Причем в зависимости от конкретного типа аргумента (ТочечнаяНагрузка или ЛинейнаяНагрузка) выбирается свой алгоритм. В расчетах фигурируют такие параметры как ДлинаБалки (принадлежит классу Балки), а также ЗначениеНагрузки и ПоложениеНагрузкиНаБалке (это данные принадлежат семейству классво Нагрузка).

помимо расчета нагрузки балка что еще умеет ? 

Классическая задача на multimethod (или double dispatch). См. http://en.wikipedia.org/wiki/Multiple_dispatch http://en.wikipedia.org/wiki/Double_dispatch

NB. Это конечно в том случае, если и Балка и Нагрузка по отдельности еще что то умеют


Это сообщение отредактировал(а) xvr - 3.11.2010, 17:04

вариант mes как раз на подпорки из-за отсутствия мультиметодов в С++ или поддержки аспектно-ориентированного подхода

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

Объекты класса Нагрузка пока ничего делать особого не умеют, кроме предоставления всем информации о себе и рисования себя.

Добавлено через 34 секунды

Ох с инглишом туго   

но таки ругань в сторону ТС была неоправдана, каюсь. double dispatch нужен, так что visitor в помощь

Добавлено через 3 минуты и 40 секунд
multimethod это множественный полиморфизм, когда функция для вызова определяется не по одному типу, а по нескольким типам аргументов:
типа

C++ не поддерживает, для  реализации используются подпорки типа visitor

Добавлено через 6 минут и 54 секунды
а у Нитонисе вероятно это


Добавлено через 10 минут и 11 секунд
если от теории к практике, то скорее всего типов элементов может быть много, заранее неизвестно каких, а типы нагрузок известны заранее, так что может быть самое разумное их просто захардкодить в виде отдельных функций для каждого элемента.

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

И в программе использовать так


Но как выяснилось это не работает и теперь я делаю так

Вобщем-то в любом случае, если у меня добавится новый тип нагрузки мне пришлось бы либо объявлять еще один метод  calculate(), где в качестве аргумента была бы новая нагрузка. И соответственно новый алгоритм расчета прописывать.
Либо в проверку типов (как по второму варианту) включать проверку на новый тип нагрузки и прописывать свой алгоритм.

Это сообщение отредактировал(а) Нитонисе - 3.11.2010, 18:14

а в чем отличие точечной нагрузки от линейной ?

и вопрос.. библиотека будет логически полной ? или предполагается дать возможность пользователю определять новые сущности ?

 и еще, что является наследником балки ?


Это сообщение отредактировал(а) mes - 3.11.2010, 18:39

Точечная нагрузка прикладывается к какой-то конкретной точке балки, соответственно один из параметров нагрузки - координата точки приложения. У линейной нагрузки такого нет - она прикладывается на всю длину. Операции расчета усилий я написал условно, по факту же, если аргумент точечная нагрузка, то наряду со значением нагрузки из нее запрашивается и точка приложения.



Имеется ввиду новые типы нагрузок? Пользователь такой возможности иметь не будет, а я, как разработчик, могу добавить новые типы.



На самом деле тут я немного тоже упростил. Любая балка имеет две опоры. Опоры могут быть различные - шарнир, жесткая опора или свободный край (консоль). Так вот наследники Балки - это разные типы с точки зрения опирания. То есть есть такие классы БалкаШарнирШарнир (две шарнирные опоры), БалкаШарнирЖесткая (слева шарнир, справа жесткая опора) и т.д. У каждого типа балки внутренния усилия от одной и той же нагрузки определяются по разному.

потом окажется, что балки могут иметь разные сечения, потом - учитывать податливость опор...
классификация обширная)))

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

У меня кстати, в контексте этого объектно ориентированного подхода есть один вопрос. Есть класс А, который является частью В, а В является частью С, который в свою очередь является частью D. то есть такая последовательная вложенность. А есть внешний класс Е, которому часто требуется обращаться к параметрам и А, и В, и С, и D, но логично установить связь всего лишь с верхним классом - D. И теперь получается, что если мне надо получить некоторые данные класса А, выполняя операцию Е, то появляется такая цепочка:

Что-то как-то это коряво выглядит.

Это сообщение отредактировал(а) Нитонисе - 3.11.2010, 19:31

Ох, не ту вы задачу выбрали для первого проекта   
То, что вы хотите, выходит за рамки ООП, как оно реализовано в С++. 

В вашем случае функции расчета нагрузки не должны быть членами класса 'Балка'. Равно как и членами класса 'Нагрузка'. Это должны быть вообще отдельные сущности, выбираемые по сочетанию динамических типов 'Балка/Нагрузка'

Это наследование (как одна из возможных реализаций)
А это динамическое агрегирование (как одна из возможных реализаций). Вы уж определитесь, что у вас 'есть'

Ну на простом проекте ООП впринципе не нужен)


То есть функция принимает в качестве аргументов объект нагрузки, объект балки и возвращает некий результат? Ну это как вариант... врядли тут могут быть единственно правильные решения. Или вы попробуете обосновать почему именно ваш вариант наиболее предпочтителен?


Я привел другую ситуацию. Это уже не о расчете балок. Классы от А до D вложены один в один как матрешки. А есть класс Е, которому нередко нужны данные из каждого из этих матрешек. Мне кажется с таким подходом будут слишком велики накладные расходы по вызову функций возвращающих объект с более низкого уровня (начиная от D и до А).

да и на сложном проекте.. не всегда нужно "сырой" ООП пихать всюду...

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

Добавлено через 6 минут и 37 секунд
исходя истого что написали:
1. задача по расчету нагрузки на балку вместо двух имеет три компонента,
а именно: балка, нагрузка, и площадь соприкосновения

2. наследование от балки, мягко скатать, неэстетичное и стоит отказаться в пользу агрегации

3. функции расчета нагрузки, как уже сказали выше, не относятся к балке...

итого в той  части задачи, которую Вы описали,  полиморфизм притянут за уши,  и никакой выгоды вы от него не получите..

Добавлено через 9 минут и 16 секунд

потому, что балка вместе с нагрузкой не обладает достаточными знаниями для решения этого вопроса..

Добавлено через 10 минут и 53 секунды
и вобще старайтесь не втягивать зависимости внутрь классов.. чем меньше тем легче поддерживать и развивать проект.. 

Так ООП более предпочтительно структурного программирования. Во всяком случае область применения ООП выше. Мой нынешний проект вполне годится для опробирования ООП. Есть действующий аналог со структурным походом, хочу переписать его в объектный.


И что должно быть в площади соприкосновения?


В чем будет агрегация? Есть балка, у балки могут быть три типа опор с каждой стороны. Можно типы опор впринципе прописать как свойства балки... но чем это лучше?


Что ж это тогда будет - просто свободная функция?



Не спорю, что он тут реализован неэффективно, но надо хоть почувствовать на своих родных объектах как он работает и в каких случаях какие функции вызываются))


Как же не обладает? Обладает. Достаточно данных нагрузки и балки чтобы определить внутренние усилия.


То есть? Стараться не передавать методам объекта в качестве аргументов других объектов и не содержать в качестве данных класса ссылки и указатели на др. объекты?

ООП бывает разное.. ООП - как подерживаемая компилятором парадигма.. ее надо принять там где нужно.. и не злоупотрблять.. и ООП (точнее ООА объектно ориентированный анализ) как способ группировки знаний - тут стоит уделить побольше внимания..

Добавлено через 1 минуту и 7 секунд

Я Вас не отгавариваю от ООП, а говорю что не все ее достижения стоит запихивать в одну корзину.. кстати этим вы убиваете ООП как подход...

Добавлено через 2 минуты и 14 секунд

наличие кучи наследований не достаточно для установления объктного подхода..

Добавлено через 3 минуты и 42 секунды

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

Добавлено через 5 минут и 19 секунд

ну так смотрите что написали жирным, так и записывайте в программный код, и не нагружайте логику ни себе, ни другим..

Добавлено через 6 минут и 45 секунд

если не зависит от какого то мира знаний, то просто свободная функция..  и не бойтесь что это ведет удаляет от ООП, наоборот Вы начинаете использовать его силу..

Добавлено через 8 минут и 17 секунд

неэффективно, это лишь малая доля проблемы.. намного большая проблема - не логично..

Добавлено через 9 минут и 30 секунд

Это в вашем ограниченом варианте достаточно.. а если подумать далеко не так все одназначно..
или весы и на земле и на луне  показывают одно и то же ?

Добавлено через 10 минут и 59 секунд

нет.. стараться не вносить детали и знания, которые объекту не необходимы.. 

И зачем такие сложности? Почему нельзя вычислять усилия в объекте Балка с аргументом Нагрузка?

Это значит такой код?


С таким подходом отдельными функциями можно реализовать практически ВСЁ. Будет одна программа, вызывающая другие подпрограммы, которые вызывает более мелкие подпрограммы. Это не ООП, а структурный подход.

хм.. т.е. из крайности в крайность ?


а ООП и есть структурный подход  

Добавлено через 6 минут и 37 секунд

потому что реализацию расчета нагрузок для всех видов объектов удобно поместить в одно место, в независимости от классов самих объектов..

А вот стоит ли группировать расчет нагрузок в класс или нет - зависит от реализации..

Один из принципов ООП (в С++) - инкапсуляция. Это в частности означает, что все операции класса (т.е. операции, использующие и влияющие на состояние класса) должны быть описаны ВНУТРИ класса. Возьмем операцию 'Расчет нагрузки на балку'. Она ни может быть описана ОДНИМ классом (ни Балкой ни Нагрузкой). Она полностью (в том числе и алгоритмически) зависит от обоих этих классов. А это означает, что в рамках ООП в С++ она НЕ МОЖЕТ быть членом ни одного из этих классов.
А это в свою очередь означает, что НЕ НАДО притягивать сюда за уши ООП механизмы С++, нужно строить НОВЫЙ механизм, используя возможности С++

Вы смотрели ссылки, что я давал? Там расписано (в том числе с примерами на С++) как это делать.
Еще поищите в сети 'Паттерны программирования' (как то так называется). Должна быть информация и на русском.

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

Вот, замечательный пример на непонимание основ (или на неумение сформулировать задачу)   

И что ж тогда? Объявить нагрузку атрибутом класса балка? Тогда классу всего хватит, чтобы вычислить усилия в балке от нагрузки. 
Мне представляется ООП - это куча различных объектов каким-то образом взаимодействующих друг с другом. Причем взаимодействие должно быть обязательно, иначе система попросту не будет работать. Это все равно что поставить в кузов от машины мотор, но не соединить его с ведущей осью - машина никуда не уедет.
В контексте моего проекта есть объект нагрузка и есть объект балка. Одно не являются частью другого, они могут существовать независимо друг от друга. При этом нужно уметь посчитать усилия в балке от этой нагрузки. Усилия ведь без нагрузки быть не могут. Значит все слепить в один класс? Но тогда придется все объединять и объединять до тех пор, пока не получится куча различных параметров, характеризующих систему и к этой куче обращается куча подпрограмм, оперирующих ими. Это не ООП, а структурный (алгоритмический подход).

Добавлено через 1 минуту и 31 секунду

Перейдем к более конкретным абстракциям. Есть спица, спица часть обода, обод часть колеса, колесо часть шасси. Предлагаете все эти объекты объявить наследниками друг друга?

вам уже говорили, ничего лишнего, что не отражает действительно состояние балки.. 



не совсем правильное представление.. этого не достаточно чтоб называться ООП..


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


обратите что на соединение идут другие детали/механизмы, а не все пихается в двигатель или в ось..


Вам как раз обратное советуют..


то что Вы описали не структурный подход, а куча хлама..


ни за что 
кстати покажите цитату после которой Вы сделали такие далеко идущие планы..

Это сообщение отредактировал(а) mes - 4.11.2010, 14:11

В контексте моей задачи состояние балки характеризуется только длиной пролета и типами опор.
Состояние нагрузки характеризуется ее величиной и положением на некоей абстрактной балке.
Мне нужно определить внутренние усилия в балке от нагрузки. Каким образом это делать? Помним о том, что другие объекты могут спросить у балки - "А какие у тебя внутренние усилия от этой нагрузки?".

вот сейчас я считаю описание задачи составлено довольно ясно и правильно.. 
и отражает все связи внутри мирка..

и так у нас есть основные сущности


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

вот условный набросок :


Это сообщение отредактировал(а) mes - 4.11.2010, 14:48

То есть надо создавать объект класса БалкаПодНагрузкой, атрибутами которой будут один экземпляр Балки и вектор экземпляров Нагрузка?

не совсем так.. там ниже приведен пример.. 

Где хранить результат расчета? Нагрузок может быть много.

Почему вы все объявляете структурами?

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

Добавлено через 1 минуту и 35 секунд

сделайте конструкцию в которую можно добавить не одну нагрузку..

если я правильно понял ваш вопрос.. 

Впринципе ваша структура близка к моему классу Балка, в чем разница-то?

Это класс одного из потомков балки с шарнирными опорами слева и справа. Метод calcMOneLoad - перегружен, в базовом классе он объявлен виртуальным. В зависимости от типа нагрузки Load производится определенный расчет моментов. Причем если бы балка была например класса BeamHingeRigid (слева шарнир, справа жесткая заделка), то метод calcMOneLoad считал бы уже совсем по другому.

А как в вашем примере бышел расчет? Нужно было бы постоянно опрашивать свойство support, чтобы определять тип расчета и плюс к этому опрашивать тип нагрузка Load, чтобы еще одну развилку делать... получится очень ветвистая функция.

кстати можно сделать конструкцию, состоящую из других конструкций..

Добавлено @ 14:54

а Вы попробуйте написать в этом стиле , и увидите  

Добавлено @ 14:56
во первых Вам не нужно будет жестко наследоваться от балки, ради балки с двумя опорами - этого уже достаточно..

Добавлено @ 14:57

если сделать структурой то да.. если классом (т.е. убрать состояние в приват) то только при изменении составляющих.. 


Добавлено через 6 минут и 10 секунд

а чтоб не делать развилок, для этого тоже есть решения 


Это сообщение отредактировал(а) mes - 4.11.2010, 14:57

mes, дело в том, что я больше знаком с предметной областью и мои решения происходят именно от этого знакомства. Сюда я выкладываю только небольшую толику темы, так как он специфична и многим будет попросту непонятна. Ведь те описания объектов и те связи, которые я тут показал - далеко не полны. Их будет много больше, равно как и объектов будет тоже намного больше.

Если интересно, могу полностью описать систему.
Необходимо рассчитать многопролетную балку методом перемещений. Есть некий графический интерфейс, который позволяет задавать новые пролеты, редактировать их, задавать типы опор. Есть графический интерфейс, регулирующий нагрузки, там можно задать тип нагрузки и ее характеристики. При этом нагрузки задаются в контексте уже заданных пролетов, то есть если нагрузка выходит за пределы пролета, то она попросту не добавляется. Нагрузки так же можно группировать в комбинации посредством еще одного графического интерфейса. То есть можно рассматривать балку нагруженную разными сочетаниями нагрузок. Вся эта расчетная схема сразу же после получения данных или их корректировки отображается в графическом окне на канве компонента TImage. Если балка статически неопределима - производится ее расчет методом перемещений. Этому методу нужно работать со всеми данными по балке (с пролетами и с нагрузками). После решения балки методом перемещений можно определить внутренние усилия в сечениях балки (в каждом ее пролете) с заданным интервалом. Наборы усилий должны сохраняться, так как их будут запрашивать другие объекты (например подбор металлической балки). После решения балки результаты немедленно должны отрисовыватьс в графическом окне в виде эпюр (график распределения внутренних усилий по длине балки).

Задачу необходимо решить таким обьразом, чтобы было затем удобно осуществлять сопровождение программы, модифицировать ее, расширять функционал. Так же нужно разработать объекты, которые было бы возможно применять в других программах. Например простая однопролетная балка. Если мне в другой программе понадобится считать такую балку, я хочу чтобы у меня было уже готовое решение - балка, которая умеет в самой себе определять усилия от заданной нагрузки. Так же отдельно и независимо должен быть реализован метод перемещений. Я могу захотеть решать балку другим методом (например метод сил) и нужно чтобы он легко интегрировался в общую структуру, без существенных изменений. 

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

Добавлено @ 15:32
вот например акак реализована эта подзадача 

?

Добавлено @ 15:33

ну вот сами говорите, что должен быть свободной функцией.. 
или самостоятельным классом..


остальное оставлю без коментариев, так как много букв.. 


Это сообщение отредактировал(а) mes - 4.11.2010, 15:35

Кода пока и нет - я его только разрабатываю.


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


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



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

Вот меня интересует абстрактный пример.
Есть класс Фигура. Частные варианты Фигуры - это Квадрат, Круг, Треугольник. Что лучше - объявить потомков от Фигуры, или создать атрибут ТипФигуры, принимающий одно из трех значений - Круг, Квадрат, Треугольник. Как мне кажется первый вариант лучше, потому что позволяет затем использовать перегруженные функции, например draw(). Ведь во втором варианте в функции дро пришлось бы проверять атрибут ТипФигуры и в завивисимости от него идти по тому или иному пути, то есть цепочка if..else.

Та же история с балками. Опоры у балок могут быть разные. Что лучше - породить потомков с перегруженными функциями расчета усилий или объявить аргумент в класса Балка, указывающий на тип опор... логика та же, что и с фигурами. Возможно отличия базового класса от потомков тут незначительны, но ведь в будщем могут появиться новые существенные отличия, которые я сейчас не могу предположить и тогда модифицировать код было бы намного проще имея структуру потомков и предков, чем заданные атрибуты в одном классе.

Зависит от задачи, если это к примеру графический редактор, то да, удобнее если наследуются от класса фигура.. 

Есть вариант, когда у класса фигура может не быть своего метода draw..
тогда когда отображение зависит не только от внутреннего состояния..

Добавлено @ 16:08

логика не та же... 
чтоб была  таже :

у нас есть фигура_прямоугольник, он может быть с бордюром, может с закругленными краями
может иметь разный цвет.. Будем для каждой композиции атрибутов заводить свой класс ?

Добавлено через 6 минут и 23 секунды

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

Добавлено через 13 минут и 54 секунды

т.е все на весу ? а не легче ли сделать класс, который эту логику проведет ? 
 

Это сообщение отредактировал(а) mes - 4.11.2010, 16:09

Я думаю, что если особенности реализации того же рисования существенно отличаются, то можно наплодить потомков, а если не очень (как например цвет), то можно это задать атрибутом. А вы по какому принципу плодите потомков? Приведите пример.


На каком весу? Я просто еще не решил как это будет реализовано, обозначил пока только задачу. Возможно отдельным классом буду это обрабатывать.

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

Добавлено через 4 минуты и 27 секунд

по описанию задачи и в зависимости от требований ей поставленных.. 

Какое слово в предложении 'НЕ МОЖЕТ быть членом ни одного из этих классов' не понятно? Я уже 2 РАЗА давал одни и те же ссылки, вы с ними ознакомились?
Точно, вот только их больше, чем вам представляется

  Интересные у вас выводы. Я фигею, дорогая редакция.   
У вас должен быть ОТДЕЛЬНЫЙ БАЗОВЫЙ КЛАСС ДЛЯ ПОДСЧЕТА УСИЛИЯ. И их (этих отдельных наследников классов), должно быть столько, сколько существует возможных комбинаций <типов балки>х<тип нагрузки>

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


Это сообщение отредактировал(а) xvr - 8.11.2010, 16:01

Что же этот класс делает? Считает усилие и все? Функционал сопоставим с единственной функцией, тем более что внутреннее состояние этого класса никому не интересно, кроме самого этого класса. Все вокруг хотят только усилие от этого класса. Проще сделать уже отдельную функцию

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

Я говорил именно об агрегации, это вы решили обернуть это наследованием. Мне нужно чтобы внешний объект имел хороший (быстрый) доступ ко всем составляющим одного целого - матрешки. Внешний объект должен легко получать данные как из самой большой матрешки, так и из самой маленькой. Так вот если нужно получить данные из самой маленькой - будет та цепочка вызовов, о которой я писал.


А я писал всего один раз - с английским на "вы"    

Да
Да
Да

Нет, не проще. Multimethod предполагает динамическое разрешение типа вызываемой функции от типов объектов. Это аналог виртуальных методов, но обобщенный на группу взаимодействующих экземпляров классов. Перегрузка функций не даст run-time полиморфизма. 
Пример:


Нет, не велики.

Я это не решал, я так понял ваш вопрос. (О чем и написал, кстати)
Сделайте во внешней матрешке методы для доступа на разные глубины по иерархии, тогда цепочки вызовов не будет. Если у вас вложенные объекты формируют контейнеры, то можно посмотреть в сторону STL - сделать аналоги STL'ных контейнеров и итераторов (для единообразия)

На эту тему и на русском материалов немало
http://ru.wikipedia.org/wiki/%D0%9C%D1%83%...%82%D0%BE%D0%B4
http://www.rsdn.ru/article/cpp/multimethods.xml

http://www.google.ie/search?q=%D0%BC%D1%83...lient=firefox-a (3550 результатов)

http://www.google.ie/search?hl=en&clie...q=&gs_rfai= (7890 результатов)


Это сообщение отредактировал(а) xvr - 9.11.2010, 16:06

Тогда просто эта цепочка будет скрыта в реализации класса. Меня как раз именно неказитсая реализация смущает. А именно - вызовы функций, возвращающие объекты более нижнего уровня.
Например мне надо узнать параметр data из класса D на самом нижнем уровне, тогда получается такая цепочка



Надо почитать.

Это как раз нормально

А это можно и скрыть в классе повыше   

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

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

Добавлено через 1 минуту и 35 секунд

а не надо получать каждый элемент отдельно.. за один раз получаете структуру 4го уровня, и оперируете уже с ней 

Это как?

хм.. на абстрактном примере неудобно объяснять.. 
грубо говоря не бойтесь делать вложенные функции..

Добавлено через 8 минут и 40 секунд
ну а применительно к вашей задаче, думаю, будет удобно разбить на два слоя :
нижний - уровень формул, где все связи статические.. 
верхний - уровень визуализации, полиморфно объединяющий сущности нижнего уровня..

Добавлено через 12 минут и 36 секунд
могу показать на примере, если приведете полностью формулу расчета нагрузки .. 

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

результаты расчета по ссылкам m1, m2 заносятся во внешние переменные.