Пишу программу - расчет многопролетной балки. Пытаюсь применять объектный подход.
Главный объект программы - Балка. У балки может быть от одного до бесконечности Пролетов. В каждом пролете нужно построить Эпюры. Эпюра - это график распределения внутренних усилий по длине Пролета.
Эпюры я выделяю в отдельный класс.

В классе Пролет имеется ссылка на объект класса Эпюра.

Как видно из кода класса Пролет (Span) все переменные класса Эпюра (Diagram) задаются вне этого класса. Что уже само по себе не удобно. При этом некоторые другие функции могут обращаться к значениям векторов X,M,Q класса Diagram, например функция отрисовка Эпюры на канве. И опять же, снаружи осуществлять доступ к отдельным элементам этих векторов неудобно. Придется писать свои функции доступа наподобие

Насколько оправдана такая структуризация данных с учетом усложненных методов доступа к данным? При этом класс Diagram обладает собственными функциями, например определение максимальных и минимальных значений из векторов M,Q. Класс может быть использован и в других программах в таком же виде.

это выглядит не логичным в рамках ООП..

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

вот читайте что сами написали и сравните с вашим кодом.. 

А что выглядит логичным? Определить эти функции в классе Diagram? По задумке класс Diagram - хранилище результатов расчета балки. Тобишь расчетная часть - не входит в сферу компетенции этого хранилища и реализуется в другом классе (классе Span).

Либо расчеты сделать вообще внешними по отношении и к Span и к Diagram?

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



Читается как, на основании пролета надо построить эпюры.. 
А значит пролет входит в состав диаграмы, а не диаграма входит в состав пролета.. 

Потому что по-моему логично расчеты поместить в этот объект. Для расчета этот объект обладает всем необходимым, а именно - длина пролета, вектор нагрузок (собственно больше ничего и не надо). Результаты же расчета хранятся в векторах X,M,Q. Их можно было бы объявить тоже в классе Span как атрибуты, но меня останавливает то, что точно такие же атрибуты могут быть и в другом классе и в другой программе. Тогда пришлось бы тупо дублировать собственный функции определения максимальных M,Q, что хоть в сущности нетрудоемко, но по сути считаю неправильно.


Первое предложение верно, а вот логика второго не ясна))

расчет совершается над пролетом, а не пролетом.. 

Вот есть Пролет (Span). Он характеризуется длиной (int length), приложенной к нему нагрузкой (vector<Load*> loads) и двумя значениями крайних моментов М1 и М2 (в предыдущем посте не указал, но эти значения нужны для расчета всех значений внутренних усилий по длине пролета). Нужно рассчитать внутренние усилия в сечениях балки с заданым интервалом. Набор сечений хранится в векторе X класса Diagram.
Вы предлагаете вместо определения расчетной функции внутри этого класса, которая бы оперировала данными этого класса, объявить внешнюю функцию, в которую в качестве аргументов передать следующее:
 - длину пролета
 - левый крайний момент М1
 - правый крайний момент М2
 - вектор нагрузок на пролет
 - координата сечения, где определяем усилия
 - ссылку на объект Diagram для записи результата расчета.
Не слишком ли много аргументов будет у функции? Ведь внутри класса эта функция работает без передаваемых аргументов вовсе.

Хотя можно в качестве аргумента передавать объект Span... только что от этого выигрываем?

Это сообщение отредактировал(а) Нитонисе - 15.11.2010, 10:59

с чего бы вдруг ?! 


не обязательно так 

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

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

Ну с того что надо где-то хранить набор сечений))


Ну я выше предложил - можно объект Span передать в качестве аргумента и получить внутри функции доступ ко всем его данным. Только что от этого выигрывается?

хочу уточнить: внешнюю по отношению к Span.. но не обязательно абсолютно внешнюю.. 

Непонятно для чего. Хотелось бы иметь возможность применять данные разработки и в других программах, подключая готовый модуль, а не готовый модуль + наборы внешних функций, который вобщем-то не нужны без объекта класса Span, уж коль скоро они оперируют его данными.

ну так кто против? 
или это аргумент чтоб запихнуть в Span,и еще к тому же следить за тем когда вызывать функции calc ?

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

Так нужно учитывать и кому это нужно ..Spanу оно нужно ? 

Так что ж тогда объявлять собственными функциями объекта если не функции, оперирующие собственными данными?) Каков глубинный смысл выносить такие функции за пределы класса?

функции описывающие внутреннее поведение объекта, а не операции над ним.. 



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

Конечно нужны. А как же получить усилия в Spanе?
Хотелось бы использовать в программе код такого типа


В вашем же случае будет

В чем преимущества этого метода?

P.S. Что у вас за манера постоянно править свои посты по всей теме? Думаете так удобнее общаться?

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

Так расчет внутренних усилий - это и есть поведение объекта.