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

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

Как видно из кода класса Пролет (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 секунды

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

это выражение не вяжется с функцией calcМ

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

нет.. в моем случае будет не так 

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

расчет усилия в  диаграмме ?

Почему?


А как будет в вашем случае?


В пролете. Диаграмма - это результат расчета усилий в пролете.

вот , а в коде у Вас что ?

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

выкиньте диаграму и слова с корнем calc, но оставьте все что описывали по отношению к пролету  - и будет мой случай.. 

А что у меня в коде? Именно так в коде и есть.

вот что должно быть в пролете : 


Добавлено @ 12:07

диаграмма у вас является результатом операции над спаном ?

Добавлено @ 12:08
насчет сечений, я из ваших постов не до конца понял.. принадлежат ли они пролету или чему то другому..


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

Тогда это просто структура данных без поведения. 


Да.

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

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

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

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

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

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

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

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

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

Обязанности диаграммы - определение минимальных и максимальных усилий M,Q, а также проверка на то, есть ли экстремум в эпюре М. Экстремум - это пик графика М. Так как значения М у меня определяются с некоторым интервалом, то экстремум может оказаться как раз в каком-то промежуточке. То есть, я определяю моменты М в сечениях с шагом 50 мм, но от заданой нагрузки экстремум оказался на отметке 2330 мм. Понятно что это значение момента не попадет в вектор М, так как там будут значения при х=2300 и х=2350. Вот внутрення функция диаграммы на основе вектора Q будет выяснять есть ли экстремум М. Ну и плюс еще отрисовка диаграммы на канве. Пока еще не решил где быть этой функции. Ясно пока одно - при отрисовке нужен будет доступ к каждому значению векторов X,M,Q, поэтому желательно, чтобы доступ к этим вектором был упрощен, что может быть в случае если функция отрисовки будет объявлена методом класса диаграммы.

Добавлено @ 12:36
Вот картинка с расчетом балки, если это как-то пояснит задачу.

Имеется балка (объект Beam) с тремя пролетами (три объекта Span). У каждого объекта Span свой вектор нагрузок Load. В данном случае по одной нагрузке у каждого спана (нагрузки разнотипные). 

Ниже отрисованы эпюры (диаграммы). Они строятся на базе векторов X,M,Q объекта Diagram каждого из спанов.



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

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


давайте для начала сделаем span.. 

Почему же? Ведь это просто тупой перебор значений соответствующих векторов и сохранение максимальных значений в Mmax и Qmax, являющихся также атрибутами класса Diagram.

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

Добавлено @ 12:50

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


а диаграмма , как и обычно,  это график, который может быть где либо отображен..  ?

уточняюю,  общее ли у нас понимание терминов.. 

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

Добавлено через 10 минут и 1 секунду
опять насчет сечений.. сечение, это диаметр среза пролета или чего то другого  ?

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

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

Добавлено через 14 минут и 49 секунд
и так у нас есть пролет и диаграмма... диаграмма строиться на основе сечений.. так ?


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

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


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

Пролет - это часть балки между опорами. В данном случае опоры четыре - пролета три.


Диаграмма - это график функции. Эпюра М и эпюра Q - это графики функции. Как и у любого графика, каждая его точка характеризуется двумя координатами (речь идет о двухмерных графиках). В данном случае графики строятся по Х (длина пролета) и М (момент в пролете) и по Х и Q (поперечная сила в пролете). Этот график может быть где угодно отображен по имеющимся значениям X,М,Q.


Сечение - это координата на оси пролета. У меня на картинке на двух графиках вертикальные линии - это и есть сечения. Для построения графика требуется набор сечений (вектор Х), где хранятся координаты пролета, где мы будем определять М и Q, то есть вектор Х может выглядеть таким образом: 0,50,100,150,200...  и т.д., это все координаты пролета в милимметрах в данном случае с шагом 50 мм.

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

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

то есть набор сечений в сумме составляет длину пролета ?

Добавлено через 1 минуту и 40 секунд
для чего нужны эти сечения, кроме как указания точки расчета момента ?

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

я так и чувствовал  значит спан не обладает сечениями 

Добавлено через 5 минут и 45 секунд
постепено картина начала выстраиваться 

Нет, не в сумме. На пролете 1 метр набор сечений может быть таким: 0,100,200,300,400,500,600,700,800,900,1000. Именно в этих точках будут посчитаны значения M и Q (внутренние усилия). То есть усилия будут определены прямо на левой опоре пролета, затем на расстоянии 100 мм от левой опоры, затем на расстоянии 200 мм и т.к. далее по вектору Х. Интервал - величина переменная, пользователь может всегда ее поменять. Например задать интервал 10 мм и тогда вектор Х примет вид: 0,10,20,30...980,990,1000. Теперь усилия будут определены на левой опоре пролета, на расстоянии 10 мм от левой опоры, на расстоянии 20 мм от левой опоры и т.д.



Для указания где считать M,Q, а также для последующей отрисовки эпюры M и Q.

еще вопрос.. верно ли "пролет знает(может сообщить) моменты М и Q для любой своей точки  " ?

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

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

Это в большей мере расчетная характеристика. То есть мы определяем степень детализации расчета. В контексте задачи пролет - это сущность, которая выполняет некоторые расчеты и в этом смысле набор сечений ему необходим, иначе он не будет знать где вычислять M и Q.

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

Да, у него будет функция типа getM(int X), где X - координата пролета, где требуется определить момент.


Алгоритм деления на интервалы такой:
 - пользователь задает максимальный интервал
 - функция Span::createSectionsSet() начинает создавать вектор X класса Diagram, при этом анализируется вектор нагрузок Load, ниже поясню как.

Допустим пользователь задал интервал в 50 мм, а у нас есть точечная нагрузка на пролет, расположенная в 30 мм от опоры. В этом случае точка 30 мм тоже будет помещена в вектор Х. То есть получится: 0,30,50,150,200 и т.д.

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


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

и возвращает моменты в указанной точке.. 

В принципе да. Только каждый объект Diagram соответствует вектору нагрузок. То есть, если на пролет задан только один вектор нагрузок, то объект диаграмм может быть в единственном числе, ну разве что наплодить таких же объектов с другим интервалом сечений, в чем, вобщем-то, нет смысла.

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

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

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

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


Нет, промежуток и интервал - это в сущности одно и то же. График строится на основе X и M (эпюра М) и X и Q (эпюра Q). При этом при построении графика будут учитываться экстремумы, но о них пока не говорю, так как это усложнит картину.


Ну это возможно - имея пролет с нагрузкой построить сотню диаграмм M и Q с разными интервалами. Но это только если для понимания сути задачи, так как на практике это не нужно, диаграммы (эпюры) будут строиться с заданным интервалом в единственном числе. Другое дело, что я могу сменить нагрузку на пролет - диаграммы создадутся и отрисуются заново.

я имел ввиду применительно к обсужденному в теме.. 

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

сорри за опечатку.. span инстинктивно обратно перевел как промежуток )
на основе пролета и интервала 

