design problem
in [OOP]
|
Prev: help me.
Next: Factory pattern
From: Sasa on 4 Oct 2006 12:45 Hi everyone, Consider following design: Employee -> IPaymentStrategy With following characteristics: - payment strategies are Salaried and HourlyPayed - each concrete strategy holds strategy relevant data (Salary or Hours and Wage respectively) - the Employee has CalculatePay() method which delegates to the PaymentStrategy Let's say that I have some abstract storage. The specific implementation fetches the Employee from the storage, and the factory creates the object, with appropriate strategy. Now, the GUI must display appropriate editing form, with either Salary or Hours and Wage UI elements displayed, depending on the type of payment strategy. How can the GUI do it without querying the Employee about it's payment strategy? Sasa
From: Sasa on 4 Oct 2006 12:50 Sasa wrote: > Hi everyone, > > Consider following design: > > Employee -> IPaymentStrategy > > With following characteristics: > - payment strategies are Salaried and HourlyPayed > - each concrete strategy holds strategy relevant data (Salary or Hours > and Wage respectively) > - the Employee has CalculatePay() method which delegates to the > PaymentStrategy > > Let's say that I have some abstract storage. The specific implementation > fetches the Employee from the storage, and the factory creates the > object, with appropriate strategy. > > Now, the GUI must display appropriate editing form, with either Salary > or Hours and Wage UI elements displayed, depending on the type of > payment strategy. > > How can the GUI do it without querying the Employee about it's payment > strategy? > > Sasa The minute I posted this, double dispatch and visitor came to mind. Are there any other ways? Sasa
From: Sergey Alpaev on 5 Oct 2006 02:30 Hi, Sasa If there is payment strategy why not to have PaymentViewingStrategy? :-) The same (or different one which is better) factory would allow creating PaymentStrategyView which would be an abstract way of viewing strategies and there would be SalariedStrategyView and HourlyPayedStrategyView. Disadvantages: 1. One inconvenience is that these views will need to know about strategy they display but abstract factory which creates them will be parameterized by abstract strategy. So the factory will need to cast abstract strategy to concrete class to pass to strategy view constructor. 2. It is possible that someone will mistakenly attempt to show SalariedStrategy with HourlyPayedStrategyView by passing result of SalariedStrategyFactory to HourlyStrategyView and cast will fail. However this is simple configuration mistake which can be caught early or eliminated by using single identifier of strategy type (string like "hourlyPaymentStrategy") which is passed to both factories. One factory will treat is as instruction to create strategy and another as instruction to create strategy view. Advantages: you can add new strategies and strategy views without touching the rest and this was the goal if I understand it right. To me visitor or double dispatch do not help here but if anyone shows an example I would appreciate. "Sasa" <sasa555(a)gmail.com> wrote in message news:eg0ooo$380$1(a)sunce.iskon.hr... > Sasa wrote: >> Hi everyone, >> >> Consider following design: >> >> Employee -> IPaymentStrategy >> >> With following characteristics: >> - payment strategies are Salaried and HourlyPayed >> - each concrete strategy holds strategy relevant data (Salary or Hours >> and Wage respectively) >> - the Employee has CalculatePay() method which delegates to the >> PaymentStrategy >> >> Let's say that I have some abstract storage. The specific implementation >> fetches the Employee from the storage, and the factory creates the >> object, with appropriate strategy. >> >> Now, the GUI must display appropriate editing form, with either Salary or >> Hours and Wage UI elements displayed, depending on the type of payment >> strategy. >> >> How can the GUI do it without querying the Employee about it's payment >> strategy? >> >> Sasa > > The minute I posted this, double dispatch and visitor came to mind. > Are there any other ways? > > Sasa
From: raxitsheth2000 on 5 Oct 2006 03:05 > Now, the GUI must display appropriate editing form, with either Salary > or Hours and Wage UI elements displayed, depending on the type of > payment strategy. So GUI depend on PaymentStrategy, the one easiest things come to mind is make the IPaymentStrategy responsible for rendering GUI, Oh, PaymentStrategy is BusinessLogic and i am trying to couple BUI with BL , Any Idea by which using type of PaymentStrategy you can get some object(of appropriate type) who is responsible for generating GUI.... --raxit
From: Sasa on 5 Oct 2006 07:48
"Sergey Alpaev" <s_alpaev(a)mail.ru> wrote in message news:eg28qn$ert$1(a)news.isd.dp.ua... > Hi, Sasa > > If there is payment strategy why not to have PaymentViewingStrategy? :-) > The same (or different one which is better) factory would allow creating > PaymentStrategyView which would be an abstract way of viewing strategies > and there would be SalariedStrategyView and HourlyPayedStrategyView. > Disadvantages: > 1. One inconvenience is that these views will need to know about strategy > they display but abstract factory which creates them will be parameterized > by abstract strategy. So the factory will need to cast abstract strategy > to concrete class to pass to strategy view constructor. > 2. It is possible that someone will mistakenly attempt to show > SalariedStrategy with HourlyPayedStrategyView by passing result of > SalariedStrategyFactory to HourlyStrategyView and cast will fail. However > this is simple configuration mistake which can be caught early or > eliminated by using single identifier of strategy type (string like > "hourlyPaymentStrategy") which is passed to both factories. One factory > will treat is as instruction to create strategy and another as instruction > to create strategy view. > > Advantages: > you can add new strategies and strategy views without touching the rest > and this was the goal if I understand it right. What I want is completely encapsulate the notion, that PaymentStrategy Exists. Hence: the Employee object has CalculatePay (internally delegates to strategy). The outer user is not aware that strategy pattern is being used. I want to be able to edit each specific employee, and show appropriate GUI elements depending on Employee's pay model. I want to avoid querying Employee about its payment model (like, are you Salaried, HourlyPayed. ...) > To me visitor or double dispatch do not help here but if anyone shows an > example I would appreciate. I'll write pseudo C#, if it's not language you're comfortable with, let me know: interface IPayDataCollector { void CollectSalaryData(decimal salaryData); void CollectHourlyPayedData(double hours, decimal hourlyWage); } interface IPaymentStrategy { decimal CalculatePay(); void CollectPayData(IPayDataCollector payDataCollector); } class SalariedPaymentStrategy { decimal salaryData; public void CollectPayData(IPayDataCollector payDataCollector) { payDataCollector->CollectSalaryData(salaryData); } } class HourlyPaymentStrategy { double hours; decimal hourlyWage; public void CollectPayData(IPayDataCollector payDataCollector) { payDataCollector->CollectHourlyPayedData(hours, hourlyWage); } } class Employee { private IPaymentStrategy strategy; void CollectPayData(IPayDataCollector payDataCollector) { strategy->CollectPayData(payDataCollector); } } The view could implement IPayDataCollector. What it would do is simply following: class EmployeePayDataForm : Form, IPayDataCollector { public void CollectSalaryData(decimal salaryData) { // show GUI element for salaryData and populate it } public void CollectHourlyPayedData(double hours, decimal hourlyWage) { // show GUI elements for hours/hourlyWage and populate them } public void SetEmployee(Employee employee) { // clear and hide pay related GUI elements employee->CollectPayData(this); } } Hope the idea is clear. There might be typo or two, I wrote this in my news reader editor. Sasa |