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


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


Я привел другую ситуацию. Это уже не о расчете балок. Классы от А до 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 секунд

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

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