Last post Aug 06, 2013 03:34 AM by DMW
Aug 04, 2013 05:42 PM|Xequence|LINK
I have 2 links with some good details as to use abstract factory, the issue is I am not sure which ons is better. Anyone know the pitfalls of anstract factory with these?
Aug 05, 2013 02:29 AM|Ringoo|LINK
I have 2 links with some good details as to use abstract factory, the issue is I am not sure which ons is better.
Please describe your problem domain, the context in which you are looking to apply the abstract factory.
Aug 05, 2013 11:35 PM|Xequence|LINK
Why do each example generate entire different dependancy graph? Easy example is paste the code from each link, and you will get a very diffrent graph.
Aug 06, 2013 03:34 AM|DMW|LINK
That's because the first of the two links, which talks about book stores, is fundamentally flawed.
In the bookstore example, you'll notice that both BookstoreA and BookstoreB have identical implementations. This is rubbish. The author of the first article implies - through the comments in the code - that the purpose of the abstract factory is to enable
you to change the internal implementation of the factory and not change the client code. This is true for all factory-like methods, and is not the purpose of abstract factory.
Abstract Factory is all about having factories that make RELATED items, whose concrete types depend on the type of the concrete factory, so that by changing the factory you can change a whole family of objects that are used by client code without changing
that client code.
A much better example is that implemented by the DbProviderFactory derived-classes in ADO.NET, where the SqlClientFactory returns SqlCommand, SqlConnection, SqlParameter objects from the relevant CreateXXX methods, and where the OleDBFactory returns OleDbCommand,
OleDbConnection, OleDbParameter objects.
DbProviderFactory factory = // code to get a provider factory omitted;
DbCommand cmd = fact.CreateCommand();
DbConnection conn = fact.CreateConnection();
Now, depending on the concrete type of factory, you will get different concrete types of cmd and conn. However, the client code can program against those concrete types, albeit constrained to the features of the base DbCommand and DbConnection classes.
That is what abstract factory is all about.
As an aside, it should be noted that whilst in theory you could shift your entire database technology without changing any client code because of the way the managed providers implement abstract factory, in the real world this is in all likelihood a fantasy.