>Hi, Walter.
>
>How was your week-end?

Busy, My son got 4 year old yesterday, so I have not touched a computer yesterday. Yours ?

>>>I understand what you mean, but for me, that violates OOD principles. Indeed, typing is one of its tenets, and that's why strong typing is so important to me. Types convey a lot of information, and provide for the necesary abstraction. In your example, you're being explicit instead of polymorphic.
>>
>>Ehh, I don't think so. If you do a DO CASE and get the type of the object and cast this opject into this type (or interface) before calling a method or accessing a property, you're indeed beeing explicit.

>Uhhh... Very different schools here, I guess. For me all that is violating encapsulation. I'm an annoying Agile zealot, and all what you're proposing is against most Agile design principles, but this is not so easy to explain. I'm writing a series of articles on the subject for UTMag, so maybe it could be good to leave this discussion on hold until you read this stuff. I'd be glad to get your criticism about this.

Don't get me wrong. I agree with your observations that it violates OO priciples (I've been burned for that on university for exactly doing this).

>>However, If you just check if a method or property exists and then access it, polimorphism still applies: From the code there is no way to tell which class implementation is used. The object itself does determine that.

>Nope. For me, checking for something is neglecting the invariants of a class. If you received a mamal, for example, you already know what kind of operations you can apply to it; if you receive a kitten, you know you can apply all the same, plus a few others.

Ehh, I don't mean that. If I recieve an object I can check if a certain method does exists. For example: Fly(). Now the object can be a mamal, amphibian, bird, insect, fish. And of course it can be any subclass of that. For example a fish generally does not fly, except if it is a flying fish. Now I can define that the object received is of type animal which does not have the fly method implemented. Now I can check if the object does have fly method and call without exactly knowing if the object is a birth, insect, fish or mamal, it does not know if it is a flying bird, flying bird or a bat. Calling the method IMO, still is a polymorphic action.

>>I'm beginning to suspect that we have different starting points here. In application development the main focus is on data and information flow, following the applications architeactual design (in an iterative manner). The application in first place is a data/information management system. The domain logic is of secundary importance and is build upon the first.

>You're right about the different starting points. For me the key is the domain model (as you say below, data and logic), but what I'm giving less importance is the actual persistence of this data (i.e: the database model). I recognize this is important from an architectural standpoint, but is not my main concern -usually.

>>I also realize that the difference my be in the type of application. In situations where the domain logic is rather static (e.g. financial, bookkeeping) the focus is more on the domain logic. When doing process controls, scientific analysis when the domain logic itself is far less static (as new techniques or better processes are introduced), the domain data and information is far more static (though new column will be added all the time).
>
>Of course it has to do with the type of application. I'm working now in a project involving data-marting, and we are having a great debate about the underlying data model, because here's a big issue about performance (concetrating many different corporate data sources with different latencies and response times), but once we agree on the general terms to set the architectural guidelines, we'll move on and stop paying so much attention until the fine-tuning time comes.

Walter,