Java 7 upgrade exam - coupling in factory design pattern

[John Stark]

Which statement is true about the factory dersign pattern?

...
C) Tight coupling exists between the factory and product class
D) Loose coupling exists between the factory and product class

Suggestes answer is D).

I would think the purpose of the factory design pattern is to transfer coupling from between the client and the product to between the factory and the product, so I would tend to answer D. Of course coupling
is a gradual thing so one could say the coupling between factory and product is still loose. Any opinions?

[Heena Agarwal]

Nice question. But where is it from. Please QuoteYourSources.

I think the coupling between the product and factory is considered relatively loose in this case because the factory only provides the ingredients to the product class and has no knowledge of the product or who is going to use the ingredients for what.

But I'm just retrofitting some logic to suit the answer. I'd also like to
know why the answer is D and not C.
Because generally the product classes give the product to the consumer class using a factory.

Doesn't the book have an explanation or something somewhere?
And I think you might want to copy the entire question here so everyone
can have the correct and complete context.

[Heena Agarwal]

But if you think of it this way--

The factory implementation will have to adhere to its interface requirements. The product class cares only about the interface. So it knows that the interface of the factory says that the factory is going to provide the ingredients. So it doesnt really care what factory implementation is passed to it. Even if the implementation of the factory changes in future, it would still adhere to what its interface promises.

On the other hand, the factory implementations couldn't care less about who is going to use the ingredients for what.

So it is still loose coupling I think. But I wish some experts out there are willing to help us on this topic so we can be sure. :-)

[Chan Ag]

John, please QuoteYourSources.

Note that this is not optional.

[John Stark]

Sorry, that is from Kaplan Selftest Software:

What statement is true about the Factory design pattern?

A) A public constructor is required for instantiation.
B) Public overloaded constructors are needed for instantiation.
C) Tight coupling exists between the factory and product class
D) Loose coupling exists between the factory and product class

I emailed them and they say

Tight coupling
still does not exist between the Factory and product classes, because the
factory does not rely on the specific implementation of the product class.
Remember, the factory class only returns an abstract reference. I
understand that some analysts might claim invoking a constructor is part of
tight coupling, but if that is the ONLY thing a class does with another
class, they are not tightly coupled. A tightly coupled class depends
entirely on the implementation of another class.

I don't think tightly coupled means a class depends entirely on the implementation of another class.
I would think how much coupling is introduced by using the constructor depends on the specific example. For example one of the java Calendar constructors is:

protected Calendar(TimeZone zone, Locale aLocale) - Constructs a calendar with the specified time zone and locale.

So using this constructor requires knowledge about how the time zone is implemented (by using the TimeZone class) and how the localization is implemented (by using the Locale class). I would consider that tight coupling. I don't think one can make the general statement 'Loose coupling exists between the Factory class and the product class'.

Another point: If invoking the constructor is not tight coupling how does the Factory design pattern then removes tight coupling (which it is supposedly doing)?

John

[Chan Ag]

I think two classes are said to be tightly coupled if a change in one of the class means that you might also need to change the other class. There are varying degrees to which a class may be coupled with another.

