John,

>Where talking keys here, primary keys right. Thank you very much, but I think using either int or char will work just fine.

This is not up to me, but up to the current implmentation of existing databases.

>If you have some other type of key requirements, my guess is that char once again, will work. As for timestamps, I don't see how that make a good key.

Well, i've seen them. I can't change the existing database, so I'd have to live with the current implementation.

>I think you have over-complicated this one. And yes, I am wide-awake on this one.....

Over complicated ? I don't think so. These situations are quite frequent in my case. I guess it has to do with the way I design applications.

>Wrongo....

Let's keep this conversation constructive. Offensive behaviour is certainly not of any benefit.

>The code is in classes that implement the interface of an abstract class. Also, you keep hanging on to your inheritance hammer here, which is the wrong tool. Here is a good for you regarding multiple interfaces.

At a second look at your code, I saw what you did. This is one concept of simulating inheritance. I've seen comparable code to implement multiple inheritance within VFP. This certainly is not inheritance but is a workarround to acomplish simular behaviour. I'd never would implement a class this way. I'd really do the real thing.

>Lets say I have an abstract entity class and an abstract printing class. I can write a customer class that implements both the abstract entity interface and the abstract printing interface. Try this in VFP, and tell me how far you get.

See my remark above, about multiple inheritance. Within VFP we could do the same thing. If we would have multiple inheritance, I would use it, not the workarround.

>>>How did this evolve to an argument on encapsulation. Based on your design, let's say I needed to query the type of data your key generator produces, before it actually produces a key. How would I do that?

>>Why do you wan't to query that ? If you do, just make an extra method or property.
>>
>
>Thats bad, very bad design. What you are saying is that your interface needs to change. No Thank-You...

Did I change the interface ? No, certainly not. I did enhance it. Your remark doesn't make sense at all. I'm free to add functionality for every subclass I make.

You implied that your code has nothing to do with inheritance, but it does. It's just a workarround to program inheritance within VB commands. Therefore your remark that inheritance plays no role for whatsoever in the middletier holds no water.

As an experienced OO developer I would never go for this solution. It requires more coding, is less readable and less maintainable. Therefore I'd choose for real inheritance.

>>This example was taken from an error handling mechanism on a 2 tier system, but the same aplies to the middle tier in combination with the UI tier, though it's a bit harder to implement.

>No it's not. The middle tier just needs to send the correct messages. It is up to the UI-Tier to act on those messages.

It's the goal for each developer to make the solution as transparent as can be. Therefore it should make no difference if a solution was build with 2 or 3 tiers (or more). Binding yourself onto the implementation is generally a very bad thing. So in my examply the middletier detects the error, provides information about the error, or tries to solve it on it's own. The UI layer provides the communication to the user. within a 3 tier system this is harder to accomplish than within a 2 tier system.

>>I Guess, you never read Alan Cooper, About Face. Some errors can be solved at runtime by your application, if it's possible: handle it. Don't make the users pay for your weak design. Also when an error occurs don't display some errorbox like: Syntax Error in line xxx. the user can't possible understand what went wrong. Before showing your errors to the user, make them understandable and give the user clear options to what to do next.

>Please be careful about making cites like this. They can come back to haunt you.

why?, please explain.

>In fact, a failed lock or trigger failure is not really an error. It is really a resource conflict issue. It happens to be reported as an error, but it is not a fatal one. Obviously, a failed lock is something that can occur at any time. And yes, I have read Alan's book.

I don't believe this is relevant here.

>I would argue that anything that could be solved by your app is not really an error. Here is another one, File Not Found. Is it an error? Or is it an exception? There is a difference here. Often, we end up dealing with and working around exceptions. Eventough they may be reported through the same mechanism, exceptions and errors are different.

Let's say your connection to the remote database is lost for whatever reason. The middletier could detect this error and try to create a new connection and resume operations.

>>Yep, i've got that hat on, but It's not an issue of thinking out of the box, but rather: Is there room to think out of the box ? I can handle C,C++ and VFP. I can't possible think into VB, if I just don't have time for it.

>This statement makes no sense whatsoever....

Why not ? I don't have the resources to even consider using VB. Therefore I do have no other alternative than C/C++ and VFP.

>OK... Please provide me with an example of how inheritance helps you with code resuse.

See the diagram JimB drew from my example of security.

>If you find yourself overriding method code, and then invoking default behaviors, you are not really using inheritance. Rather, you are working around it.

I don't have a clue what you're trying to say here.

>Also, if you are such a pureist, you would not be so quick to have design whose extensibility model is built around adding new properties and methods. The whole concept of programming to an interface is kind of lost there, isn't it.

No, it isn't! If I've got a formclass, I can make a subclass with additional objects on it. Isn't this inheritance ?? The derived class supports everything the baseclass would. The derived class on the other hand can be more complex. If this isn't inheritance, i'm Bill Clinton.

>>That's a very odd statement you're making for someone with your reputation. Can you clearify yourself. I'm sure many OO purists are very curious to your statement.

>First, I don't give a crap about OO purists.

You sound aggresive. There is no need to do so. This is only a discussion. This is by no means a contest of who's being right.

>Second, instead of tossing what I have said about INTERFACES NOT INHERITANCE side, put some thought into it. I am not saying to give up inheritance. Rather, I am saying there are some alternatives out there.

Alternatives to simulate inheritance. Yeah, now i do understand your point that VB middle tiers can be build up in a simular way as with VFP. Nevertheless my point is that inheritance *CAN* play an important role within middle tiers.

>Being a purist might be your biggest handicap...

or biggest advantage, as long as you're open to other technologies, reason and fact.

>Keep in mind the only OO element missing from VB is inheritance. In the scenarios you list, inheritance would not be the right course of action IMHO.
But, you have your approach, and I have mine.

Yes, I have.

>Please.... Go look at the code I posted about interfaces and how they are implemented in VB and why implementing interfaces is a better approach to what you are attempting to accomplish.

Where can i find it ? I will have a look and will provide you my comments.

Walter,