🚀 go-pugleaf

"Barry Mossman" <BarryMossman@hotmail.com> a �crit dans le message de news:
4108dfad@newsgroups.borland.com...

> I have become a fan of using interface references for my objects rather
> than object references;

Sensible person :-)

> I really liked the way Microsoft had used interfaces in the
> System.Collection classes such as IList, IEnumerable  etc.

So do I

> Then I read advice in the supplied documentation suggesting to stay clear
> of this practice as much as possible.

Would you really take advice from Microsoft ? ,~}

Joanna

--
Joanna Carter (TeamB)

Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker

"Joanna Carter (TeamB)" <joannac@btinternetxx.com> wrote in message
news:4108e7be@newsgroups.borland.com...

> > Then I read advice in the supplied documentation suggesting to stay
clear
> > of this practice as much as possible.
>
> Would you really take advice from Microsoft ? ,~}

Usually. Otherwise I probably wouldn't be using C# or dotNet. ... or
hasn't anyone told you yet who designed/wrote these ? ;)

Do you use Interface references exclusively ? If no, what is criteria ?

Barry Mossman

Barry,

Some of your concerns I addressed in a replay on the delphi.oodesign
newsgroup not so long ago. IMO it is a bad idea to overuse interfaces.
They're good sometimes and not so good other times, and sometimes it
doesn't make much difference.

> 1) The focus on Interfaces rather than implementation gave clarity of
> purpose as I can focus on what something does, rather than be bogged down
> in how it does it.

In this sense, a pure abstract class is exactly identical. So why is
there a special "clarity of purpose"? I don't think there is
particularly. In any case, designing an interface (of either class or
interface) can actually often be better done during implementation and
the consequent refactoring you do (or I do, anyway <g>). It's not always
obvious from the start what should be exposed, or even in which
class/interface it should live. I wouldn't get too hung up on this
point.

> 2) In version 2 I can use a different class, and as long as my new class
> implements the same interface only my factory needs change; my client is
> unaffected.

You mean version 1? :-) Sure, that's the point of interfaces, after all.
However, beware of falling foul (pun intended <g>) of the Speculative
Generality smell. There is no need to make things general purpose until
there is a need to. Don't use an interface if the only reason is that
"one day you might need to implement it in another class". It's easy
enough to refactor to do that if "one day" ever comes (usually it
doesn't).

> 3) Polymorphism.

Eh? Polymorphism applies to both classes and interfaces.

> 4) Multiple interface inheritance.

This is as often a bad thing as a good thing though. Use with care (see
the delphi post for a longer argument)

> 5) helps implement some of the GOF design patterns.

And doesn't help with others. Template Method is an obvious one that is
a PITA with interfaces, since it's a behavioural modification thing. All
factories are by definition classes since they're doing something (they
may return an interface reference, of course). There is little point in
making a Singleton an interface, since there will only ever be one of
them :-) IME, Visitor and Strategy are not particularly good candidates
for interfaces either, as my base Visitor and Strategy classes almost
always need default behaviour (usually do nothing in the case of
Visitor). However, some like Observer are much neater using interfaces.
Some can go either way depending on other factors (Iterator is one of
these, IME).

> Then I read advice in the supplied documentation suggesting to stay clear
> of this practice as much as possible.

It can be overused, certainly. You need to make a judgement call.

> ----------------------------------- quoted from MSDN ---------------
> Base Classes vs. Interfaces

They are good points. You should consider them in each situation. IMO,
if you always use interfaces for everything, you're doing it wrong.
Class inheritance allows you to do things you cannot do any other way.
Use the right tool for the right job (sometimes there is no clear
winner, mind). 

You might also like to consider the implications of custom attributes on
both class and interface design. There are times when *they* are more
appropriate :-) For an example of this, compare DUnit and CSUnit or
NUnit.

Cheers,
Jim Cooper

_______________________________________________

Jim Cooper         jim@falafelsoft.com
Falafel Software   http://www.falafelsoft.co.uk
_______________________________________________

This may be an over simplification, but here it is anyway :-)  I always
think of it this way

1) An object is "what it does"
2) An interface is how to tell it to do stuff.

I typicall only use interfaces for stuff like plugins.  Or if I need an
observer pattern or something.  Otherwise I tend to stick to objects, if I
can do it simply with an object why spend time writing an additional
interface?  Makes no sense to me.


-- 
Pete
-------
http://www.DroopyEyes.com
Audio compression components, DIB Controls, FastStrings, "Bold for Delphi"
components

http://www.HowToDoThings.com
Read or write articles on just about anything

"Barry Mossman" wrote
>
> I really liked the way Microsoft had used interfaces in the
> System.Collection classes such as IList, IEnumerable  etc.
>
> Then I read advice in the supplied documentation:
==
> Interfaces are appropriate in the following situations:
> Several unrelated classes want to support the protocol.
==

