What design pattern is best for the following scenario?
As you can see from above, all 3 basically contain the same information, altough this doesn't have to be the case (some can contain more or less information), but it is structured different, so the way I access it is different. What is the best approach to take so I can write the most minimum code, but be able to adapt to new rental agencies that come along with a different structure?
Right now, I am doing something like this:
In the above, the classes contain the same methods, but the way they are implemented is different. There are some methods, properties, etc that are in some classes, but not in others. Are interfaces the best way to approach this? If so, should everything be made an interface?
In the XML samples above, the data was the same, but the format was different but what about the scenario where not only is the format different, but the data is different as well?
Xaisoft S, Jul 17, 2012
My Understanding -there are three supplier with whom we have to xml interfacing to perform some operations. such as car rental website does same thing with different car suppliers for book/cancel/availability etc...
Factory Method design pattern to create instance of supplier
Facade can also be used.
Dharmesh Parekh, Nov 20, 2016
How about the Strategy and Factory patterns.
See example, below. I left out error checking for clarity.
How you want to pass around the derived classes (Agency1, Agency2, ... the data) is up to you. I find this way to be the easiest, but will vary depending on your app.
You could also add a property to set the behavior and pass in the required data in some other fashion.
I think you'll get the idea, though.
And, of course, the "swtich" statement in the main controller is not ideal. That too could be put into a factory.
I just wanted to illustrate and suggest the Strategy pattern without writing an entire app.
Hope this helps,
Michael Lopez, Jul 20, 2012
Just sharing my thoughts here, may need to fine tune - as I have not tried this solution yet (may be I can get back)
Two key aspects here:
1) If you are going to process all of your Agency's XMLs (whatever may their format) into a common format - Adapter Pattern.
2) If you want to have classes or entities into your system, to represent each Agency XML , then you would need - Factory Pattern
For case 1 , you can read an agency XML into an XML object and then "adapt" its contents to your target class - Say Agency Mapper
Whenever a new schema comes into scope, you need to adapt it to the AgencyMapper class.
For case 2:
You have build Factory pattern, that each Agency XML becomes a concrete product. I hope you would not need another layer of abstraction here. In this case whenever a new (type of) Agency comes in you may need to add a new COncrete class. I think IOC containers will help here to avoid adding code into the system.
1) Have multiple Schema files each representing an Agency XML, (saved to your working directory) like Agency1.XSD..etc.,
2) When you start processing, your system should read an Agency XML file and try validating it against the existing schemas.
3) when it matches with one of the Schemas , your code should assign a type (enum?) like Agency1 or AgencyTwo etc.,
4) Pass the type Factory class that it creates the corresponding Agency Class
5) Have a mapper method in each class that it reads XML and initializes corresponding members ( I maintain the class name and XML attribute name to be the same, that I can use reflection to loop through and assign at runtime)
6) then call Submit rental()
To answer Abstract Factory or interface, if you want to enforce things against unrelated entities - interface
To enfore and enable versioning across related entities - abstract classes
Thanks and Regards
Tarriq Ferrose Khan, Jul 19, 2012