Enthuware

this is not complete answer, why DAO and composite is not program to interface ? even composite pattern encourage program to interface.

The question is not which pattern encourages "program to an interface" principle.
This concept is not integral to DAO and composite patterns.

I have read in book and it's part of DAO and Composite.They provide a common interface for client so client doesn't need to think about implementation class detail.In composite pattern component is a interface which is used by client.client doesnt need to think about leaf class or composite class.In DAO pattern client doesnt need to think about data source because DAO provides a interface.

Yes, the main purpose of DAO is to shield the db access. You can do it without using interfaces also and it would still be DAO. If you provide an interface to DAO, you are using the "program to an interface" principle also but that is not required for DAO. Same for composite.

Factory pattern however cannot be done without interfaces.

Even in factory pattern interface is not necessary, you can do thru abstract class also.

Even with abstract class, you are relying the the "program to an interface" principle in the sense that you are using the interface (conceptually, i.e.) provided by the abstract class. That is the key point here. Program to an interface doesn't necessarily mean java interface definition but the concept that that implementation can change as long as the conceptual interface remains the same. Whether you do it with abstract class or interface is a language specific thing.

You said

Yes, the main purpose of DAO is to shield the db access. You can do it without using interfaces also and it would still be DAO.

Please tell me without interface how can i do this for DAO?

if your answer is abstract class then as you said below,DAO also ultimately relying on interface.

Even with abstract class, you are relying the the "program to an interface" principle in the sense that you are using the interface (conceptually, i.e.) provided by the abstract class.

your explanation is like round robin.

No, an interface is not critical for DAO. You can have a concrete class that has methods to do persistence. The user of the class can just do a new on that concrete class. Again, creating an interface for the DAO and then creating a class that implements that interface would be better, but not related to DAO as such. That is exactly what Factory pattern is.

You are confusing a combination of factory pattern + DAO with DAO.

You may want to take a look here: http://www.corej2eepatterns.com/Pattern ... Object.htm

"Since the return type of the factory method is an interface"

Is that always true? I.e. is that a definite requirement of the Factory pattern? I thought the Factory pattern was everywhere and that it just meant you get an X without having to invoke X's constructor eg

http://docs.oracle.com/javase/7/docs/ap ... teInstance()

DF isn't an interface; it's a class. DF's getXXX methods are supposed to be Factory methods aren't they?
Cheers

It is a just a pattern, not a hard and fast rule. So variations are possible. But conceptually, yes, the return type of the method should be an interface and not a class.

HTH,
Paul.

The Factory pattern cannot be created or applied without interfaces.

ewebxml wrote:The Factory pattern cannot be created or applied without interfaces.

That is not completely true. Factory pattern can be used with abstract classes also. In fact, it is used with regular classes as well in many cases. For example, in Java 8, LocalDate/LocalDateTime classes have several instance creator methods. These are basically static factory methods.
But yes, the classic factory pattern involves interfaces.

HTH,
Paul.