Спан не нужен. Для построения графика нужны координаты его точек. В данном случае X,M и X,Q. 
То есть можно сказать объекту класса Diagram: "Рисуемся отсель и с таким масщтабом" - и он рисуется. В коде примерно так

ага, понимание самое главное 

а как же длина пролета ? нагрузки на него ? как без этого то построить диаграмму   

Если вы имеете ввиду расчет точек графика, то нужен спан, а если отрисовку графика - то не нужен.

отрисовку мы не обсуждали.. 

Тогда для расчета нужны:
 - длина балки
 - момент слева
 - момент справа
 - вектор нагрузок
 - набор сечений с заданным интервалом.
На выходе имеем
 - вектор Q
 - вектор M

ну это у вас насколько я помню внутренние характеристики балки.. 


Ну а набор сечений это в принципе внутренняя характеристика, основанная на интервале.. 

Ну да. 

ну так разобрались ? или еще есть вопросы ? 

С чем разобрались? Ни с чем не разобрались. Собственно я так классы и спроектировал. Мой вопрос втом - насколько оправдано выделять класс Diagram отдельной сущностью, уж коль скоро имеется масса неудобств при работе с ним.

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

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

Смысл есть.. так как эпюры не являются частью балки или спана..

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

а вот где Вы увидели неудобства ?

