471,343 Members | 1,326 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,343 software developers and data experts.

Calling a parent class method

I have a class (sharedClass) that is instantiated (not derived) by two other
classes (guiClassA and guiClassB). The sharedClass needs to be able to call
a method that is defined in its parent class (guiClass).

Specifically, when guiClassA or guiClassB calls a method from the
sharedClass, the sharedClass needs to log its actions by sending strings to
the guiClass (via guiClass method calls), which in turn display or record
this log information in their own unique ways.

How can the sharedClass call out a function from its parent class without
knowing exactly what kind of class the parent class is? (I can however
guarantee that the parent class will implement the logging function).
Since both guiClasses are not used in the same application, I was able to
solve this in C++ by declaring the logging function prototype in a header
file that was included by all the classes, and then defining the function
implementation at the same level as the guiClass was instantiated. Thus, the
connection was made by the linker. Is there any way to do something similar
in C#?

Nov 17 '05 #1
1 2236
I was going to suggest declaring the logging function(s) as an
interface implemented by both gui classes, but I just thought of a
better way.

Don't use methods at all. Use events. Have your sharedClass expose a
(or multiple) shared event(s). You can declare your own event arguments
and your own event handler type to carry any specialized information
you need. Whenever it needs to log anything, the sharedClass simply
raises the appropriate event.

It's then up to the enclosing guiClass to subscribe to the event(s) and
do whatever it needs to do (log the event) as appropriate.

I wouldn't even name the event according to what has to happen (don't
call it LogXXXX). Instead, I would name the event according to what
happened that was "loggable". You know: ValueChanged,
CertificateExpired, whatever. This may lead to multiple events from the
sharedClass, but this also achieves maximum decoupling, both logically
and conceptually. The sharedClass just notifies the "outside world"
when certain things happen and provides details about the event. The
guiClass is then just one interested party that happens to respond to
those events by logging them. Other classes may want to subscribe to
the events for other reasons.

So... I would use a completely different paradigm: events rather than

Nov 17 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Murat Tasan | last post: by
14 posts views Thread by Axel Straschil | last post: by
6 posts views Thread by jalkadir | last post: by
6 posts views Thread by Jon Hyland | last post: by
1 post views Thread by NOSPAM | last post: by
5 posts views Thread by Nick Flandry | last post: by
1 post views Thread by =?Utf-8?B?cmFuZHkxMjAw?= | last post: by
1 post views Thread by Ryan Krauss | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.