Sounds like they're following their own advice to me. listability,
iterability, printability, enumerability are all 'cross-class' type
functions. That's the main power of using an interface rather than a class.

bobD

"Barry Mossman" <BarryMossman@hotmail.com> a �crit dans le message de news:
4108ee0d@newsgroups.borland.com...

> Usually. Otherwise I probably wouldn't be using C# or dotNet. ... or
> hasn't anyone told you yet who designed/wrote these ? ;)

Yeah, but the inspiration came from a Borlander :-)

> Do you use Interface references exclusively ? If no, what is criteria ?

In Delphi for Win32, due to refcounting nightmares, I use Interfaces much
more than is normally desirable.

Now .NET is changing how I write to a more balanced approach.

Interfaces are a means of describing behaviour, '-ability' as Bob puts it;
if you have a common behaviour that is likely to be required over disparate
class hierarchies, then this is a candidate for an Interface.

An Interface is also a contract and having everything declared as an
Interface allows developers to write implementing classes that know nothing
about each other, simply about the contracts offered by the interfaces
specified.

Classes are also a means of describing behaviour, but in a way that
stipulates the implementation as well as the 'contract'.

Whereas an interface describes what an object can do, a class can also
describe the order in which that behaviour has to occur; see the Template
Method pattern.

A class can also retain state information, even if it is a pure abstract
class; a sort of interface with data.

The beauty of not having the refcounting nightmare of Delphi for Win32 is
that you can write classes without interfaces and then discover common
behaviour that can be refactored out into interfaces at a later stage in
development.

Finally, it has to be said, that interfaces are the only sensible way to
implement 'multiple inheritance' although by that I really mean that an
object can be addressed from several 'users' without allowing those users to
know how other users view the object.

e.g. a business object appears to be the type that it represents (e.g.
Customer) to application logic, but also appears to be an Originator of a
Memento to an editing history without the history classes needing to know
what type of business object it really is.

Does any of this make sense? Have I answered your question? I haven't yet
had breakfast and am in need of an injection of decaffeinated coffee :-))

Joanna

--
Joanna Carter (TeamB)

Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker

"Jim Cooper" <jcooper@tabdee.ltd.uk> wrote in message
news:41093509.C3E2B3BF@tabdee.ltd.uk...
> Barry,
>
> Some of your concerns I addressed in a replay on the delphi.oodesign
> newsgroup not so long ago.

Thanks Jim. I found your comments here, and in the delphi group, very
helpful.

> > 1) The focus on Interfaces rather than implementation gave clarity of
> > purpose as I can focus on what something does, rather than be bogged
down
> > in how it does it.
>
> In this sense, a pure abstract class is exactly identical. So why is
> there a special "clarity of purpose"? I don't think there is
> particularly. In any case, designing an interface (of either class or
> interface) can actually often be better done during implementation and
> the consequent refactoring you do (or I do, anyway <g>). It's not
always
> obvious from the start what should be exposed, or even in which
> class/interface it should live. I wouldn't get too hung up on this
> point.

I guess I am still missing the interface section of a Delphi source file.
I had been putting the Interfaces in a group together at the front, or in
a seperate cs file. My abstract classes usually end up with some
implementation. ... agree no big deal.

> You mean version 1? :-) Sure, that's the point of interfaces, after
all.
> However, beware of falling foul (pun intended <g>) of the Speculative
> Generality smell. There is no need to make things general purpose until
> there is a need to. Don't use an interface if the only reason is that
> "one day you might need to implement it in another class". It's easy
> enough to refactor to do that if "one day" ever comes (usually it
> doesn't).

Good point, and touche. I guess "Speculative Gernerality" is from a book.
Is it the agile one ?

> > ----------------------------------- quoted from MSDN ---------------
> > Base Classes vs. Interfaces
>
> They are good points. You should consider them in each situation. IMO,
> if you always use interfaces for everything, you're doing it wrong.
> Class inheritance allows you to do things you cannot do any other way.
> Use the right tool for the right job (sometimes there is no clear
> winner, mind).

Thanks. I guess I was still thinking that is best not to mix interfaces
and normal object references as an overhang from Delphi before dotNet. I
understand it better now after your posts.


> You might also like to consider the implications of custom attributes
on
> both class and interface design. There are times when *they* are more
> appropriate :-) For an example of this, compare DUnit and CSUnit or
> NUnit.

Will look into it. Thanks again.

Barry Mossman

"Joanna Carter (TeamB)" <joannac@btinternetxx.com> wrote in message
news:4109f820$1@newsgroups.borland.com...

> > Do you use Interface references exclusively ? If no, what is criteria
?
>
> In Delphi for Win32, due to refcounting nightmares, I use Interfaces
much
> more than is normally desirable.
>
> Now .NET is changing how I write to a more balanced approach.

I am starting to understand this better now. Thanks.