приведите последнее представление вашего  кода 


Добавлено через 8 минут и 1 секунду
то что важно для : span beam и diagramm 

Предполагаю такую структуру



Не то что бы частью, а сопутствующим объектом имеющим четкую ассоциацию с конкретным объектом класса Span.


Неудобства в том, что при работе функции greateXSet (создание набора сечений) на первом этапе данные будут заноситься во временный ыектор, а потом весь этот вектор будет копироваться в атрибут Х Diagram. Напрямую работать с вектором Х неудобно, так как потребует создания функций типа setX(int index, int value). Примерно такая же функция для считывания данных из векторов. Если представить что в программе будет 10 пролетов и у каждого пролета 100 сечений, то такие усложненные схемы доступа мне видятся неоптимальными, ведь будь эти векторы X,M,Q данными класса Span, то доступ бы был намного проще.

У меня дежавю? Или мы наблюдаем 2й сезон мыльной оперы?
Первый назывался 'Изобретение Паттерна Multimethod в 108 сообщениях'
Второй видимо будет называться 'Изобретение Паттерна Visitor в 47 (пока) сообщениях'

2 ТС: Почитайте какую нибудь книжку по Паттернам Проектирования и заканчивайте вынос мозга участникам конфы. Все, что вам тут объясняют описано в этих Паттернах гораздо более полно и развернуто.

ну так это ж не члены пролета..

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

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

Добавлено через 11 минут и 46 секунд
а можно и удобно сделать 

Что именно там описано? Тут вопрос выделения классов и установки между ними отношений. При чем тут паттерны?


А куда их деть?))

Ну например? Как снаружи добраться к пятому элементу вектора, объявленного protected?

Это тоже относится к паттернам (архитектурным)

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

все зависит от интерфейса 

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

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

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

туда где им место.. в вашем случае в диаграмме... (если конечно ж они вобще нужны в таком виде )

Блин. 'Пастернака не читал, но осуждаю'   
Именно это - вопрос выделения классов и установки между ними отношений ТАМ И ОПИСАННО!

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

вот интерфейс класса Diagram



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

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

О, если так, то это то что нужно) посоветуйте автора.

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

Цитата(Нитонисе @  15.11.2010,  15:34 )

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

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


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

что делает setX ?

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

Да уж советовал, и ссылки давал. Все впустую   

Вот, классика:


Еще
WiKi

http://c2.com/cgi/wiki?CategoryPattern

Очень неплохая статья

он делает X[index] = val


Вы на мультиметоды давали ссылки. тема интересная, но я ее пока не потяну))


А вот это скачал, буду образовываться)

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

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

a интервала не достаточно, для  расчета этого вектора ?
если нужен именно вектор, то чем не устраивает:  на входе: вектор сечений и пролет, на выходе эпюра/ы ?

Для заполнения вектора Х значениями нужен еще вектор нагрузок.


Вектор сечений еще нужно задать, а задается он функцией класса Span. Вот тут и выбор варианта - либо пользование setX для работы напрямую с вектором X класса Diagram, либо создание временного вектора внутри функции createXSet, заполнении его значениями, а потом копирование в вектор Х Diagram.

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



то есть третьего варианта не дано ?

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


В данной системе классов другого варианта не вижу.

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

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

так может стоит над этой проблемой подумать ? кстати что мешает напрямую обратиться ? 


не вижу проблемы? сформулируйте интерфейс так, чтоб это не было проблемой.. 


не важно.. зависит от модели "рисовальщика"..


да, если нужно отделить данные от вида, то рисовальшик должен быть отдельным
 

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

а кажись понял.. Вам мешает слово protected ? как самый простой вариант, откройте возврат константной ссылки на него 

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

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

Добавлено через 5 минут и 9 секунд
для вектора можно затайпдефить std::vector, а можно написать свою обертку, если требуется более жесткие гарантии.. 

То, что и длина и вектор нагрузок protected в классе Span.


Сделать эти вектора public?


Не понял.

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

Опять не понял.

И это тоже не понял)