Good design choice, different types of customers, from webservice
Hi, I have thoughts about good design pattern, when doing this:
You have a webservice where customers coming into your system. The customers are private ones, business ones, and big business types.
These 3 customer types has different needs, and must have different values like companyname, social security number, etc etc.
The customer also has some shared types, like customerid, created, updated, etc.
So what you want to do is to have an interface or an abstract class containing common methods for the customer, then you will create subclasses for the different types.
I was thinking about creating a factory class and pass in the customer object retreived from the webservice, and in the factory process method create objects on the different subclasses based on what kind of object you get in (private, business, etc).
So, webservice gets a private customer object, you serialize it and then you pass it into your factory class. And back you get a customer object.
Now you want to do business logic on the object, storing it to a database, etc.
So you might still have to create different scenarios based on if its customer type.
The basic idea is that you want to get the object from webservice, pass it to a factory and get back a customer object which you want to do things with.
What do you think, what is a good design solution to the problem described?
[1433 byte] By [
HTRC.SEa] at [2007-10-2 8:43:12]
To be clear "pattern" has a specific meaning. Your description is a design not a pattern.
Is the small business one never going to become a big business one?
Is a big business one never going to become a small business one?
If the answer to either is yes, then you have one entity with different attributes, not two.
I have no idea why serialization would matter in this. And your description doesn't explain that either. If you are talking about communication between different boxes then you need a communication layer (and it doesn't appear you are at the level yet where you need to decide the specifics of how that is handled.)
It is unclear why you would want a factory. But if you just want the experience then you could probably use it.
Your description isn't nearly complete enough to define how the overall system should behave which is what you seem to be also describing. You need to seperate what the system will do for how it will do it (the design.)
> I was thinking about creating a factory class and
> pass in the customer object retreived from the
> webservice, and in the factory process method create
> objects on the different subclasses based on what
> kind of object you get in (private, business, etc).
It is unusual for an Abstract Factory to perform object promotion since this puts some of your business logic into your application's framework and raises the level of coupling between your Factory and your Customer Abstractions. This is compromissing the main reason for using a factory, I would keep your object promotion seperate, and ask the factory for a specific object type.
Your also say your 'Factory ... create objects' . Noting you plural use of object. It is more usual to use the Builder pattern where the abstraction being made consists of multiple objects.