> Does any of this make sense? Have I answered your question? I haven't
yet
> had breakfast and am in need of an injection of decaffeinated coffee
:-))

Thanks. I was pretty much on top of what Interfaces where, just
re-considering when to use them in my declarations, and when to use
base/concrete types.

What does decaffeinated coffee do for one ? Sounds like a steak without
the sizzle to me. You sure it isn't just a placebo in dirty water form ?
<g>

Barry Mossman

> I guess I am still missing the interface section of a Delphi source file.

Oh, me too. C# is not a tidy language, and all that inline code makes it
worse, IMO. Code folding isn't the same thing, and definitely isn't
implemented well enough. 

> I guess "Speculative Gernerality" is from a book.
> Is it the agile one ?

Martin Fowler's "Refactoring". It lists a number of "bad smells", ie
aspects of code that don't feel quite right.

Speculative Generality is a difficult one for most programmers, as most
of us have been trained/conditioned to do exactly that - look for
generalised behaviour. I know I still have to consciously stop myself
going too far down that road from time to time :-)

As I get more comfortable with refactoring, I also find myself delaying
applying refactorings. For example, I won't necessarily do an Extract
Method (ie create a new method from a piece of code in a longer one)
immediately if I find I need to repeat the code somewhere. I'll often
let it fester for a bit, even if I have the same code several times.
That way I let variations fall out, and it seems to make it more obvious
sometimes what new classes/interfaces are needed. 

My current opinion (this one is definitely subject to change without
warning <g>), is that this sort of approach is somewhat counter to the
way you work if you use modelling tools to define your
classes/interfaces. Because you are then working as per your first post
- focussing on the public interface of a class/interface rather than the
implementation. The contract level view, if you like. I've noticed a
tendency in those who work that way towards a proliferation of
classes/interfaces because it's so easy to make them.

However, a lot of (most?) refactoring is to do with the implementation
code, and letting that drive the need for new properties, methods,
classes etc. I don't know if I can explain it well, but there is often a
different feel to the code produced one way to the other (of course,
sometimes it will be the same). It's sort of similar to the difference
between bottom-up and top-down programming, if you remember those :-)
These days, we recognise that you need to do both, and I would (roughly)
equate modelling with top-down, and refactoring with bottom-up. Note
that I'm not saying they are the same things! :-) That's just to
indicate the difference in feel I find in the code.

Cheers,
Jim Cooper

_______________________________________________

Jim Cooper         jim@falafelsoft.com
Falafel Software   http://www.falafelsoft.co.uk
_______________________________________________

On Thu, 29 Jul 2004 23:31:33 +0100, Peter Morris [Droopy eyes
software] wrote:

> This may be an over simplification, but here it is anyway :-)  I always
> think of it this way

The way I've seen it put (and think is helpful) is:

> 1) An object is "what it does"
This is an is-a relationship

> 2) An interface is how to tell it to do stuff.
While this is a 'can-do' relationship.

-- 
Marc Rohloff [TeamB]
marc rohloff at myrealbox dot com

Joanna Carter (TeamB) wrote:
>
> Does any of this make sense? Have I answered your question? I haven't
> yet had breakfast and am in need of an injection of decaffeinated
> coffee :-))

Isn't that kind of like taking aspirin with the ASA removed ?

-- 
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
"The two most abundant elements in the universe are hydrogen and
stupidity." - Harlan Ellison

Barry Mossman wrote:

> I guess I am still missing the interface section of a Delphi source
> file.

Tell me about it.

-- 
Nick Hodges -- TeamB
Lemanix Corporation -- http://www.lemanix.com
Read my Blog -- http://www.lemanix.com/nick

> > 1) An object is "what it does"
> This is an is-a relationship
>
> > 2) An interface is how to tell it to do stuff.
> While this is a 'can-do' relationship.

Yes, although they mean the same thing, I do prefer yours.


-- 
Pete
-------
http://www.DroopyEyes.com
Audio compression components, DIB Controls, FastStrings, "Bold for Delphi"
components

http://www.HowToDoThings.com
Read or write articles on just about anything

> Does any of this make sense? Have I answered your question? I haven't yet
> had breakfast and am in need of an injection of decaffeinated coffee :-))

OK I'll fill up one little thing you missed. :)

Interface is a good way to provide Design abstraction. Eventually what ever
application we develop now a days will have different layers, in  a good
design each layer will do one thing & only one thing. example may be Data
Access layer(DAL), which knows how to save your BO in to database, and BO
layer which known how to process the data. and so on.... Change in design of
one should not effect the change in design of other.

If I am developing BO, I hardly care how it will be stored or processed by
DAL. This is a kind of place where you expose an Interface. This is what we
call Design Abstraction. If I need to replace the DAL to store the BO in a
different kind of Database, I just need to create a new class derived from
totally different kind of base class & expose the same interface. Nothing
else changes here...

Regards
Kiran.