Why is Object Oriented so successfull
in [OOP]
|
Prev: Proxy pattern: remote chat proxy and interfaces
Next: Derived class calling overriden base class methods
From: Patrick May on 19 Jan 2008 18:00 ram(a)zedat.fu-berlin.de (Stefan Ram) writes: > Patrick May <pjm(a)spe.com> writes: >>>he just states the action by a "verb" with a type and the >>>programing language will then make sure, that the correct >>>implementation is called for any given object at run-time. >>This definition excludes C++ and Java, at least, from the set >>of OO languages, unless dynamic casts are used in C++ or >>reflection is used in Java. > > Run-time polymorphism is possible in both languages > without casts or reflection. So, what do you refer to? [ Sorry for the delay in replying, work got in the way of Usenet this week. ] I was replying to the previous part of your definition: >> This is called �run-time polymorphism� or �late binding�. >> Individual object-oriented programming languages might >> include additional support for object-oriented programing, >> but this binding is the core feature of every object-oriented >> programming language. Java does allow some run-time polymorphism, but does bind variables at compile time (early rather than late). When reflection is used, late binding is required. Consider this: String string = "foo"; string.bar(); which fails at compile time, versus this: String string = "foo"; string.getClass().getMethod("bar",null).invoke(string,null); which fails at run time. Regards, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | Large scale, mission-critical, distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: Patrick May on 20 Jan 2008 11:32 ram(a)zedat.fu-berlin.de (Stefan Ram) writes: > Patrick May <pjm(a)spe.com> writes: >>>>This is called �run-time polymorphism� or �late binding�. >>>>Individual object-oriented programming languages might >>>>include additional support for object-oriented programing, >>>>but this binding is the core feature of every object-oriented >>>>programming language. >>Java does allow some run-time polymorphism, but does bind variables at >>compile time (early rather than late). When reflection is used, late >>binding is required. Consider this: > > We can agree to ignore reflection, because it is usually used > in Java only as a last ressort, when the �normal� language fails. > > Late-bindings does not require variables, but objects, > identifiers and expression. It is possible in Java. I understand your definition better now. My original response was based on the fact that Java performs some binding at compile time and some at run time. It is not a fully late binding language. Regards, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | Large scale, mission-critical, distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: topmind on 24 Jan 2008 23:47 frebe wrote: > > 1. having a set of related entities, all/some having the same > > properties, and each having properties specific to itself. Users of > > the entities may wish to reference instances of the set as an entity > > that has properties in common, or as the specific entity type. > > create table vehicle ( > vehicleid integer, > name string, > primary key (vehicleid) > ) > > create table car ( > vehicleid integer, > engine_volume double, > primary key (vehicleid), > foreign key (vehicleid) references vehicle (vehicleid) > ) > > careate table boat > ( > vehicleid integer, > propellercount smallint, > primary key (vehicleid), > foreign key (vehicleid) references vehicle (vehicleid) > ) > > > 2. changing the properties of any member of the > > set, without affecting/impacting the other members (interface, impl) . > > update vehicle set name='Boat' + name > where vehicleid in (select vehicleid from boat) > > > 3. changing the representations (impls) of any member of the > > set, without affecting/impacting the other members (interface, impl) . > > alter table boat modify propellercount integer > > > 4. changing the code written by users of the entity set, whenever the > > members of the set changes. > > Function pointers > > > 5. correctness (being able to confirm the attempted use of properties > > � �that do or do not belong to members of the set) . > > update car set propellercount=5 where vehicleid=3 > > will case [cause] an error > > //frebe Personally in practice I would be more inclined to include all vehicle properties in one table, and have a set of indicator(s) to indicate which kind of vehicle it is. This way, if hybrid boat/cars or the like come along or something unexpected, fewer changes have to be made. Triggers or constraints could do the checking instead of existence. Then again, it depends largely on the business at hand. Government vehicle registries may experience very little major change over time. However, a fashion-savvy company that designs mall doodads may change entity configurations so often that a more flexible approach is warranted. It is hard to make the proper choice without having a feel for the business. -T-
From: S Perryman on 29 Jan 2008 05:34 topmind wrote: > On Jan 18, 10:04 am, S Perryman <q...(a)q.com> wrote: SP>I've experienced a lot of complaints about "procedural/relational" SP>failures too. Some I have been first-hand witness to. TM>A lot of the times it is just bad programming/design, or limiting TM>tools. For example, Oracle is kind of stiff and bulky for projects TM>that need to be nimble. That is not the fault of relational in TM>general, but a misapplied vendor's product. >>And a lot of the time it is the paradigm itself being used for something >>it is not best suited for. > Unicorns unicorns unicorns. >>>Are we comparing bad OO to bad P/R? >>Are we comparing 'good OO' to 'good P/R' ?? No answer to this one. Or in topmind speak : Unicorns unicorns unicorns. TM>I'd take bad P/R over bad OO TM>because bad P/R tends to be more predictable in where it goes wrong. >>Of course, you have *objective* evidence that all of the rhetoric above >>is anything other than an ignorant, uneducated rant ... > No, that is a personal observation/anecdote. Of what ?? Real systems that you have implemented using OO ?? The source code of systems implemented using OO, that you have read first-hand ?? > If only objective facts > were allowed on comp.object, then there would only be like one post a > month. > At least I know when my observations or opinions are not objective > info. As evidenced by the reams of "IMHO" etc we can find littered in your umpteen postings (LOL) ... [ Robert Martins' payroll system stuff snipped - dealt with elsewhere ... ] >>2. OO does take advantage of set theory, because it is *orthogonal* to >>set theory. > Bull. If you use giant navigational object pointer structures, you are > NOT using direct sets. You obviously don't understand set theory. There is no such thing as "direct" sets. A set is a set is a set. In a computer system, the concepts of set theory have to be *implemented* in a computer-executable form. The choice of implementation is chosen as appropriate for a systems' needs. > Using both is likely unnecessary duplication. Which of course is a meaningless statement. >>3. OO does not use *particular implementations* of set theory imposed by >>certain products, because they conflict with the ADT concept (encapsulation >>of behaviour + representation) . The desire for an RDB that is compatible >>with the ADT model (and programming languages thereof) is one that is very >>strong for experienced OO practitioners. > ADT's are not always the right tool. ADTs are always the right tool. Because ADTs present their properties in an implementation-independent form. A user of any instance of an ADT T cannot make the following assumptions : - whether each property of T is implemented in terms of data (variables etc) , a computational process (algorithm etc) , or both. - that all instances purporting to be of type T implement their properties in the same way. Given this, degenerate cases are possible, and allowed. For example : - all properties of T are implemented solely in terms of data - all instances of T share the same implementation Do you recognise this degenerate case ... ?? > If you don't mind, I'd like to see some sample data. It may help > clarify some of the domain lingo. No problem. 1. Entities Managed Resource (some properties) Equipment (some more properties) IS A Managed Resource Network (even more properties) IS A Managed Resource Line Card (yet more properties) IS A Equipment Connection (god, more properties) IS A Managed Resource Endpoint (bloody hell) IS A Managed Resource PSTN Endpoint (you're having a laugh) IS A Endpoint PSTN Connection ... 2. Tree construction node : parent = E1 (entity type 1) , child = E2 (entity type 2) So a node would be : some E1 (parent) --- any number of E2 (children) But not quite that simple. The node template specs allows for any entity type that is also an instance of E1 *or* E2. So you can have the following forms of template : n1 : parent = Connection, child = Endpoint n2 : parent = Connection, or any entity which ISA Connection child = Endpoint n3 : parent = Connection, child = Endpoint, or any entity which ISA Endpoint n4 : parent = Connection, or any entity which ISA Connection child = Endpoint, or any entity which ISA Endpoint So a tree constructed from n1 : Connection --- Endpoint from n2 : Connection (or PSTN Connection, or ... ) --- Endpoint from n3 : Connection --- Endpoint (or PSTN Endpoint, or ...) from n4 : Connection (or PSTN Connection ... ) --- Endpoint (or PSTN Endpoint ...) So, according to the templates used for real, the tree is going to contain at least 2.5 million nodes. > And I repeat, most non-trivial biz > apps cannot effectively use hierarchical subtyping. Proven wrong by the numerous real-world OO implementations of the problem (and its kin) that I have given you. > It WILL become a mess Proven wrong by the numerous real-world OO implementations of the problem (and its kin) that I have given you. Regards, Steven Perryman
From: topmind on 29 Jan 2008 13:29
On Jan 29, 2:34 am, S Perryman <q...(a)q.com> wrote: > topmind wrote: I see Perryman's back. (I am curious to see your response to your "combinatorial explosion" claim with regard to the library (publications) example in a nearby sub-thread.) [snipped internal bickering stuff...] > > > If only objective facts > > were allowed on comp.object, then there would only be like one post a > > month. > > At least I know when my observations or opinions are not objective > > info. > > As evidenced by the reams of "IMHO" etc we can find littered in your > umpteen postings (LOL) ... I am not sure what your complaint is here. > > [ Robert Martins' payroll system stuff snipped - dealt with elsewhere ... ] > > >>2. OO does take advantage of set theory, because it is *orthogonal* to > >>set theory. > > Bull. If you use giant navigational object pointer structures, you are > > NOT using direct sets. > > You obviously don't understand set theory. > There is no such thing as "direct" sets. A set is a set is a set. > > In a computer system, the concepts of set theory have to be *implemented* > in a computer-executable form. The choice of implementation is chosen as > appropriate for a systems' needs. It is true that pointers can be represented as sets and visa versa ("representionally equivalent"). However, dealing with them via "set math" is often easier than dealing with them as object pointers (graphs), which OO generally leans toward. (I thought this was implied, but I guess some misinterpreted it.) Even in RDBMS, one can do a form of "pointer-hopping" if they really want (or for special needs), but usually one uses the query language. > > > Using both is likely unnecessary duplication. > > Which of course is a meaningless statement. If one has to copy data stuctures or classificationis from an RDBMS into RAM-based OO objects, then one is generally doing a form of duplication. One is "mirroring" a structure that already exists in one paradigm into another. > > >>3. OO does not use *particular implementations* of set theory imposed by > >>certain products, because they conflict with the ADT concept (encapsulation > >>of behaviour + representation) . The desire for an RDB that is compatible > >>with the ADT model (and programming languages thereof) is one that is very > >>strong for experienced OO practitioners. > > ADT's are not always the right tool. > > ADTs are always the right tool. (cough cough) > Because ADTs present their properties in an implementation-independent form. One can argue that any application programming language is "implementation independent" because one is dealling with a high-level programming language: the app language and not machine language. An app programming language *is* an abstract interface already. ADT's are often not the right abstraction for the job. The mere existence of an abstraction does not automatically make something better; it has to be a *good* abstraction. > > A user of any instance of an ADT T cannot make the following assumptions : > > - whether each property of T is implemented in terms of data (variables > etc) , a computational process (algorithm etc) , or both. Relational views and stored procedures can be the same way (although vendors often don't support it well). In practice, hiding too many levels of computation indirection creates unexpected surprises in both performance and tracability. In my experience, it generally is better to create user/deparment-specific computations/views rather than global ones. If doing it in real-time is too resource intensive, then one can do nightly batches. Thus, an abstraction transformation simular to what you describe *is* taking place, withOUT ADT's. (Some even claim that views and stored procedures *are* ADT's, but I'll stay out of that definition catfight.) > - that all instances purporting to be of type T implement their properties > in the same way. And if "types" are not a fitting approach, this is not very relavant. One of the (multiple) problems with complex "types" is that they are hard to share across different app languages and tools. > > Given this, degenerate cases are possible, and allowed. For example : > > - all properties of T are implemented solely in terms of data > - all instances of T share the same implementation > > Do you recognise this degenerate case ... ?? You are calling RDBMS "degenerate" it appears. But, this is a strawman argument, per above. Query features are not *forced* on RDBMS users. One can navigate records in a one-per-one hoppity explicit-loop navigational approach IF you really want/need to. Thus, it is a superset of what OO provides out of the box. (Indeed, there are cases where such navigational hoppity is necessary. Not everything is handled nicely via simple queries, but a hell of a lot is, making it a net gain.) > > > If you don't mind, I'd like to see some sample data. It may help > > clarify some of the domain lingo. > > No problem. [....] I think I would need industry-specific details, such as a definition dictionary/glossary describing these terms to laymen. I don't relate to all these telecom machines and gizmos and so don't know how, if, and when they connect together, among other things. You might as well call them Thingamabob, Doohicky, Widget, etc. without such. > Regards, > Steven Perryman -T- |