artima - Article Discussion

Article Discussion

Design Principles from Design Patterns

View Flat

Summary: In this interview, Erich Gamma, co-author of the landmark book, Design Patterns, talks with Bill Venners about two design principles: program to an interface, not an implementation, and favor object composition over class inheritance.

17 posts.

The ability to add new comments in this discussion is temporarily disabled.

Most recent reply: June 4, 2010 5:17 AM by Vincent

Bill

Posts: 409 / Nickname: bv / Registered: January 17, 2002 4:28 PM

Design Principles from Design Patterns

June 6, 2005 7:00 PM

In this interview, Erich Gamma, co-author of the landmark book, Design Patterns, talks with Bill Venners about two design principles: program to an interface, not an implementation; and favor object composition over class inheritance.

http://www.artima.com/lejava/articles/designprinciples.html

What do you think of Erich's ideas?

bug

Posts: 5 / Nickname: bugmenot / Registered: July 12, 2004 11:21 PM

Re: Design Principles from Design Patterns

June 8, 2005 5:48 AM

I always heard about the "comkposition vs inheritance".
What I miss is the parte about why w should be suing inheritance.
Are SupesrStar Developers suggest that languages should give explicit support for not abusing inheritance (i.e. strict subtyping, or only non conforming inheritance) ?

Since I'm composing and never inheriting, does'nt OO slip into component-only programming (think of NesC) ?

Cedric

Posts: 7 / Nickname: cbeust / Registered: February 27, 2004 3:21 AM

Re: Design Principles from Design Patterns

June 10, 2005 5:59 AM

A few comments and thoughts here:

http://beust.com/weblog/archives/000291.html

--
Cedric

nes

Posts: 9 / Nickname: nn / Registered: July 11, 2004 6:19 AM

Re: Design Principles from Design Patterns

June 7, 2005 5:25 AM

Programming consists of this:

1. Divide your problem in smaller parts that you can name and are easy to understand. But make too many and you loose track of them.

2. Add more indirection to make your system more flexible to change. But add too much and you will get lost in the maze.

3. Only expose the minimal protocol (interface). Make it too big and you will have the pain of supporting it. Make it too small and its usefullness is restricted.

Nicolas

Posts: 2 / Nickname: nnombela / Registered: February 28, 2005 2:19 AM

Re: Design Principles from Design Patterns

June 14, 2005 8:41 AM

> Programming consists of this:
>
> 1. Divide your problem in smaller parts that you can name
> and are easy to understand. But make too many and you
> loose track of them.
>
> 2. Add more indirection to make your system more flexible
> to change. But add too much and you will get lost in the
> maze.
>
> 3. Only expose the minimal protocol (interface). Make it
> too big and you will have the pain of supporting it. Make
> it too small and its usefullness is restricted.

I will also say:

4. Minimize relations/dependencies between the parts of the problem. But less relations means being less flexible

5. Preference local relations/dependencies between the parts, so you only have to fully understand a small subset of the system to make changes or add new functionality. But being too local usually means less indirection and maybe a little bit of duplication (oh, no!)

Michael

Posts: 1 / Nickname: scharf / Registered: June 11, 2005 1:59 AM

Clarification: Interfaces versus Abstract Classes

June 11, 2005 6:06 AM

Erich says: In Java when you add a new method to an interface, you break all your clients. When you have an abstract class, you can add a new method and provide a default implementation in it.

This matters only if the interface is intended to be implemented by clients! If the interface is part of the API, but clients are not allowed to implement the interface (instead they use it), then new methods can be added without breaking API compatibility.

Ahsan

Posts: 2 / Nickname: elemental / Registered: June 13, 2005 11:36 PM

Re: Clarification: Interfaces versus Abstract Classes

June 14, 2005 3:56 AM

> This matters only if the interface is intended to be
> implemented by clients! If the interface is part of
> the API, but clients are not allowed to implement the
> interface (instead they use it), then new methods can be
> added without breaking API compatibility.

About this last comment. I see this line in eclipse a lot that "This inteface is not intended to be implemented by the client." Now there is one class in thier API that got deprecated (WorkbenchHelp, which contain static methods)and it says there to use IWorkbenchHelpSystem instead of it which is an interface. Now I am confused seeing this. The deprecated class had implementations. The interface replacing it is just ... well an "interface" without any implementation.

So here is my question what do you mean by "clients are not allowed to implement the interface (instead they use it)".

How would I be using such an interface. Am I missing a point here.

jaydee

Posts: 1 / Nickname: jaydee / Registered: January 27, 2005 1:50 AM

Re: Clarification: Interfaces versus Abstract Classes

June 14, 2005 7:29 AM

