abstract factory RRS feed

All replies

  • User-1067017023 posted

    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.

    Monday, August 5, 2013 2:29 AM
  • User1080785583 posted

    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.

    abstract factory

    Monday, August 5, 2013 11:35 PM
  • User1109032460 posted

    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.

    Consider this:

    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.

    Tuesday, August 6, 2013 3:34 AM