Hello Friends I was wonering do we need to implement any design pattern for Pricing mechnaism ? Although the CEO says the pricing is pretty simple , but the designer has to consider the future scenarios i.e " Open for Extension" design principle. There might be disocunts available on some seasons or to some card holders , so I think we should consider this while designing. ALso in the use case , Pay for Itinerary it is written that 'customers select award travel'. Does this mean any discount on ticktes price for just adding the points based on itinerary ? Vinay
Vinays, I prefer to keep the design simple and delay gratification for additonal features/enhancements which may increase the complication of the application and make the five seconds response time requirement difficult to meet.
That's the amazing thing nowadays, especially with the internet - we build applications that by definitions evolve. Try to speak with an architect (the one that designs houses ) and let him know that in a year or two you would like to make major changes but you have no clue what they are going to be. Ask him please to design accordingly. I wonder what type of look you are going to get. The major tool/practice which we have nowadays to deal with this type of requirement is refactoring. How effective it is? � go figure.
BTW, let's face it. writing software against extremely well defined requirements is not as easy task, especially on the internet which is packed with all the new, changing and semi-baked technologies.
-- Dan [ July 11, 2005: Message edited by: Dan Drillich ]
William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.