Internal events/ vb.net - event driven?

vis781

Well-known member
Joined
Aug 30, 2005
Messages
2,016
Location
Cambridge, UK
Programming Experience
5-10
Ok, so i'm just chucking this out there because i'm interested in peoples opinions on this one... Why is it that when ever i see app being built or ,my favorite field, controls being developed i very rarely see these programs using internal events. For example....

ClassA has a sub called 'DoSomeWork'

Why is it that more often than not, i see instances passed into say ClassB via a property or in the constructor then ClassA's 'DoSomeWorkSub' Is called like this....

'InstanceOfClassA.DoSomeWork'

That is to say nothing of having to check if it is nothing prior to calling the sub. I mean wouldn't it be better in FormB to raise an internal event that ClassA catches and that runs the 'DoSomeWork' sub in ClassA, no checking if things are nothing and ClassB has done it's part and couldn't care less what happens after. Am i the only one who sees this or is this common place. Going on the principle that vb.net is event driven is this not the preferred way to go? Or is it that declaring something using the WithEvents keyword incurrs a lot of overhead.

As I say, i'm just asking the question, as i've seen both approaches however the former seems to be the method most adopted. I welcome your comments...
 
Last edited:
It is an event that happens when you click button to execute 'InstanceOfClassA.DoSomeWork', it was the click event..

What you were saying, you mean that the formX has got an instance of objectY, and you want the objectY to subscribe to an event of formX?
That sound a bit on the edge of backwards programming to me, stretching it, I would say, the least. You have to pass the formX instance to the objectY property, and objectY will then add handler for the formX events. You wouldn't then do other than mirroring the events already in formX, nothing but lots of typing for no gain.

Well, maybe that was an awful misunderstanding of what you meant.

Perhaps you meant, formX has got an instance of objectY, when formX sets a property in objectY, then objectY automatically does its work? This is pretty normal in property setters, if only doing 'something' when this data is received. In respect to doing the class full main process, there could be issues with missing parameters, that the caller has special needs for when the method must be executed synchronous and asynchronous etc.

It all depends, it's you who develops, could be all classes, and how all the bits work together is a piece of the big puzzle/architecture/design to decide.
 
vis781,

I'm a wee bit lost - the post is a bit hard to follow? Can you re-state it, or provide some code outlining what you describe? I cant easily see a "former" or "latter" that you infer exist in your post?
 
Last edited by a moderator:
Are you talking about:

2 classes, ClassOwned and ClassOwner

In ClassOwner:
VB.NET:
  Dim x As ClassOwned = New ClassOwned
  x.SetOwner = Me

then in ClassOwned:
VB.NET:
  Dim y as ClassOwner = Me.MyOwner
  y.SomeMethod


And you ask why is it like this instead of using a delegate or having ClassOwned raise an event when it wants some work doing or make some notification?

I think the answer is because people just dont understand event driven hierarchies and delegation - especially if upgrading from a procedural background.

The aspect you describe here is a tell tale OO flaw of high coupling - both Owner and Owned will fail if only one is added to a project. With delegation/events this wouldnt happen, and the overheads (though maybe greater) probably dont weigh into things too heavily unless there is a very good reason for the coupling to exist in terms of performance/traffic between objects. In that case I would consider whetehr they should be the same object anyway
 
VB.NET:
Public Class Class1

    Private var As New Class2

    Private Sub DoSomethingToClass2()
        Me.var.DoSomething()
    End Sub
End Class
In this code, the Class2 instance has no need to know that the Class1 instance exists. If you want Class1 to raise an event that is then handled by Class2, that would require that the Class2 instance have a reference to the Class1 instance. That's why it's done the first way. If you don't then every object would be required to have a reference to evry other object that might want it to do something, instead of the other way around.
 
The inference being, i guess, that you have some Worker class and you want to watch it work.. the Watcher class should have the knowledge sufficient to set up the worker and start it working. The worker class should have no knowledge of any other class in the system, it merely announces messages via event or delegate to whomever is watching or interested.

As noted before, this approach generally isnt well understood among non-OO/non-event driven thinkers, so they generally choose to specialise the worker so it knows who/what its watcher is and it then becomes dependent/coupled with that. Its easier to understand, probably because few humans find themselves in the real life context of wanting to start some process, not know or care the internals and observe the result. It requires a bit of lateral thought to realise that this process is everywhere.. possibly to a greater extent than the coupled knowledge transfer..

To examine this by analogy: When humans interact with other humans, they usually establish a dialog whereby the interaction is personal and contextual - if youre going camping, you go to a shop and make the sales person aware of your need, and then he feeds back to you.. You rarely go to a camping shop and wait for a sales person to amke an announcement that two-man tents are great for a single person in summer because they are more airy.
Humans might not consider that a camping expert who writes in a magazine isnt dialoguing with anyone in particular, just announcing information that the user may or may not be interested in.

It would be an interesting psychological study, actually.. and you may find your answer in books about HCI - why do programmers program in a certain way.. How do their interpersonal skills influence the degree of coupling they assign to objects within their programs?
 
Back
Top