> So here is my question what do you mean by "clients are not allowed > to implement the interface (instead they use it)".
>
> How would I be using such an interface. Am I missing a point here.

I have to say that I was a bit puzzled by this at first too.
Would I be correct in thinking that "using" and not "implementing" means something like

 
	public void myMethod( Map myMapOfStuff )
	{
		...
		String myValue = (String) myMapOfSuff.get( "MyKey" );
		...
	}

since I am "using" the Map interface but not "implementing" it directly in my code. In the above example I would probably be calling the method with something like a

HashMap

instance that I'd populated.

Mind you, if the Map interface was given a new method, the HashMap implementation would have to implement it right? This is where Erich's point about abstract classes is true...

In Java when you add a new method to an interface, you break all your clients. When you have an abstract class, you can add a new method and provide a default implementation in it.

If HashMap extended an abstract class (which implemented Map) then you could fling a new method into Map and add a default implementation to the abstract class. So HashMap would not break - but would have the opportunity to implement the new method locally if it wants.

I don't know if this (a) helps anyone (b) is rubbish or (c) is a statement of the bleeding obvious!

Anyway, there's my input.
Jaydee

Ahsan

Posts: 2 / Nickname: elemental / Registered: June 13, 2005 11:36 PM

Re: Clarification: Interfaces versus Abstract Classes

June 16, 2005 1:50 AM

What was interesting to me in this discussion was the point that came up about using interfaces in contrast to having abstract classes and then their implementations in subclasses. I totally get the point about not wanting to break the clients.

I had a little solid problem and this probably isn't the best place to ask it. I should maybe post it in a java forum. But since Micheal mentioned this point

>"This matters only if the interface is intended to be implemented by clients!"

I thought he or someone else could elaborate on it. Because my problem is that I had used a class in my System that got deprecated in a newer API. Now I want to fix this. The deprecated class tells me to use an interface instead of it. And this interface says that it is not intended to be implemented by clients. So I am confused now about how to use this interface.

The deprecated class in the API had static members that I was using. The interface just give me method signatures, not implementations. This is the eclipse API I am talking about, so they must have done it for some reason. But I dont get it. Is my question a bit clearer now. If you are really interested in a solid example I gave the name of th deprecated class and the new interface in last post.

Phil

Posts: 1 / Nickname: pdennis / Registered: January 11, 2005 0:43 AM

Re: Clarification: Interfaces versus Abstract Classes

June 16, 2005 3:56 AM

> What was interesting to me in this discussion was the
> point that came up about using interfaces in contrast to
> having abstract classes and then their implementations in
> subclasses. I totally get the point about not wanting to
> break the clients.
>
> I had a little solid problem and this probably isn't the
> best place to ask it. I should maybe post it in a java
> forum. But since Micheal mentioned this point
>
> >"This matters only if the interface is intended to be
> implemented by clients!"
>
> I thought he or someone else could elaborate on it.

I think the key point here is that all the implementations of an interface, are distributed alongside that interface, by the API owner. This means that the API owner can extend the interface, and also implement the new interface methods in all of the implementations.

Clients which simply "use" the interface, by making calls to the interface methods, will not be broken by the interface change, as would clients which implement the interface. Of course the API must provide a way of obtaining objects which implement the interface, either by having the implementations publically constructable, or by returning instances from methods on other accessible classes.

From the Eclipse example, clients should now call PlatformUI.getWorkbench().getHelpSystem() to obtain a reference to an implementation of the IWorkbenchHelpSystem, which they can then use, instead of calling the static function on the WorkBenchHelp class.

Patrick

Posts: 7 / Nickname: pdoubleya / Registered: June 17, 2005 11:28 PM

Re: Design Principles from Design Patterns

June 18, 2005 3:31 AM

I would like you to have an interview with Allen Holub (holub.com), who last year published Holub on Patterns. His approach is to take working applications and show you how patterns are used to understand the code, solve real problems, and plan for future changes. The book is excellent, a great resource, I found. Anyway, he's a long-time engineer and author and I think what he has to say about patterns (and about how he and others were using patterns before the term was brought into IT) would be an interesting addition to what Gamma says.

Cheers
Patrick

dhanaraj

Posts: 1 / Nickname: gdhanraj / Registered: January 19, 2006 10:10 PM

Re: Design Principles from Design Patterns

January 20, 2006 3:59 AM

hello

i need information about factory and abstract factory method in design patterns in c++ with example please reply it

thank u

adi

Posts: 1 / Nickname: adiian / Registered: July 15, 2006 11:12 AM

Re: Design Principles from Design Patterns

July 15, 2006 3:23 PM

