About Question enthuware.ocpjp.v7.2.1123 and enthuware.ocpjp.v7.2.1659 :

[Ciprian Mihalache]

I noticed I often give wrong aswers when I have to decide between DAO and Factory.
From what I saw, there are 4 questions that, basically ask the same thing: What design pattern(s) should I use, that, in case I change the database to have minimum impact on the application. These questions are:

• enthuware.ocpjp.v7.2.1123 (this one)

• enthuware.ocpjp.v7.2.1623

• enthuware.ocpjp.v7.2.1624

• enthuware.ocpjp.v7.2.1659

For the question #1624 the answer is obvious because it asks for 2 design patterns.
The question #1623 is also easy because it basically says thay we have multiple DAOs and asks how do we expose them to the application. So "Factory" is a natural answer.

But the questions #1123 and #1659 are really hard for me. For sure there is a subtle difference that I am unable to see. Can you please spot that difference between #1624 (which uses both design patterns), #1123 (that has not the Factory as a valid answer) and #1659 (that has not the DAO as valid answer)

Thank you.

[admin]

#1624: your data access logic is separated from the business logic and that the application code is not aware of the database used

You need two things here - separate data access logic from business logic. This implies you need DAO.
application code is not aware of the DB used : You need factory to get the DAO implementation.


#1123: decouple business logic from data access logic and adapt the data resource being accessed such that it can be changed easily without any impact to your business logic code.
You just need DAO because you only need to separate data access logic from business logic. There is no requirement that the application logic has to be unaware of the DB used.


#1659: isolate the business logic of your application from a change in the implementation strategy of the data access routines

The question says that you already have routines that return dummy data and you expect them to be replaced with routines with routines that return real data. So all you now need is the Factory pattern to get the appropriate DAO implementation.


But I do realize that it is not a clear distinction because usually both the patterns are used together. I would definitely select both of them in these questions. However, in the exam, you will find questions that require you to make that distinction based on similar vague statements. Our objective with these questions is to make you aware of such questions. It would be easy for us to change the question and select both the options as the right option but then that will rob the users of a chance to apply their mind in this kind of situation.

So it is good that you raised this point and I hope other users will also stumble upon this thread and make their own judgement regarding what to do in such kind of questions.

-Paul.

[Mark7777]

Really, really dumb question, but I'm still confused. By business logic do you mean the client that uses CRUD to access the database? And what do you call the objects (say, instances of Book) that go into the database? (or referenced therein). The language in the four questions perplexes me. Book objects have business logic, don't they, as well as the application client that does the work of CRUDing those objects in the db? Does this make any sense? Thanks.

m.

[admin]

Business logic means the logic that drives the business of the application. For example, a library application may maintain a "number of copies" of any book and whenever anyone checks out a book, this number is updated. This is business logic. The actual saving and updating of the data in database is not business logic because this logic is same for all applications. That is why, tools such as hibernate, JDO, ibatis are able to automate pure CRUD operations. They don't care about the business logic of the application. They just focus on saving and loading the fields from the database to/from the object. There is no intelligence in saving and loading data from a business perspective.

The save and load methods of your Book class should not contain code other than setting and returning the instance fields of the Book object. If, otoh, the save and load methods of the Book class contain any special logic that is unique to the way you conduct business then that is business logic. For example, if while loading the data from the database, your load method formats the data using some custom logic, then that is business logic. You cannot expect any database persistence tool to know about your business logic.

HTH,
Paul.

[Mark7777]

Very good. Thank you.

m.