Re: Program to an Interface not an implemetation

"Will" <billreyn@xxxxxxxxxxx> wrote in message
news:1127405086.536898.282310@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>I am looking at the Gang of Four
> Design Patterns and wondering
> about the advice 'Program to
> an Interface, not an implementation'.

I sure hope that this question is based upon the fact that you have just
started taking a long look at patterns. If so, great. It is a toolkit that
can make OO development much more effective. However, I sure hope you
aren't starting with the GoF book! It's essentially a doctoral thesis. If
you want to actually learn how OO patterns are used in context, pick up a
book like "Design Patterns Explained" by Shalloway.

Your examples show, to me, that you do not understand how encapsulation is
enabled by interface.


> Does any person know what the present thinking
> is since the gang of 4? Have we moved on and
> upwards. What is the latest
> bees knees in OO thinking. Or are we back to
> every application should be considered on its
> own merits. (i.e. hack it together in 1 week)
>

I refuse to speak for the community. In my opinion, current design
discussion tends towards describing systems as (potentially) distributed
components in a loosly coupled infrastructure. The components themselves
are developed to take on coarse-grained but atomic responsibilities. They
share code by using common frameworks. The frameworks are built largely on
the GoF design patterns and much of the work that followed.

I've seen lots of discussion about cross-cutting concerns and AoP. Lots of
discussion about process (as always) with Agile methods taking the center
stage (and the heat) in the past few years.

I do not know of anyone who thinks you should hack.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--


.

Relevant Pages

  • Re: Class inheritence & subclassing
    ... Provides a common interface for accessing containers and objects. ... The Design Patterns book is a must-have for OO developers - problem is ... ' IColoredComponent ... Public ReadOnly Property Color() As System.Drawing.Color Implements ...
    (microsoft.public.dotnet.languages.vb)
  • Re: a java design question
    ... > functions as long as they implement the interface and so I dont have to ... > int a; ... instantiating objects is not that expensive. ... using known design patterns enhances the ...
    (comp.lang.java.help)
  • Re: Basic Concept Question Why Interface?
    ... The answer can be found by digging deeper into Design Patterns. ... Nearly every one of these design patterns REQUIRES the use of interface ... definitions in order to create the concept of a contract where any object ... > void PostInterest(); ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Why Java interface?
    ... i recommend books related to 'Design Patterns' to you. ... in java, 'interface' is _only_ way for multi-inheritance. ... But in an interface, there are> only abstract methods, and we have implement all the methods in the> class that implements this interface, why do we still use interface? ...
    (comp.lang.java.programmer)
  • Re: Programaticly call a method from a different object?
    ... Opinions expressed in this forum are my own, ... I do not answer questions on behalf of my employer. ... programmer helping programmers. ... that's covered loosly by traditional Design Patterns. ...
    (microsoft.public.dotnet.general)