Patterns mock question?

[Amandeep Singh]

You are creating a utility billing system that you want to sell to as many different utility companies as possible. You want each company to have their own billing module, reporting module, and historical reporting module that are specific to each utility and each module in the system is related to one another, but you do not want to have lots of conditional statements in your code.


Which is the correct design pattern to avoid having lots of conditional statements?

A. Builder
B. Factory Method
C. Singleton
D. Abstract Factory
E. Prototype
F. Facade

Option D is correct.
Option A is incorrect because Builder separates the construction of a complex object from its representation so that the same construction process can create different representations.
Option B is a similar pattern, but it is incorrect because we want families of related objects that are related to each other.
Option C is incorrect because we do not want to control the number of instances.
Option E is incorrect because it is used when the inherent cost of creating a new object in the standard way (e.g., using the 'new' keyword) is prohibitively expensive for a given application
Option F is incorrect because Facade creates a simplified interface of an existing interface

I selected A. Since the utility company want to sell to many companies. So it is obvious the same construction process can create different representations which means different modules for each company. So this should be correct answer.
Do you know why D is correct?

[Jeanne Boyarsky]

Where did this question come from?

[Amandeep Singh]

This is from Sun's Epractice.

[Amandeep Singh]

Any SCEA expert?

[Ranganathan Kaliyur Mannar]

At first thought I thought about option A or B.
But option D seems to be the correct one. This is because:
Key point here is that, the company wants to sell multiple modules - and each of these can be customized independent of each other. If you are just customizing one module, builder or factory method will do it. So, when you are customizing multiple modules, what you need is simply a factory of factories - which is what Abstract Factory is.

[Amandeep Singh]

Since the question says which is the design pattern to avoid having lots of conditional statements, then Builder Pattern makes the sense, I wasn't knowing about this earlier.

[Nimit Shah]

Without looking at the answers I was thinking about strategy pattern first, which is not among the possible answers expected.
Among the given choices D is correct as any application which needs to use other systems such as report, billing will have to do "if xcompany then XReport."

This will be solved by AbstractFactory

[Eduardo Mineo]

Amandeep Singh wrote:Since the question says which is the design pattern to avoid having lots of conditional statements, then Builder Pattern makes the sense, I wasn't knowing about this earlier.

Hi Amandeep. I don't see builder as a mechanism to avoid if-else statements. In order to avoid it, you must use polymorphism. Since the problem is about avoiding if-else to instantiate modules (or classes if you please), the only right answer is Abstract Factory. Lasse Koskela, a colleague from Java Ranch, wrote a very good book about Test-driven Development. One of the refactoring he did was a removal of if-else statements for instantiate objects in a parser example. He was creating a parser of a template where there would be variables in the form of ${name}. So, the whole idea was to break the template into segments of two types: PlainText or Variable. He says:

An essential part of our grand plan of avoiding ugly if-else blocks by means of polymorphism is to embed the varying functionality into the different implementations of the polymorphic concept of Segment objects. (Test Driven: TDD and Acceptance TDD for Java Developers, p.123)

--eduardo

[Amandeep Singh]

Thanks guys got it vaguely.