http://www.oodesign.com
Really good articles about desing principles. The Factory and Abstract Factory is really good described.

Roopa

Posts: 1 / Nickname: infronee / Registered: May 1, 2008 11:47 PM

Design Patterns

May 2, 2008 4:57 AM

I just wanted to know on which design pattern is .net architecture built on???

nikolai

Posts: 1 / Nickname: niki4ko / Registered: May 20, 2008 10:48 AM

Re: Design Patterns

May 20, 2008 4:06 PM

I've started to learn design patterns from GoF. In the book it is written that I must to "program to an interface, not an implementation". Ok, I understand that I will not have dependencies between the client class and the module, and I will have conditions to change the classes, but not the client. This is representation of the Abstract Factory pattern. Why I have to use this code:



public interface WidgetFactory {
    
    public ScrollBar createScrollBar();
    public Window createWindow();
    
}

//********************************************************

public class MotifWidgetFactory implements WidgetFactory {

    public ScrollBar createScrollBar() {
        return new MotifScrollBar();
    }

    public Window createWindow() {
        return new MotifWindow();
    }
}


//********************************************************

public interface Window {
    public void createWindow();
}

//********************************************************

 public class MotifWindow implements Window {
 
    public void createWindow() {
        System.out.println("MotifWindow was created!");
    }
}


//********************************************************
public class Client {
   
    public static void main(String args[]){
        
        WidgetFactory factory = new PMWidgetFactory();
        
        Window window = factory.createWindow();
        window.createWindow();
        
        ScrollBar scrollBar = factory.createScrollBar();
        scrollBar.createScrollBar();
        
    }
    
}

when I can write:



public class Client {
   
    public static void main(String args[]){

       MotifScrollBar motifScrollBar = new MotifScrollBar();
       motifScrollBar.createScrollBar();

       MotifWindow motifWindow = new MotifWindow();
       motifWindow.createWindow();

    }
}

What is wrong, and what will happened, when I have future changes in the program.

Fredy

Posts: 1 / Nickname: liquidsnk / Registered: October 20, 2007 0:26 PM

Re: Design Patterns

July 18, 2008 6:15 AM

nikolai traikov:
I'm not even close to be an expert at this, as some people that replies here, but maybe i can help you..

You are missing some code there, but i think the idea is:
Say tomorrow you want to change Motif to something else..
Using the first example, changing 'new PMWidgetFactory();' for the new implementation of the factory should suffice.
But, in the second example, your change will expand to every place in which you use Motif!,
and, even if you where using interfaces for the components, you still would have the job of changing the creation of every individual Motif component to the creation of the new ones..
using the abstract factory.. you just need to know how to instantiate an implementation for it... and even then.. you could just accept the interface of the factory as a parameter for the constructor of the classes that use it and decouple the implementation even more.

Of course, you don't allways need to do something like this.. there are many scenarios where a pattern implementation is overkill.

If i'm wrong or mssing something, please, feel the need to correct me!!!.
Regards.

Michael

Posts: 3 / Nickname: mangelguy / Registered: June 1, 2010 4:42 PM

Re: Design Principles from Design Patterns

June 1, 2010 9:53 PM

Hi,

I'm a bit new to interfaces. I'm not quite sold on them yet. Maybe someone here can help.

For example, I can implement one in my new class and fulfill all of its implementation requirements. I can then remove all references to the interface but keep the details of my implementation and my class still works the same. In other words, my class will work the same with or without the interface implementation references. So why keep the references?

What am I missing?

Thanks,

mangelguy

Vincent

Posts: 40 / Nickname: vincent / Registered: November 13, 2002 7:25 AM

Re: Design Principles from Design Patterns

June 4, 2010 5:17 AM

For a single type of class, you are not missing anything.

However, consider the following class where Animal is an Interface:

import java.util.ArrayList;
import java.util.List;
 
public class AnimalHospital
{
    private final List<Animal> animals;
 
    public AnimalHospital()
    {
        // Initially the hospital has no animals to treat.
        this.animals = new ArrayList<Animal>();
    }
 
    void add(final Animal animal)
    {
        animals.add(animal);
    }
 
    void treatAllAnimals()
    {
        for(final Animal animal : animals)
            animal.treat();
    }
}

This AnimalHospital can accept any kind of animal for treatment - provided the animal's class (e.g. Cat, Dog, etc.) implements the Animal interface.

If, at a later date, someone creates a new animal class (such as a DuckBilledPlatypus) that implements the Animal interface then that animal can also be treated at the hospital without any change to the hospital code. As long as it's an Animal then the AnimalHospital can handle it.

The same is also hold true if someone later extended the Dog to create a Doberman sub-class of dog.

That is power that interfaces bring to your code.