Articles Forum - Design Principles from Design Patterns

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Articles Forum
Design Principles from Design Patterns

17 replies on 2 pages. Most recent reply: Jun 4, 2010 6:17 AM by Vincent O'Sullivan

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 17 replies on 2 pages [ 1 2 | » ]

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Design Principles from Design Patterns

Posted: Jun 6, 2005 8: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?

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Design Principles from Design Patterns

Posted: Jun 7, 2005 6: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.

bug not

Posts: 41
Nickname: bugmenot
Registered: Jul, 2004

Re: Design Principles from Design Patterns

Posted: Jun 8, 2005 6: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 Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Design Principles from Design Patterns

Posted: Jun 10, 2005 6:59 AM

A few comments and thoughts here:

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

--
Cedric

Michael Scharf

Posts: 1
Nickname: scharf
Registered: Jun, 2005

Clarification: Interfaces versus Abstract Classes

Posted: Jun 11, 2005 7: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: Jun, 2005

Re: Clarification: Interfaces versus Abstract Classes

Posted: Jun 14, 2005 4: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.

Christopher Ward

Posts: 1
Nickname: jaydee
Registered: Jan, 2005

Re: Clarification: Interfaces versus Abstract Classes

Posted: Jun 14, 2005 8: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

Nicolas Nombela

Posts: 17
Nickname: nnombela
Registered: Feb, 2005

Re: Design Principles from Design Patterns

Posted: Jun 14, 2005 9: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!)

Ahsan

Posts: 2
Nickname: elemental
Registered: Jun, 2005

Re: Clarification: Interfaces versus Abstract Classes

Posted: Jun 16, 2005 2: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 Dennis

Posts: 2
Nickname: pdennis
Registered: Jan, 2005

Re: Clarification: Interfaces versus Abstract Classes

Posted: Jun 16, 2005 4: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 Wright

Posts: 15
Nickname: pdoubleya
Registered: Jun, 2005

Re: Design Principles from Design Patterns

Posted: Jun 18, 2005 4: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 govindasamy

Posts: 2
Nickname: gdhanraj
Registered: Jan, 2006

Re: Design Principles from Design Patterns

Posted: Jan 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 ian

Posts: 5
Nickname: adiian
Registered: Jul, 2006

Re: Design Principles from Design Patterns

Posted: Jul 15, 2006 4:23 PM

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

Roopa Reddy

Posts: 1
Nickname: infronee
Registered: May, 2008

Design Patterns

Posted: May 2, 2008 5:57 AM

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

nikolai traikov

Posts: 1
Nickname: niki4ko
Registered: May, 2008

Re: Design Patterns

Posted: May 20, 2008 5: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.

Flat View: This topic has 17 replies on 2 pages [ 1 2 | » ]

Previous Topic

Next Topic