This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Patterns mock question? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Patterns mock question?" Watch "Patterns mock question?" New topic
Author

Patterns mock question?

Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
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?


SCJP 1.4, SCWCD 5, SCBCD 5, OCPJWSD 5,SCEA-1, Started Assignment Part 2
My blog- http://rkydesigns.blogspot.com
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30789
    
157

Where did this question come from?


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
This is from Sun's Epractice.
Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
Any SCEA expert?
Ranganathan Kaliyur Mannar
Bartender

Joined: Oct 16, 2003
Posts: 1085
    
  10

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.


Ranga.
SCJP 1.4, OCMJEA/SCEA 5.0.
Amandeep Singh
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
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
Ranch Hand

Joined: Jul 02, 2007
Posts: 53
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
Ranch Hand

Joined: Sep 26, 2011
Posts: 63

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
Ranch Hand

Joined: Jul 17, 2008
Posts: 844
Thanks guys got it vaguely.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Patterns mock question?