Board index » delphi » Re: Is this class methods usage violating OOP principles?

Re: Is this class methods usage violating OOP principles?


2005-09-23 03:42:05 PM
delphi63
On Thu, 22 Sep 2005 11:49:30 -0500, Scott Roberts
<XXXX@XXXXX.COM>writes:
Quote
>I could argue that the
>caller knows what kind of information it handles, so define things
>there.
>I don't, but that point would be just as valid as yours.

The problem is that different clients may handle different information..
If
you design this way, you need to know in advance what every client can
handle and create a "context" that handles it all. If you use events, the
process gives some information to whoever is listening. The listener can
decide for themselves what to do with that information (if anything).
Don't mix things. My non-serious argument was that the client defines
everything. This is not the context way, this is a silly way. I was pointed
out only that the fact that process knows what information it has, is not
a final argument.
As usually, if you don't formalize things, but let every processes have any
number of events, you certainly have greater possibilities. Like
programming
in assembly gives you the opportunity to handle everything the way you
like.
But it won't invalidate the role of high level languages. At this point, i
feel no urge to have the freedom to distribute any kind of information. I'm
ok with the abstract, predefined ones. But i still say, it is up to you to
decide, you know your situation.
Quote
>Context way is more formal, every
>process uses the same interface. Event way is more free, every process

All of our long running processes expose a "OnProgress" event and the
"OnProgress" event always passes "SBSProgressEventArgs". What the client
So actually, you don't really use the freedom to create process-specific
information? Or you do, but you define a minimum, some common part?
Quote
>>The C# code would be something like this:
>Oh. Is this not a general delphi ng?
If we are limited to discussing only "Delphi OOP" in this newsgroup I
think we're going to miss some good conversation.
In general, yes. But this topic was launched on a certain problem, so
I feel it is not very forthcoming to recommend fancy technologies (oh
my, i called .NET a fancy technology. now I am afraid of fans! :) )
Quote
Delphi does not support multi-cast delegates?
Delphi .NET might does, i don't know. Delphi win32 does not.
Quote
I don't see the point in defining some context that then launches events.
Why not just have the process launch the events and forget about all the
additional complexity of having a "context"?
I see a point. Generalisation. The abstract context does not have events,
but any descendant can, if it fits.
 
 

Re: Is this class methods usage violating OOP principles?

"krisztian pinter" <XXXX@XXXXX.COM>writes
On Thu, 22 Sep 2005 11:49:30 -0500, Scott Roberts
<XXXX@XXXXX.COM>writes:
Quote
Don't mix things. My non-serious argument was that the client defines
everything. This is not the context way, this is a silly way. I was pointed
out only that the fact that process knows what information it has, is not
a final argument.
I an effort to not confuse the subject, I kindly ask that you not make silly
arguments. :-)
The "context" way means that some object is passed to the process. The
process then calls some methods on that object at various intervals. Right?
This is almost exactly what events are. The process defines a method
signature that is valid for that process and a "context" (EventArgs) to be
passed to any objects who decide to implement that method signature. While
it is certainly possible to go crazy creating different events for every
process, it is certainly not the standard nor recommended method - by
anybody. The standard recommended event signature is (Sender, Args).
Defining a common "Args" for progress is a no-brainer.
The only real difference between creating a "context" and having the process
call its methods and having an event is that the event can ultimately call
*any* method that is registered to it - not just the pre-defined ones that
exist on the "context". I realize that the context could translate calls to
its methods into calls to other methods, events, etc., but I personally just
don't see the point.
 

Re: Is this class methods usage violating OOP principles?

On Fri, 23 Sep 2005 10:36:33 -0500, Scott Roberts
<XXXX@XXXXX.COM>writes:
Quote
The "context" way means that some object is passed to the process. The
process then calls some methods on that object at various intervals.
Right?

This is almost exactly what events are.
The difference are:
1. the event way is liberal, every process can declare any number of
events, can or can't follow any guidelines, etc. the context way is
rigid, you need to go by the design of the context. we agree, that it
is not a great advance, although some.
2. events can be used to send information to different places. i don't
really see (yet) how would we benefit by this.
Quote
can call *any* method that is registered to it - not just the
pre-defined ones
That one is confusing. They are not the "pre-defined" ones. The context
has no predefined methods, as they are all abstract. The base context
is abstract, and you supply your own methods during declaring the real
context. In case you need to do different things in two places, you
can define two contexts, or a multi-state context, or whatever.
 

Re: Is this class methods usage violating OOP principles?

Quote
1. the event way is liberal, every process can declare any number of
events, can or can't follow any guidelines, etc. the context way is
rigid, you need to go by the design of the context. we agree, that it
is not a great advance, although some.
In my opinion (and you really can look at it with a different point of
view) the context approach is cleaner, while the event approach is more
simple to implement. But the context approach has its advantages, too:
Switching context is one assignment, switching events are more
assignments (and you have to find all of them if you add more events,
but, well, if you add new methods to your base context class you have to
do some modifications, too, but I think it is less likely that you forget
one). But I think the main advantage of the context approach is that you
can use all of the OOP design patterns. And you can use class types and
virtual constructors. You can store different context objects in a
TObjectList and access them by index. it is just seems to be a bit more
elegant to me.
Jens
--
Jens Gruschel
www.pegtop.net
 

Re: Is this class methods usage violating OOP principles?

On Mon, 26 Sep 2005 11:24:06 +0200, Jens Gruschel
<XXXX@XXXXX.COM>writes:
Quote
In my opinion (and you really can look at it with a different point of
view) the context approach is cleaner
I think the same, but i never see this thing implemented anywhere. Nor i
used it myself. So i want to convince Scott to use it, and then report
difficulties, benefits, thus i can get info for free :)
 

Re: Is this class methods usage violating OOP principles?

Quote
I think the same, but i never see this thing implemented anywhere. Nor i
used it myself. So i want to convince Scott to use it, and then report
difficulties, benefits, thus i can get info for free :)
The same is true for me. Often when implementing such things you are in
a hurry and don't think much about it, and the most important thing is
that you get it working as soon as possible, being confident with a
solution that isn't that general.
Jens
--
Jens Gruschel
www.pegtop.net
 

Re: Is this class methods usage violating OOP principles?

"Jos?GonzŠlez D'Amico" <XXXX@XXXXX.COM>writes
Quote
Completely agree, I just wanted to make the hourglasses more OO and
reduce the amount of code. My app only need to change to hourglass, do
the lengthy operation and return to the normal cursor in no more than 3
places along the project... No threads,
Sounds good.
Quote
no nesting of operations, etc.

As others have pointed out, this is a risky assumption.
You are creating an implicit contract for how your
object can be used. This violates OO principles.
It isn't much more complicated to make it nestable
and will make your life easier down the road.
--
HTH,
Brad.
 

Re: Is this class methods usage violating OOP principles?

Brad White writes:
Quote
As others have pointed out, this is a risky assumption.
You are creating an implicit contract for how your
object can be used. This violates OO principles.
I know, but when one is in a hurry...
Besides the code probably will be maintained by another person who
doesn't care much about OO.
Regards,
--
José