John:

Finally something I agree 110% with you!! Most developers should read Design Patterns to get an idea of what decoupling strategies exist out there. I read the book two and half years and I built a VFP framework based on delegation (everything is send to behavior objects). The biggest adavantage of my framework is that I can translate it (or parts of it) very easily into VB, Powerbuilder, Delphi, or whatever when needed!! Doing multi-tools is not even difficult anymore...

Daniel

-----------------------------------------------------------------------------
We must decouple the knowledge from the tool....

This is not to say that general theory in a vacuum is good either. It still needs to be applied. Certainly, there is a fine line...

With respect to inheritance, I found that if I first understood what inheritance does, and then look at it from VB's terms, then I had a chance at survival. In VB, they key is delegation.

Let me explain...

In VFP, lets say you have a button on a form that saves data. No doubt, there are all kinds of implementations of this in VFP apps around the world. Some folks may have used inheritance to inherit calls to a VFP class that actually does the work. Others may have bound the logic in the UI, still using inheritance. They common denominator of course is inheritance.

In VB, how would you accomplish the same task? They key is delegation.

OK, I have a form with a button that needs to save data. The save process is very generic. Yet, I don't have inheritance to help me here. What I do have is a dataclass of sorts that has the ability to save data. In a call, I could have the button send an instance of a data object to a save method and have it do the work. The data object in this case is a member of the form. Believe it or not, this is a case where lack of containership is nice.

Let's say that the name of the data object was called oData. In a form, I could reference the member like this: me.oData. Or, I could just reference it as oData. And, in the button, all I need do is reference it as oData.

We have come up with a way of having having behavior objects in VB that sit and wait for something to do. A button on a form that either adds, deletes, edits, saves , or cancels changes to data calls the same object.

The key to take from this is that while it is not inheritance, the ends are the same. There is next to no duplicated code. Through the use of ActiveX controls, I could create a situation where there is zero duplicated code...

Again James, the key is to first decouple the knowledge from your knowledge of VFP. Then, look at things on VB's terms and reconcile the two. Even if it is something else like C++, Delphi, or whatever, you will need to do the same thing.