A base form with partial implementation? Can this be done?

[zachattack05]

Hi again!

I was hoping someone would be kind enough to throw some advice my way here.

I'm working on an application (still) that I would like to provide "Wizards" in. I have a general idea of how I would like to implement something like this, but staying in line with OOP, I would like to have a base class that derives from a form (basically a form) with some standard controls, buttons, progress bar, and a "canvas" area for the wizard steps to show.

The idea is that I would have a single form that would act as the base of the wizard, or the Host. This form would be partially implemented having some methods that cannot be overridden so that basic functionality applies to all wizards.

The developer would then, if a wizard was needed, create a new form that inherited from this partial form. Certain properties could be set (like the text to show on the buttons, whether or not to allow canceling out of a wizard, should a progress bar be visible etc while others could not be.

When the developer creates the inherited form, just like an interface, they would need to implement the "interface" of the form they inherited from.

I hope this makes sense...

Another way of saying it would be that I would like to create a form that has certain methods and properties, some that can be overridden and some that cannot. The form is not fully implemented though, only partially. The forms that derive from it would need to finish that implementation for it to be useful.

I've been reading about Abstract classes and the like and it seems like this may be what I am looking for, but I don't know. It seems like abstract classes cannot implement anything which is only part of what I am looking for.

Any ideas or suggested readings?

[Momerath]

Using the sealed modifier you can prevent someone from overriding your methods.

And, of course, using abstract will force them to implement a method. virtual will allow them to override, but not require it.

[zachattack05]

Momerath,

Yeah, that's true. But can an abstract class contain methods that are already implemented, and contain methods that are not implemented, but would need to be implemented by the classes that inherit it?

For example, the "base" wizard class would contain methods that would load, sort and process the showing and navigation of the various steps. These methods would already be written, the classes/forms that inherit it wouldn't need to implement those methods, and in fact should be an error if they try to.

Here's an example:

Let's say we have a form called BaseForm. It has a method called BaseFormMethod() . The BaseFormMethod() is already implemented and is sealed. However there is also a another method called LoadSteps(IWizardStep[] stepArray) which is NOT implemented in BaseForm, it is just an empty method.

Now, we have another form called SomeWizard which inherits from BaseForm. I want SomeWizard to have to implement the method LoadSteps(IWizardStep[] stepArray) on its own, but NOT implement BaseFormMethod() because it is already implemented. The SomeWizard form can call BaseFormMethod() and LoadSteps() simply by calling it like normal, but the developer would not have to write the BaseFormMethod() because it was already written and is automatically in ALL wizards that are inheriting from BaseForm, and by changing the BaseFormMethod() in BaseForm, all of the Wizards that inherit from it would also change without making any modification to those forms individually.

So it's kinda like, I need a form that has x, y and z methods already written, that are sealed and any form that inherits from that one, automatically has access to methods x, y and z, but also, by simply inheriting from that base form, must also implement a, b and c methods on its own. Kinda like an interface that has a few methods already written and are sealed.

Does that make sense?

[zachattack05]

Strike that!

I re-read your post and re-read the MSDN docs.

Looks like abstract classes can have abstract methods and normal methods...For some reason I thought they couldn't, but I guess that would make them interfaces instead...my bad.

Thanks as always!

[Momerath]

but I guess that would make them interfaces instead...my bad.

This is actually a debated topic: When should you use an Interface vs using a pure Abstract class.

I use interfaces to add functionality to a class (IComparable, IEnumerable, ISerializeable, etc.) but the functionality doesn't 'care' what the class represents and pure abstract when it represents an object, but not something that you'd instantiate (Animal class vs Horse class, Dog class, etc.)

[zachattack05]

I actually thought that an interface was a "tool" to create a bridge between one object type and another and make things that otherwise are completely unrelated, related. Like a Japanese speaking person learning English, and a French speaking person learning English and the both of them meeting in the United States to conduct business together in English. English allows the two of them to conduct business though an "interface" of sorts. If both don't use or implement English, then they really can't conduct business together except on a very basic level (public and static methods etc...). If both knew English then they can conduct business easier. But since one doesn't know the others native language, they can only use the tools provided by the interface.

An abstract class to me appears to be a new base to start from. The reason the two people above had to use an interface to communicate is because the languages are different, but every language shares some of the same basic rules (abstract). These basic rules are rules that every language must follow, but Japanese and French evolved separately and can continue to evolve over time, but they both still share the same exact rules that they originally started with.

Is that right? I don't see how there could be debate if that is correct. An interface and an abstract object to me are totally different and serve totally different purposes.