Ein DAO Pattern ist ein DAO Pattern. Das Pattern selbst ist sehr klein. Also klein, in dem es eigentlich nur die Vorgabe macht, dass man Datenzugriffslogik für eine Klasse (z.B. User) in ein separates Data Access Object verlegen sollte, z.B. um die Logik in User nicht von der konkreten Persistenzimplementierung abhängig zu machen.
Okay, nun hast du also zwei Objekt um mit einem Benutzer zu arbeiten. Den User selbst und sein DAO. Jetzt stellt sich noch die Frage wie der Code aussieht, der damit arbeiten soll. Und da kommen dann die Themen Factory und Strategy ins Spiel.
Factory braucht man nicht unbedingt, wenn sich der Client die DAO Instanz z.B. per Dependency Injection geben lässt. Ansonsten lässt man sich von der Factory die Instanzen erzeugen.
Um nun Abhängigkeiten zu minimieren und Austauschbarkeit zu gewährleisten, führt man ein Interface für das DAO ein -> Strategy Pattern. Dadurch ist der Client nur noch vom DAO Interface abhängig und kann v.A. leichter getestet werden. Recht theoretischer Vorteil ist auch, dass man eine JDBC DAO Implementierung gegen eine mit Hibernate austauschen könnte oder von MySQL auf Oracle wechselt oder oder oder. Tut niemand, das Austauschen gegen ein Mock zum Testen ist dagegen sehr viel verbreiteter.
Gruß
Ollie