Board index » delphi » Re: Evangelizing

2005-09-21 07:13:06 AM
delphi248
"Jarle stabell" <XXXX@XXXXX.COM>wrote in
message news:XXXX@XXXXX.COM...
references. I with ya.
However, haven't you just moved the coupling from the "public class methods"
to the "interface methods"? So the client is coupled to the interface, and
any time you want to change the interface you've (potentially) got to change
all clients that use it. Right? And it gets worse - you have to change all
classes that implement the interface too!
Don't get me wrong, I see the value of interfaces they are very nice in some
situations. But I don't see how they "solve" anything by using them
exclusively in place of public methods & properties.
 

from using every interface. Are you after something like the Eiffel approach
others have been talking about?
And one of the two biggest problems I see with interface-based code is having
too many interfaces on one object.
interface is involved. You've used this expression several times now, but I
don't see what you're getting at - you seem to have used it in at least 2
different contexts.
Cheers,
Jim Cooper
__________________________________________
Jim Cooper XXXX@XXXXX.COM
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
__________________________________________
 

wanted to talk about one of the papers, and why he thinks this chap's ideas are
important, but we still aren't having that discussion.
FWIW, I no longer read non-tech. Between the "Borland is dying" and "Why aren't
Borland doing a 64-bit Delphi? They're gonna die without it" threads, and a
certain tone that is creeping into all the others, it has driven me away :-)
Cheers,
Jim Cooper
__________________________________________
Jim Cooper XXXX@XXXXX.COM
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
__________________________________________
 

"Jim Cooper" <XXXX@XXXXX.COM>writes
I agree. I am a much more easy going individual when I avoid that group. :-)
 

Bob Dawson writes:
coupling.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: www.logicfundamentals.com/RADBooks.html
"The purpose of morality is to teach you, not to suffer and die, but to
enjoy yourself and live." - Ayn Rand
 

"Scott Roberts" <XXXX@XXXXX.COM>a écrit dans le
message de news: 4330972d$XXXX@XXXXX.COM...
querying is no longer tied to the COM implementation, I find that my designs
are radically changing.
Where I'd normally use exclusively interfaces due to refcounting
problems, I find that I am able to design classes with a primary public
"interface" of its own which represents the primary purpose or behaviour of
the class, whilst supporting "secondary" behaviours with interfaces.
So you would have something like CustomerList as a class with public methods
like Add, Remove, etc and support for interfaces like IEnumerable,
IStreamable, etc.
One of the major influences in this decision is the ability that .NET
interfaces give you to get back to the implementing class from an interface;
something that was not possible or very messy in Delphi for Win32.
Joanna
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
 

"Wayne Niddery [TeamB]" wrote
needing modules (or any visibility/scope context other than class). It's
clearly the Eiffel version of friend declarations.
Actually with the new 'strict' visibility term Delphi gives us almost the
same functionality--put two classes in a unit and you can have them be
friends for some private/protected methods, but not others. Eiffel's
selective export concept does exactly that, but specifies the relationship
in the class itself, rather than needing the unit/module construct to scope
the friendship rights.
bobD
 

"Jim Cooper" <XXXX@XXXXX.COM>writes
self-effacing nostalgia for an old way of writing programs. Clearly he
recognizes the problems inherent in goto. It didn't seem to me that he was
implying that he wished he could go back to using goto, like secretly in the
middle of the night, he writes code that uses goto :-)
-Corinna
 

Jim Cooper writes:
you don't have the source code for the class of the object, nor the
declaration of the interface itself?
Unless your name is Danny Thorpe or Hallvard Vassbotn, I doubt you are able
to do it. No offense! ;-)
that isn't a problem IMO. that is a situation when interfaces shine.
With interfaces, you can get away with being less "strict" in
implementing/constructing your classes, you can use quite a lot of tricks in
the implementation, without that complexity "leaking out".
is convenient to implement it that way, interfaces let you get away with
having a bit more "dirty" classes.
the whole class (methods, fields, the class' place in the class hierarchy)
as being only "locally" interesting when using interfaces.
combine those into classes is "implementation".
The MFC pattern doesn't dictate you to implement it with three classes, it
is the three roles which are the essence of the pattern.
Cheers,
Jarle
 

Jarle stabell writes:
It is the three roles and how they *collaborate* which are the essence of
the MFC pattern.
Cheers,
Jarle
 

answer, BTW :-)
only time there is any need for that is when the responsibilities are very
tightly coupled (eg enumerating and sorting a collection). Otherwise it is a
(very) bad smell, and you should be splitting the responsibilities out into
separate classes. This is exactly the same problem faced by many objects that
have lots and lots of methods and properties.
Cheers,
Jim Cooper
__________________________________________
Jim Cooper XXXX@XXXXX.COM
Tabdee Ltd www.tabdee.ltd.uk
TurboSync - Connecting Delphi to your Palm
__________________________________________
 

Jim Cooper writes:
interface.
dangerous because it can be made very local. If I find it convenient to
merge together things which "academically" belongs in separate classes, I do
the merge because the consequences of doing it isn't as severe, because the
smell isn't noticable outside of the implementation of the given class. (The
class generally isn't visible to other units.)
tricks are kept very local.
you regard them as being on a higher abstraction level than concrete
classes?
Cheers,
Jarle
 

"Jarle stabell" <XXXX@XXXXX.COM>wrote in
message news:433201d0$XXXX@XXXXX.COM...
design requires full normalization (at least 3NF, if not further). But in
practice, most database designers find it more "convenient" to denormalize
their data a bit, or at the very least, use views and triggers, etc to
improve performance, or simplify common queries. The database design is
dirtier, but for a good reason.
Like an artist or architect, you *purposely* violate "proper" design because
your judgement tells you it is a good idea. And so then the trick is to not
go too far... (like artists tend to do :) )
-Corinna
 

"Jarle stabell" <XXXX@XXXXX.COM>wrote in
message news:433201d0$XXXX@XXXXX.COM...
Here's what I am hearing, and let me know if I have completely missed the boat.
You're saying:
This class implements 3 interfaces (A,B,C). Interface A is visible to client
X, interface B is visible to client Y, and maybe interfaces B & C are
visible to client Z.
What this implies is that your single class fulfills 3 different
roles/responsibilities. What *I* would do is create 3 different classes
(perhaps all derived from a common ancestor) to fulfill the 3 roles instead
of implementing 3 interfaces on a single class.
To me, an interface is a "client" design feature - not a class design
feature. I'd write a client that could process any object that
implements a specific interface, but I'd never create a class and try to
show/hide functionality in that class using interfaces.
Or maybe I have grossly misunderstood. :-)
 

Scott Roberts writes:
implies the implementing class is doing too much). But it is entirely
possible the interfaces are simply being used to limit access to a subset of
the class. That could be for the purpose of roles and/or security, or other
things. It also maybe that the interfaces also derive from each other so
that each one is a superset of the prior one.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: www.logicfundamentals.com/RADBooks.html
"The moment the idea is admitted into society that property is not as
sacred as the laws of God and there is not a force of law and public
justice to protect it, anarchy and tyranny commence." - John Adams