>Walter,
>
>>When using a framework, you can't anticipate on all possiblities. Often it is not desirable to have all functionality within your classes (specifying datatype as property or parameter). OO keeps you framework classes lightweight, only specifying the general, You can add functionality by using inheritance.


>Placing the VFP vs VB issue to the side for a moment. Inheritance is the single most overused and misused feature of OO.

I've got another opinion: Inheritance is overused because everybody like to talk about it, but few people do use it properly. If you've ever spoke to a OO purist, you'll know what I mean. Let them show your OO design and they 'll laugh at you. In some cases they're overdoing their job, but many times they're right.

>Your example is much better served using composition at runtime to place behavior clases in the application class.

If your talking about the errorhandling object: it's ON the applic class.

>Inheritance should ONLY be used to provide a consistent interface to the class of objects.

I'm sure, by interface you mean, methods, properties and events. Yes, you're right. Doesn't this also apply to components build out of framework classes ?

>The various differing behaviors are not provided through subclassing a class and altering the behavior, it is instead a subclass of the abstract (a sibling to the other object) with different behavior.

I'm changing the class because of other implementations: like securiry on a Novell network instead of a NT network. Taking the NT security object as the base class, and derive all other networks from it, i'm doing nothing wrong IMHO. (Except maybe that the NT sec class should be on the same level of the others and that there should be a more general baseclass. In this cases you've got to do more reasearch at forehand).

>>Also OO hides the actual implementation of the original (thus not the derived) obejcts. This kind of information hiding is IMO very important.

>Information hiding has been a part of software development since structured programming was in vogue.

It does, but this also applies to OO. Objects are evolved from structures.

>>I'm refering to handling specific errors: For Example, if a trigger fails, it can popup a dialog providing information about why the trigger failed and provide any mechanism to solve the problem. For Locking problems, you can provide the user information that someone else has the record in use, and ask if the user wants to wait or discard the funtion. This advanced kind of error handling *CAN* be very solution specific, to overwrite specific error handling for a particular error OO might be of added value. See the implementation of the following errorhandling object
>
>I would disagree here with the idea of using error handler objects. First, for me, it philosophic; an error is an unanticipated situation (if it was anticipated why diodn't the code handle it without the error ever occuring). As an unanticipated event, the ability to predict the impact of the error on the running system is at best a coin toss. Therefore, if an error occurs, I shut down the system as gracefully as is possible with very few exceptions.

I'm sure you read ALAN COOPER, About face. In my case I try the solve error before they where reported to the user. This can be a very daunting task, and is very solution dependend. To advance my error handling I went for the solution with Error objects.

>>>>Another feature used in middle tier, is handling application security. I've got framework classes which take care of this. To have maximum flexibility to implement security It might be handy to use subclasses. If you want to use your own or Novell security data instead of the standard NT security subbclassing is a great mechanism to accomplish that.
>
>Again, using classes is a great way, but subclassing? I don't think so. I think a well designed security system would be a composit of many classes each providing its own level or type of security. The objects involved would not be subclasses but rather siblings of each other.

Note that i'm using general framework classes, which has to be adjusted for the given solution. Isn't this RAD ? I'm sure we'd agree if the middle tier was written exclusively for a particular solution. Then there would be no need to inherit anything.

>>Well, I do not intent to implement all possible NOS into one frameworkclass. I'd rather choose for a lightweight class, which of couse can be subclassed for a particular solution. This is just the strenghts OO offers. Adding functionality to one class to cover all variations is not according to OO philosophy. In general your approach will require more maintainance, is more complex and less readable to the end-programmer.

>I don't believe John is talking about NOT using OOP. He is talking about the fact that VB is a valid and valuable tool for development and that we, in this forum, always seem to dismiss it out of hand as having no value at all.

I did get that message, BUT his statement that inheritance has no value for the middle tier, I find offensive. I simply do argue this single statement.

>As I said above, inheritance is the single most overused and abused aspect of OO. Using inheritance to specialize behaviors leads to a heirarchy that is unwieldy and difficult to support. Needing to trace through class levels to find the particular behavior you're interested in is not what I call fun.

As I said above... No seriously, this a shotcomming of the development tool.. Isn't this solved in VFP 7 ?

>One could make a strong argument that for maintenance, using a method with all of the behavior in it would be easier to keep running, since one doesn't have to search around to find the code.

This violates the OO phylosophy. I'm not willing to choose this path just because of finding the right code at once.

As for the difficulties to find the code: This depends on how the hierarchy was implemented. I'll guess an unexperienced OO developer could make a mess of it. But if it's done properly, this should not be a problem at all as all classes should be well defined. Also I don't believe in solutions with more than let's say 4 or 5 levels. Then this would be a real pain, But when we talk about 2 or 3 levels, i'm sure this argument would hold no water.


Walter,