I think what the book is saying is right. As long as you are coding to the interface ( includes the abstract class also cause I'm referring it in the general sense here ), the product class is not tightly coupled with the factory class.

For example

public interface ShoeMakingFactory {

   public Leather createLeather();
   public Sole createSole();

}

public class NYShoeMakingFactory implements ShoeMakingFactory {

   public Leather createLeather()  
   {
       return new NYStyleShoeLeather();
   }
   public Sole createSole()
   {
        return new NYStyleShoeSole();
   }

}

public class TexasShoeMakingFactory implements ShoeMakingFactory {

   public Leather createLeather()  
   {
       return new TexasStyleShoeLeather();
   }
   public Sole createSole()
   {
        return new TexasStyleShoeSole();
   }

}

public abstract class Shoe {
   Leather leather;
   Sole sole;
  
   abstract void createShoe();
   void boxShoe() 
   {
       System.out.println("Boxing the shoe");
   }

   void polishShoe() 
   {
       System.out.println("Polishing the shoe");
   }
}

public class FormalShoe extends Shoe {
   ShoeMakingFactory factory;

   public FormalShoe(ShoeMakingFactory factory) {
      this.factory = factory;
   }
  
   void createShoe() 
   {
       System.out.println("Creating a formal shoe");
       leather = factory.createLeather();
       sole = factory.createSole();
       
   }

  
}

public class SportsShoe extends Shoe {
   ShoeMakingFactory factory;

   public FormalShoe(ShoeMakingFactory factory) {
      this.factory = factory;
   }
  
   void createShoe() 
   {
       System.out.println("Creating a sports shoe");
       leather = factory.createLeather();
       sole = factory.createSole();
       
   }

   
}

public abstract class ShoeStore {

   public Shoe getShoe(String type) 
   {
        Shoe shoe;
        shoe = createShoe(type);
        shoe.polishShoe();
        shoe.boxShoe();
        return Shoe;
   }
   protected abstract Shoe createShoe(String type );
}

public class NYShoeStore extends ShoeStore  {

   protected Shoe createShoe( String type )  
   {
        Shoe shoe = null;
        ShoeMakingFactory factory = new NYShoeMakingFactory();
       
        if ( type.equals("sports")) 
        {
             shoe = new SportsShoe(factory);
        }
        else if ( type.equals("formal"))
       {
            shoe = new FormalShoe(factory);
       }
       return shoe == null ? new SportsShoe(factory) : shoe;
   }
}

In the above example, the SportsShoe and FormalShoe only take a ShoeMakingFactory type. You could pass it any implementation of the factory. All implementations would implement createLeather and createSole methods and these methods return a Leather and a Sole respectively. The factory implementation would return a specific Leather and a specific Sole but in your product class ( SportsShoe/LeatherShoe), the constructor takes a ShoeMakingFactory ( it is not tied to a specific shoe making factory ). Hence the product class does not need to know the internals of the factory implementation and any changes in the factory implementation would not bring about a change in the specific shoe implementation.

For example one of the java Calendar constructors is:

protected Calendar(TimeZone zone, Locale aLocale) - Constructs a calendar with the specified time zone and locale.

So using this constructor requires knowledge about how the time zone is implemented (by using the TimeZone class) and how the localization is implemented (by using the Locale class). I would consider that tight coupling.

I don't think you need to know the internal details of how a specific TimeZone or a Locale is implemented. As long as you are passing it a TimeZone that is compatible with the Locale, you are good.

So if we consider the various compatible combinations of Locale and TimeZone as one case each, you still don't have to know the internal details of a TimeZone or a Locale implementation. You can change one without changing the other as long as you adhere to its interface requirements.

Note : I've referred to the Pizza Factory example in the Head First Design Patterns book to create a short ShoeMakingFactory example in this case.

[John Stark]

I am getting confused now. My understanding is that we are talking about the coupling between the product class and Factory. As I understand it the product is the SportsShoe and FormalShoe and the Factory is for example the TexasShoeMakingFactory. The factory does:

return new TexasStyleShoeLeather();  

and therefore has to deal with a concrete class.

I don't think you need to know the internal details of how a specific TimeZone or a Locale is implemented. As long as you are passing it a TimeZone that is compatible with the Locale, you are good.

Sorry what I meant was using the constructor requires knowledge about how the time zone is implemented in terms of what class is being used to represent a time zone. So instead of java.util.TimeZone some other class like com.mytimeutilities.MyTimeZone could be uses. Instead of using java.util.Locale one could use com.mylocalizationtools.MyLocaleRepresentation.

[Chan Ag]

John Stark wrote:I am getting confused now. My understanding is that we are talking about the coupling between the product class and Factory. As I understand it the product is the SportsShoe and FormalShoe and the Factory is for example the TexasShoeMakingFactory. The factory does:

return new TexasStyleShoeLeather();  

and therefore has to deal with a concrete class.

Sorry I didn't refer to Leather and Sole as products in my previous post. But yes, they are the products that the factory provides. So even though the factory returns a specific Leather, you can change TexasStyleShoeLeather class and this will not affect the TexasShoeMakingFactory implementation. This is because the TexasStyleShoeLeather is- a Leather. And the TexasShoeMakingFactory is only supposed to provide a Leather and TexasStyleShoeLeather will continue to be a Leather even though you change its internal implementation. You can have it as a double layer or a triple layer leather or soft leather or ( whatever types there are ) anything - it is still a Leather. So even though the factory implementation returns a specific Leather, these two classes are not tightly coupled with each other. You can change the product class without changing the factory class and the vice versa.

Sorry, I cannot take the other part of your question right now. I may have to look at some implementation details for that but I'm guessing if you understand part 1, you may not need the answer of part 2.

[John Stark]

Yes, if you change the type of object returned by the factory, let's say to LuxuriousTexasStyleShoeLeather then you don't have to change the client's implementation as LuxuriousTexasStyleShoeLeather still is-a Leather. However, you have to change the implementation of the Factory as now you have to do

return new LuxuriousTexasStyleShoeLeather();

When you invoke the constructor you exactly need to know what kind of object to instantiate.

[Chan Ag]

John Stark wrote:Yes, if you change the type of object returned by the factory, let's say to LuxuriousTexasStyleShoeLeather then you don't have to change the client's implementation as LuxuriousTexasStyleShoeLeather still is-a Leather. However, you have to change the implementation of the Factory as now you have to do

return new LuxuriousTexasStyleShoeLeather();

When you invoke the constructor you exactly need to know what kind of object to instantiate.

Right. But that is the only place where you are going to have to make a code change, i.e you will now have the factory return LuxuriousTexasStyleShoeLeather. LuxuriousTexasStyleShoeLeather however is a different Leather so the coupling relation of TexasStyleShoeLeather with the factory does not apply now.