Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/topic.php on line 737 Форумы портала PHP.SU :: Помогите спроектировать
Покинул форум
Сообщений всего: 6
Дата рег-ции: Нояб. 2013
Помог: 0 раз(а)
Есть 2 сущности. Продукты(Product) и Страховые Компания(Insurer). В их связки образуется Договор.
Договор нужно сначала Посчитать(Calculator), потом Сохранить(Save).
Сохранение может быть как у Продукта, так и у Страховой Компании.
Помогите спроектировать.
На картинке нарисовал к чему я пришел, но думаю есть и куда лучше вариант реализации. Прикреплено изображение (Нажмите для увеличения)
AmsTaFF
Отправлено: 29 Ноября, 2013 - 14:36:40
Гость
Покинул форум
Сообщений всего: 84
Дата рег-ции: Июнь 2013 Откуда: Россия, Москва
Помог: 1 раз(а)
я бы посоветовал отдать ответственность за сохранение договора какой-нибудь одной сущности.
Что из себя представляет Save? Calculator? что он считает? Какие данные нужны? Почему договор могут сохранять 2 сущности?
P.S. что продукт может сохранять договор...
P.P.S. откуда такие абстракции? почему они без методов?
-----
Djos
Отправлено: 02 Декабря, 2013 - 07:35:50
Новичок
Покинул форум
Сообщений всего: 6
Дата рег-ции: Нояб. 2013
Помог: 0 раз(а)
Есть 3 продукта ( П1, П2, П3 ), и 2 Страховые компания( СК1, СК2 ).
Если брать их по отдельности, они сущности и нечего из себя не представляют.
Если взять связку П1 + CК1 то получим договор по Продукту 1 у Страховой компании 1 или П1 + СК2.
Связка может быть любая, главная чтоб были 2 сущности П и СК.
Можно начать оформление договора с 1-й из сущности, но когда доходим до Расчета должна быть известна 2-ая сущность.
Получается чтоб Рассчитать договор нужно связка П и СК, так же и с Сохранением.
AmsTaFF пишет:
я бы посоветовал отдать ответственность за сохранение договора какой-нибудь одной сущности.
По подробнее.
AmsTaFF пишет:
Что из себя представляет Save? Calculator? что он считает? Какие данные нужны? Почему договор могут сохранять 2 сущности?
Расчет( Calculator ) - считает стоимость договора. Расчет может полностью на нашей стороне или на стороне СК.
Сохранение( Save ) - сохраняет договор. Сохранение происходит на нашей стороне, и на стороне СК.
AmsTaFF пишет:
P.S. что продукт может сохранять договор...
P.P.S. откуда такие абстракции? почему они без методов?
Покинул форум
Сообщений всего: 84
Дата рег-ции: Июнь 2013 Откуда: Россия, Москва
Помог: 1 раз(а)
Djos пишет:
Если взять связку П1 + CК1 то получим договор по Продукту 1 у Страховой компании 1 или П1 + СК2.
Связка может быть любая, главная чтоб были 2 сущности П и СК.
Почему бы вам не внести ещё одну сущность Договор Д1? он как раз будет связывать две сущности П1+СК2
я бы посоветовал отдать ответственность за сохранение договора какой-нибудь одной сущности.
Это относилось к
Djos пишет:
Сохранение может быть как у Продукта, так и у Страховой Компании
И означало что пускай кто-нибудь один класс будет заниматься этим делом, а не оба. Т.к. это повлечет копирование кода и прочие прелести
Djos пишет:
Расчет( Calculator ) - считает стоимость договора. Расчет может полностью на нашей стороне или на стороне СК.
Сохранение( Save ) - сохраняет договор. Сохранение происходит на нашей стороне, и на стороне СК.
Составьте интерфейс этих двух классов, какие у них будут методы, что они будут принимать, что возвращать.
AmsTaFF пишет:
P.S. что продукт может сохранять договор...
Сам не помню почему такой текст получился
Djos пишет:
2. Учусь.
Тогда напишите пожалуйста с методами (открытых будет достаточно)
-----
Djos
Отправлено: 03 Декабря, 2013 - 15:40:12
Новичок
Покинул форум
Сообщений всего: 6
Дата рег-ции: Нояб. 2013
Помог: 0 раз(а)
AmsTaFF пишет:
Djos пишет:
Если взять связку П1 + CК1 то получим договор по Продукту 1 у Страховой компании 1 или П1 + СК2.
Связка может быть любая, главная чтоб были 2 сущности П и СК.
Почему бы вам не внести ещё одну сущность Договор Д1? он как раз будет связывать две сущности П1+СК2
Получается у сущность Д(Contract) будут методы Расчета и Сохранение, которые в обращаются к своим классам.
Обновил UML картинку, но мне не нравиться реализация Калькулятора и Сохранение.
AmsTaFF пишет:
Djos пишет:
Расчет( Calculator ) - считает стоимость договора. Расчет может полностью на нашей стороне или на стороне СК.
Сохранение( Save ) - сохраняет договор. Сохранение происходит на нашей стороне, и на стороне СК.
Составьте интерфейс этих двух классов, какие у них будут методы, что они будут принимать, что возвращать.
Классы будут содержать вспомогательные функции расчета/сохранение и сам расчет/сохранение. Возвращать будут тип boolean.
предложения и замечания:
1. методы лучше назовите глаголами. С Save::save() все окей, но вот с Calculator::calculator() как-то не очень, лучше назвать calculate
2. В методе Save::save() ещё понятно почему возвращается true/false, но почему у метода Calculator::calculator возвращается true/false?
Вопросы по схеме:
1. Объясните назначение Save_Product, Save_Product_Insurer, Calculator_Product, Calculator_Product_Insurer, Contrac_ProductInsurer. Если это сделано "на будущее" - уберите сейчас же, это усложняет процесс проектирования и разработки, в дальнейшем с помощью тестов, рефакторинга и времени сможете изменить абстракции.
2. Посмотрел внимательнее на схему. Где вы ещё будете использовать интерфейсы Calculator, Save? Может стоит пока убрать их из схемы, чтобы не мешались? (Как и в п.1 все это можно будет вернуть)
-----
DeepVarvar
Отправлено: 04 Декабря, 2013 - 10:41:48
Активный участник
Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008 Откуда: Альфа Центавра
Помог: 353 раз(а)
AmsTaFF пишет:
и почему не сделать что-то типа такого: $dogovor = new Dogovor($product, $company);
Сущность уже подразумевается самим автором, так что я предложил её сделать более "реальной". Никаких преград для этого на данном этапе не наблюдается + сложности лишней не вносит
Покинул форум
Сообщений всего: 6
Дата рег-ции: Нояб. 2013
Помог: 0 раз(а)
AmsTaFF пишет:
предложения и замечания:
1. методы лучше назовите глаголами. С Save::save() все окей, но вот с Calculator::calculator() как-то не очень, лучше назвать calculate
2. В методе Save::save() ещё понятно почему возвращается true/false, но почему у метода Calculator::calculator возвращается true/false?
1. Спасибо, по правил, буду знать.
2. В проекте есть класс кэш, где все храниться, поэтому и не придал значение. Будем возвращать объект CalculatorResult. На схеме нарисовал.
AmsTaFF пишет:
Вопросы по схеме:
1. Объясните назначение Save_Product, Save_Product_Insurer, Calculator_Product, Calculator_Product_Insurer, Contrac_ProductInsurer. Если это сделано "на будущее" - уберите сейчас же, это усложняет процесс проектирования и разработки, в дальнейшем с помощью тестов, рефакторинга и времени сможете изменить абстракции.
2. Посмотрел внимательнее на схему. Где вы ещё будете использовать интерфейсы Calculator, Save? Может стоит пока убрать их из схемы, чтобы не мешались? (Как и в п.1 все это можно будет вернуть)
1. П и СК может быть очень много. Отсюда и решил что будет наследование Д для каждой связки ( типа Д_ПСК ).
Я не понимаю где будет описана логика расчета для каждой связки.
2. Только в Д. Схему изменил. Прикреплено изображение (Нажмите для увеличения)
AmsTaFF
Отправлено: 04 Декабря, 2013 - 15:19:00
Гость
Покинул форум
Сообщений всего: 84
Дата рег-ции: Июнь 2013 Откуда: Россия, Москва
Помог: 1 раз(а)
Djos пишет:
П и СК может быть очень много
В каком смысле много? много разновидностей (например у них там разные расчеты цены, налогов и прочее)?
Djos пишет:
Отсюда и решил что будет наследование Д для каждой связки ( типа Д_ПСК )
Это тупиковый способ. Кол-во классов будет расти в "какой-то там" прогрессии.
Djos пишет:
Я не понимаю где будет описана логика расчета для каждой связки.
Для каждой связки чего? П и СК? какие у них будут связки? в каком смысле связки? Реальный пример в студию, можно словесно, со схемкой красивой было бы лучше, но и без неё можно разобраться.
по схеме:
почему в классе CalculatorResult 3 поля? sum, premium, go, что каждое из них означает? На основании каких и чьих данных производится расчет?
-----
Djos
Отправлено: 04 Декабря, 2013 - 16:00:18
Новичок
Покинул форум
Сообщений всего: 6
Дата рег-ции: Нояб. 2013
Помог: 0 раз(а)
AmsTaFF пишет:
Djos пишет:
П и СК может быть очень много
В каком смысле много? много разновидностей (например у них там разные расчеты цены, налогов и прочее)?
Djos пишет:
Отсюда и решил что будет наследование Д для каждой связки ( типа Д_ПСК )
Это тупиковый способ. Кол-во классов будет расти в "какой-то там" прогрессии.
Djos пишет:
Я не понимаю где будет описана логика расчета для каждой связки.
Для каждой связки чего? П и СК? какие у них будут связки? в каком смысле связки? Реальный пример в студию, можно словесно, со схемкой красивой было бы лучше, но и без неё можно разобраться.
Допустим, имеем Продукт1(П1), так же имеем Страховые компания которые его продают( СК1, CК2, СК3 ).
У нас есть 3 СК которые предлагают услуги по П1. У каждой СК своя методика расчета П1.
Расчет делается на нашей стороне или на стороне СК.
Сохранение же на нашей стороне и на стороне СК. Сохранение на нашей стороне по П одинаковое, а у СК у каждого своя и зависит от П.
Д1 = П1 + СК1, Д2 = П1 + СК2, Д3 = П1 + СК3.
AmsTaFF пишет:
по схеме:
почему в классе CalculatorResult 3 поля? sum, premium, go, что каждое из них означает? На основании каких и чьих данных производится расчет?
От калькулятора нужно получить стоимость(premium), сумму(sum) по Д. Данных которые возвращает будет калькулятор я потом допишу.
Я не могу спроектировать, как реализовать связки П и СК.
DeepVarvar
Отправлено: 05 Декабря, 2013 - 08:24:34
Активный участник
Покинул форум
Сообщений всего: 10377
Дата рег-ции: Дек. 2008 Откуда: Альфа Центавра
Помог: 353 раз(а)
AmsTaFF пишет:
Сущность уже подразумевается самим автором, так что я предложил её сделать более "реальной". Никаких преград для этого на данном этапе не наблюдается + сложности лишней не вносит
А я не только Вам, но и ему. (Добавление)
AmsTaFF пишет:
Это тупиковый способ. Кол-во классов будет расти в "какой-то там" прогрессии.
Ну вот, уже началось
-----
AmsTaFF
Отправлено: 05 Декабря, 2013 - 08:35:20
Гость
Покинул форум
Сообщений всего: 84
Дата рег-ции: Июнь 2013 Откуда: Россия, Москва
Помог: 1 раз(а)
Djos пишет:
Расчет делается на нашей стороне или на стороне СК.
Это как так на нашей или на стороне СК? Подробнее.
Djos пишет:
У каждой СК своя методика расчета П1.
т.е. для каждого товара каждая страховая компания будет иметь свой метод расчета (примерно: "кол-во П = N" * "кол-во СК = M", т.е. любое добавление товара повлечет за собой добавление M методов расчета. )? Можно ли какой-нибудь жизненный пример, чтобы лучше разуметь сие.
+ расскажите ещё подробнее что за продукты, и что за страховые компании. Сколько продуктов? Если их 3, например: автомобиль, дом, жизнь человека - то можно сделать просто, если наименований большие, то просто не получится
Djos пишет:
Сохранение же на нашей стороне и на стороне СК. Сохранение на нашей стороне по П одинаковое, а у СК у каждого своя и зависит от П.
Что ещё за разные стороны? Рассказывайте все в подробностях как у вас происходит работа (вы пишите для предприятия какого-нибудь?). Прошу рассказать, т.к. для дальнейшего проектирования текущих знаний недостаточно.
Djos пишет:
стоимость(premium), сумму(sum) по Д
как вы отличаете два слова "стоимость", и "сумма"? и почему "стоимость" названа "premium"? а не ... "cost" например?
Djos пишет:
Я не могу спроектировать, как реализовать связки П и СК.
разберемся подробнее чем они являются и попробуем что-нибудь спроектировать (Добавление)
DeepVarvar пишет:
AmsTaFF пишет:
Сущность уже подразумевается самим автором, так что я предложил её сделать более "реальной". Никаких преград для этого на данном этапе не наблюдается + сложности лишней не вносит
А я не только Вам, но и ему. (Добавление)
AmsTaFF пишет:
Это тупиковый способ. Кол-во классов будет расти в "какой-то там" прогрессии.
Ну вот, уже началось
Всмысле опять "ООП ради ООП"?
-----
Djos
Отправлено: 05 Декабря, 2013 - 11:03:35
Новичок
Покинул форум
Сообщений всего: 6
Дата рег-ции: Нояб. 2013
Помог: 0 раз(а)
AmsTaFF пишет:
Djos пишет:
Расчет делается на нашей стороне или на стороне СК.
Это как так на нашей или на стороне СК? Подробнее.
Некоторые СК представляют возможность делать расчет на их стороне.
Делаем интеграцию с нашей и с их стороны. Обмен информации происходит по протоколу SOAP.
AmsTaFF пишет:
Djos пишет:
У каждой СК своя методика расчета П1.
т.е. для каждого товара каждая страховая компания будет иметь свой метод расчета (примерно: "кол-во П = N" * "кол-во СК = M", т.е. любое добавление товара повлечет за собой добавление M методов расчета. )? Можно ли какой-нибудь жизненный пример, чтобы лучше разуметь сие.
Да, но не все СК предоставляют услуги по П.
Например из примера выше. П1 есть у СК1, СК2 и СК3. А П2 есть только у СК1 и СК3.
AmsTaFF пишет:
+ расскажите ещё подробнее что за продукты, и что за страховые компании. Сколько продуктов? Если их 3, например: автомобиль, дом, жизнь человека - то можно сделать просто, если наименований большие, то просто не получится
Продукты Каско, Осаго, Даго и т.д.. У Осаго расчет один для всех, так требует государство наше. Каско, Даго и т.д. расчет будет зависит от тарифах СК.
AmsTaFF пишет:
Djos пишет:
Сохранение же на нашей стороне и на стороне СК. Сохранение на нашей стороне по П одинаковое, а у СК у каждого своя и зависит от П.
Что ещё за разные стороны? Рассказывайте все в подробностях как у вас происходит работа (вы пишите для предприятия какого-нибудь?). Прошу рассказать, т.к. для дальнейшего проектирования текущих знаний недостаточно.
То же, делаем интеграцию по передачи данных в СК, протокол обмена данных SOAP, и сохраняем так же себя. Для статистики.
AmsTaFF пишет:
Djos пишет:
стоимость(premium), сумму(sum) по Д
как вы отличаете два слова "стоимость", и "сумма"? и почему "стоимость" названа "premium"? а не ... "cost" например?
Ошибся. Калькулятор возвращает премию и сумму. Премия - сколько нужно заплатить за договор.
DeepVarvar пишет:
Не надо плодить ООП ради ООП.
Я правильно понимаю, что вы якобы намекаете что я фигней страдаю? Можно по подробнее?
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.
Главная
Помощь
Поиск
Пользователи
Форумы портала PHP.SU » PHP » Программирование на PHP » Объектно-ориентированное программирование (Модераторы: OrmaJever, Саныч)
Описание: 2 сущности. Продукты и Страховые Компания
