Home > Patterns and Practices > Design Model – Static Model

Design Model – Static Model

Till now we were in the problem domain, now we will get into the solution domain by deciding on the Design Model. The domain model is good start to identify classes in your design model. Before we get into the solution, there were a couple of questions about the domain in my mind. Since we have a cross-functional team we don’t have a problem. We will ask the customer (who is working part-time with us to get this implementation rolling). The questions and the customer response,
 
  • Do you sell only books?
    Well, we sell only books as of now. We might sell Stationaries, Music Albums, Movies in the near future. But we want the current solution to work for Books alone, make it easier to include Stationaries, Music Albums, Movies later.
  • Which parts of the system do you think will change often?
    Discount Policy is the one which changes most.
    Taxes and Duties are something which change too, but then they may not change as often as the discount policy.
The main responsibilities are applying discounts, calculating sales taxes, calculating VAT and calculating import duty. Let us take one by one and see where the resposibility can be assigned to.

Applying Discount:
To apply discount we need the data elements total price, price of each book, its category and the number of books. The total price is available with the Sale class. The price of each book and its category are available with the Book class. The quantity is available in the SalesLineItem class. So the responsibility must be realized by collaboration among Sale, SalesLineItem and Book classes. The discount percentage for for each slab will be determined by the Sale class and given to the book class which applies the discount based on the price of the Book and its category. This will be multipied by the Quantity in the SalesLineItem class. The Sales class will then sum it up for all the SalesLineItems.

Calculating Sales Tax, Import Duty:
To calculate Sales Tax, import duty we need the data elements price of each book, is the book imported, the tax percentage and the number of books. The price of each book and if it is imported are available with the Book class. The quantity is available in the SalesLineItem class. The book class gives  tax for each book which is mutiplied by the qunatity in the SalesLineItem class. The Sales class will then sum it up for all the SalesLineItems. So the responsibility must be realized by collaboration among Sale, SalesLineItem and Book classes.

Calculating VAT:
To calculate VAT we need the data elements total price and VAT%. The Sales class has the total price and can provide the VAT% as well. So the responsibility can be realized by Sales class alone.

What we did just now is called the Information Expert, responsibility assignement pattern. That is assign the responsibility to the class which has the information to realize the responsibility. This keeps the coupling low.

Since we might sell products other than books in the near future, it will be better if we program the clients to an abstraction rather than the concrete implementation Book. We’ll introduce another class called Product, which the Book class will inherit from. Book is a product, Stationery is a product etc. Another good design principle is to encapsulate what varies into a separate class. Good candidates here are Tax calculation and Discount calculation.

We can program to a TaxCalulator interface ITaxCalculator rather than to the implementation, IDiscountPolicy follows in the same line. We can read the data like the percentages of discounts and the ranges for which they are applicable, percentage of sales tax, percentage of import duty etc from a file. Again programming to an interface and keeping this a black box will help to move to a different storage provider later. This calls for IRuleDataProvider and FileRuleDataProvider, NullRuleDataProvider (which can be used for testing) types. The RuleDataProvider in the strictest sense violates a responsibility assignment pattern, High cohesion. The Discount Rules data and the Tax rule data are grouped together reducing coupling. But its ok I guess, we need to move on. Enough said let us see how this looks:


The static model of the system is close to done. Lets us see how the dynamic model will look like in the next post.

Advertisements
  1. Prakash
    October 6, 2006 at 4:24 am

    The image is not very clear. it will be really helpful if you can make it readable.

  2. Sendhil Kumar
    October 6, 2006 at 5:33 am

    I know, I am looking for hosting provider / I am also thinking of blogger to host the images. Live Spaces scales down the image…

  3. ~ Numb ~
    July 24, 2007 at 6:08 pm

    Hi Sendil,
     
    It would be great if you can send across the valid image on kunal989@hotmail.com
     
    BTW, thanks alot for blogging across all the above articles, they are easy to understand yet informative.
     
    Kunal

  1. November 19, 2010 at 10:59 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: