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

Это класс одного из потомков балки с шарнирными опорами слева и справа. Метод 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го уровня, и оперируете уже с ней