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: S Perryman on 29 Jan 2008 15:48 topmind wrote: > 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.) I need to provide a type substitutability implementation for the publications example. The example and points made in OOSC2 are sound (and provably so) , but tis better to present something for which you can provide a like-for-like equivalent. So bear with me. > [snipped internal bickering stuff...] Like to give it but don't like to take it I guess. TM>If only objective facts TM>were allowed on comp.object, then there would only be like one post a TM>month. TM>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. Only you seem to know which of your "observations" are subjective. We don't (other than those we routinely debunk - which of course are then neither objective or subjective) . TM>Bull. If you use giant navigational object pointer structures, you are TM>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.) Once again : a set is a set is a set. When I use a set, I usually don't worry about its *implementation* . >>>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. No. One is *stove-piping* because of the "mismatch impedence" that is imposed by moving between data-only type bases, and computational behaviour + data type bases. SP>3. OO does not use *particular implementations* of set theory imposed by SP>certain products, because they conflict with the ADT concept (encapsulation SP>of behaviour + representation) . The desire for an RDB that is compatible SP>with the ADT model (and programming languages thereof) is one that is very SP>strong for experienced OO practitioners. TM>ADT's are not always the right tool. >>ADTs are always the right tool. > (cough cough) unicorns unicorns ... ?? >>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. An *Abstract* Data Type is often not the right "abstraction" for the job. Circular argument for starters. > The mere > existence of an abstraction does not automatically make something better Better is a comparative word. What things (if any) are you comparing the "existence of an abstraction" with ?? > it has to be a *good* abstraction. Which is everything to do with the *subject domain* for which an abstraction is created, and nothing to do with the *core principles* behind using ADTs. >>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. The surprises are not unexpected (performance certainly) . > 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.) All the above is meaningless without a demonstrative example. >>- 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. The words "fitting approach" are meaningless to me. > One of the (multiple) problems with complex "types" is that they are > hard to share across different app languages and tools. Indeed. A type notation that has very powerful semantics may not be supported or practically implementable in certain prog langs/envs. >>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. 1. More non-understanding of English (the term "strawman argument" in this case) . 2. An RDB will indeed be a degenerate case of a relational ADT base. Nothing wrong with that. Degeneracy is good. Degeneracy allows in many cases the most optimal implementation to be provided. But as is well-known, attempting to use degenerate cases to solve a general case is just folly. > 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.) This is meaningless to me. All that is going on is the manipulation of sets of entities. Once I have instances of those sets, I manipulate the entities in those sets. What "navigational hoppity" has to do with this manipulation (or actually means in English) , God knows. [ snip ... ] > 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. Search for "OSI network management" , CMIS (or CMIP) , GDMO, "X.700" . Examples of an object tree may be around on the Net. Regards, Steven Perryman
From: topmind on 29 Jan 2008 18:16 S Perryman wrote: > topmind wrote: > > > 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.) > > I need to provide a type substitutability implementation for the > publications example. The example and points made in OOSC2 are sound (and > provably so) , but tis better to present something for which you can > provide a like-for-like equivalent. So bear with me. > > > > [snipped internal bickering stuff...] > > Like to give it but don't like to take it I guess. > > > TM>If only objective facts > TM>were allowed on comp.object, then there would only be like one post a > TM>month. > TM>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. > > Only you seem to know which of your "observations" are subjective. > We don't (other than those we routinely debunk - which of course are then > neither objective or subjective) . Generally before I make an issue of it, I ask. Example, "Can you provide objective evidence of that?". Don't complain about ambiguity, instead ask questions. That is the more diplomatic way to do it. We should strive and practice to be more diplomatic, otherwise we'll be outsourced. I often want to call you lots of names, but I resist because it creates bad general habits. > > > TM>Bull. If you use giant navigational object pointer structures, you are > TM>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.) > > Once again : a set is a set is a set. > > When I use a set, I usually don't worry about its *implementation* . I haven't worried about implimentations of set operations much since college projects. Like I said, most of the tools we use these days are not low-level. However, some language and tools have better built-in support for sets. And RDBMS standardize it. You could implement sets in OOPL's, but you'd be rolling your own and it would probably be different from some other OO developer's rolling their own. RDBMS bring some standardization to common attribute and collection handling idioms. It's called "reuse". > > > >>>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. > > No. > One is *stove-piping* because of the "mismatch impedence" that is imposed > by moving between data-only type bases, and computational behaviour + data > type bases. In otherwords, wasting time and code translating between paradigms. And I reject your "computational behavior" characteristic of anything non-ADT. ADT's are one abstraction technique among MANY. > > > SP>3. OO does not use *particular implementations* of set theory imposed by > SP>certain products, because they conflict with the ADT concept (encapsulation > SP>of behaviour + representation) . The desire for an RDB that is compatible > SP>with the ADT model (and programming languages thereof) is one that is very > SP>strong for experienced OO practitioners. > > TM>ADT's are not always the right tool. > > >>ADTs are always the right tool. > > > (cough cough) > > unicorns unicorns ... ?? > > > >>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. > > An *Abstract* Data Type is often not the right "abstraction" for the job. > Circular argument for starters. Existence of abstraction and helpful abstraction are not necessarily the same. > > > > The mere > > existence of an abstraction does not automatically make something better > > Better is a comparative word. > What things (if any) are you comparing the "existence of an abstraction" > with ?? I don't understand the question. Please restate. I don't know of any objective way to measure abstractness at this point. Code size is one suggestion, but has lots of traps. I tend to focus on what makes code maintenance easier rather than dwell on measuring abstraction. We can get into techniques for measuring "easier maintenance", but lets finish this first. > > > > it has to be a *good* abstraction. > > Which is everything to do with the *subject domain* for which an > abstraction is created, and nothing to do with the *core principles* > behind using ADTs. I do tend to agree. One tends to create little "micro-languages" for the domain at hand when engineering a solution. Whether these micro- languages are based on relational views, stored procedures, subroutines, OO classes, ADT's, or a combo is what the big fight is about. I tend to think it is largely subjective. I feel that a set- centric approach is more flexible than a type-centric approach, but cannot objectively prove it just yet. At least it has not been shown worse, and given all else being equal, I'll go with my preference. > > > >>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. > > The surprises are not unexpected (performance certainly) . > > > > 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.) > > All the above is meaningless without a demonstrative example. Show me a rank-and-file biz app that you think ADT's would do better at. Or, use the library or payroll example since we are already digging around those. > > > >>- 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. > > The words "fitting approach" are meaningless to me. > > > > One of the (multiple) problems with complex "types" is that they are > > hard to share across different app languages and tools. > > Indeed. > A type notation that has very powerful semantics may not be supported > or practically implementable in certain prog langs/envs. So we can both agree that a type-centric approach tends to make information sharing more difficult across different 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. > > 1. More non-understanding of English (the term "strawman argument" in this > case) . > > 2. An RDB will indeed be a degenerate case of a relational ADT base. > > Nothing wrong with that. Degeneracy is good. > Degeneracy allows in many cases the most optimal implementation to be > provided. But as is well-known, attempting to use degenerate cases to > solve a general case is just folly. Demonstration, please. Otherwise, this is meaningless. > > > > 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.) > > This is meaningless to me. > All that is going on is the manipulation of sets of entities. > Once I have instances of those sets, I manipulate the entities in those > sets. > > What "navigational hoppity" has to do with this manipulation (or actually > means in English) , God knows. Links between objects tend to follow the "navigational" model. The messes it creates are largely what motivated Dr. Codd to find a cleaner solution. All OO changed since the late 60's is putting behavorial wrappers around the nodes. However, this did little or nothing to change the original problem. > > > [ snip ... ] > > > 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. > > Search for "OSI network management" , CMIS (or CMIP) , GDMO, "X.700" . > Examples of an object tree may be around on the Net. Maybe after the library and payroll examples are cooked. > > > Regards, > Steven Perryman -T-
From: Robert Martin on 31 Jan 2008 16:56 On 2008-01-11 06:07:51 -0600, alexcpn <alexcpn(a)gmail.com> said: > Maybe I should frame the question more clearly- what is it so special > in OO that makes it so successfully industrially. I really don't > 'believe' that it is because of the way OO entity help us in closely > modeling real life etc > > Is it the Open Closed Principle > Or is it because there are not many choices OO languages, like Java, C#, C++, Ruby, Python, Smalltalk, etc, are more successful than procedural languages like C, Pascal, etc. because they allow more options for partitioning source code and managing the dependencies between modules. The prime benefit of OO comes from the ability to put code into meaningful partitions, and minimize the dependencies between those partitions. That is, after all, what the Open Closed principles is all about. Indeed, that's what all the S.O.L.I.D. principles are about. -- Robert C. Martin (Uncle Bob)��| email: unclebob(a)objectmentor.com Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com The Agile Transition Experts��| web:���www.objectmentor.com 800-338-6716� � � � � � � � ��|
From: Robert Martin on 31 Jan 2008 17:02 On 2008-01-11 10:49:28 -0600, "Daniel T." <daniel_t(a)earthlink.net> said: > Rather than beat myself up > looking for the bug, I replaced the code and used a string class. That > increase in abstraction reduced the complexity of the code in every > measurable way and fixed the bug. > > Note, the above has nothing to do with polymorphism. It also had little to do with OO. You could just as effectively used any good string library. OO does not, in and of itself, present a higher level of abstraction. Any abstraction I can create in an OO language can also be created in a procedural language. What OO *does* provide is an easy way to make the abstractions independent of the implementations. That's something that's relatively hard to do in a procedural language. -- Robert C. Martin (Uncle Bob)��| email: unclebob(a)objectmentor.com Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com The Agile Transition Experts��| web:���www.objectmentor.com 800-338-6716� � � � � � � � ��|
From: topmind on 31 Jan 2008 17:13
Robert Martin wrote: > On 2008-01-11 10:49:28 -0600, "Daniel T." <daniel_t(a)earthlink.net> said: > > > Rather than beat myself up > > looking for the bug, I replaced the code and used a string class. That > > increase in abstraction reduced the complexity of the code in every > > measurable way and fixed the bug. > > > > Note, the above has nothing to do with polymorphism. > > It also had little to do with OO. You could just as effectively used > any good string library. > > OO does not, in and of itself, present a higher level of abstraction. > Any abstraction I can create in an OO language can also be created in a > procedural language. What OO *does* provide is an easy way to make the > abstractions independent of the implementations. That's something > that's relatively hard to do in a procedural language. Can you demostrate that with your own payroll example? Now you have some runnable procedural code to compare it to: http://www.geocities.com/tablizer/payroll2.htm > > -- > Robert C. Martin (Uncle Bob) [...] -T- |