т.е. 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

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

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

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