I believe I understand why you have a problem

Post #26,337 by ben_tilly 1/29/02 12:53:33 PM Reply	I believe I understand why you have a problem You are unable to understand any OO code unless you have mentally rewritten it in terms of your favoured paradigm, at which point it is a lot uglier than it would be if written in terms of your favoured paradigm from the start. Since you never tried to understand OO on its own terms, you are unable to manipulate its structures directly. Being unable to do that, you are unable to see how to work with things which have been set up in an OO manner. This makes you unable to understand how to use it. Now rather than go on about how much this mental handicap costs your employer, I am going to recommend a non-OO book as a good way to understand it. That book would be Code Complete by Steve McConnell. It is all about practical coding advice to program well in a procedural environment. Whether he is talking about the One True Brace Style or discussing naming flags, he has excellent advice backed up with plenty of references to the literature. Buried in his advice on how to modularize code there is a little section about the benefits of abstract data types. That section does a rather good job of explaining the fundamental principles that make OO a useful way to work, even though he never uses words like "Class" or "Object", and even though he talks about how to use the concept of an ADT in purely procedural code written in a purely procedural language. Pick up that book for everything else in it. But do read that section. After you are done reading that section say the following, A class is a way of implementing an abstract data type, and having data encapsulated in objects is merely a way of keeping data associated with the appropriate abstract data type. There may be more to OO than this (a lot more) which OO people like going on about (mainly because, having learned it, they think everyone else should as well), but that simple idea, combined with the wins listed in Code Complete of using abstract data types, give about 90% of the real win from having OO designs available. (Wins which a bad OO design can easily lose for you, but that is another issue.) Cheers, Ben
Post #26,360 by wharris2 1/29/02 2:35:10 PM Reply	Re: I believe I understand why you have a problem Problem with "code complete" is that he describes a programmatic lifestyle that Microsoft seems not to have embraced. "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
Post #26,396 by ben_tilly 1/29/02 4:04:15 PM Reply	Well, my philosophy says... Their failure to follow their own good advice is no reason for me not to follow it. :-) Cheers, Ben PS That is, of course, if I think the advice is good. Which I do in this case.
Post #26,418 by tablizer 1/29/02 5:27:14 PM Reply	ADT's and Coddlets >> You are unable to understand any OO code unless you have mentally rewritten it in terms of your favoured paradigm, at which point it is a lot uglier than it would be if written in terms of your favoured paradigm from the start. << I won't deny that my head tries to tablize OO structures. However, that is because tables are more grokable and structurally compact IMO. They are lined up in a clean pattern, row and column names are not repeated in each and every cell, etc. They strip out the repetitious packaging crap and are leaner meaner and cleaner. Then I mentally convert the OO relationships into SQL-like relational formulas. That is more compact and abstract than seeing each node's reference to others via a hand-built manual index, as it appears in OOP patterns. >> Being unable to do that, you are unable to see how to work with things which have been set up in an OO manner. This makes you unable to understand how to use it. << It is like going back to hand tools after using powertools. IOW, building "node indexes" by hand; like stringing the wire like Xmas decorations. I have mentally reduced the complexity of GOF patterns into mere simple formulas (more or less), and you want me to go back to bricks and mortar. That is how I see this. How can manually putting up the Xmas decorations be superior to issuing a few formulas to tell the computer (how) do it? Codd was a fricken genius (although it took a few people to clean up his ideas). He found a way to reduce complex patterns into set-based and Boolean-based relational formulas. My software and tables define the pieces (elements), then Codd's magic strings it all together with tiny, easy to change formulas. IOW, the big picture is in the "Coddlets" and not the code structure itself. You don't have to read the entire application to find the underlying pattern; you only have to read the Coddlets and then apply them to the good ol' stable, consistent tasks+schemas p/r model. That is a little bit of an idealistic description, but that is what my head keeps trying to achieve and I cannot make it do a U-turn. Now, with regard to ADT's, Meyer's book had a whole section on ADT's. His primary examples showed how one could hide away the implementation of a simple collection engine (find, add, delete, count_nodes, etc.). IOW, be able to swap out the implementation without affecting the code that uses those operations. One could switch to a linked list instead of say arrays without changing the calling code. Is Code Complete's description of ADT's superior to OOSC2's (Meyer)? If I drop by the bookstore again soon I will take a look. I agree it is an interesting concept. However, I cannot extrapolate such into realistic projects. I have been bathed in plenty of "OO Lore". The problem is that nobody can show me how such concepts make better business applications. I use tables, not arrays and not linked lists (although the post-XBase anti-nimble-table world has forced me back into arrays a little bit), so I don't have to worry about swapping between arrays and linked lists. In custom biz apps one rarely writes different implementations of the same thing (for use at the same time). That would be a waste of money. Thus, there is nothing to "swap out" the implementation of, at least nothing that I actually code myself. IOW, my OO training is reality-deprived. The concepts are cute (at least the first 10 times I heard them), but I cannot find applicability such that they make software more change-friendly than p/r in a demonstrate-able way (such as thru change impact analyses). ________________ oop.ismad.com
Post #26,511 by Arkadiy 1/30/02 10:23:26 AM Reply	Coddlets? Google searc turn up nothing. Could you clarify?
Post #26,533 by CRConrad 1/30/02 12:12:02 PM Reply	From the context: Applets + Codd = "Coddlets". He used Codd's name repeatedly, and the parallel to "applets" is obvious -- well, if you work in a company that markets portal plug-ins as "portlets", it is... So it must mean little snippets, not of code functionality, but of data structure (in this case, TABLE! :-) definitions... Something like that. HTH! Christian R. Conrad The Man Who Knows Fucking Everything
Post #26,553 by Arkadiy 1/30/02 2:19:53 PM Reply	And "little snippets of data structures" make no sence to me
Post #26,590 by CRConrad 1/30/02 5:12:56 PM Reply	Me neither - but don't blame me; it's his concept! :-)
Post #26,890 by tablizer 2/1/02 2:23:51 PM Reply	Virtual Structures >> And "little snippets of data structures" make no sence to me << It is not snippets of data structures themselves, but snippets of specification of the relationships between the base components. IOW, rather than "build the tree" in code like you do in stereotypic OOP, you define a formula for a tree. (Hypothetical only since it is the specific views that are defined, not physical structures, and so the label "tree" is not really appropriate.) In p/r, one is less pressured to "model" up front, because it is assumed that the structures eventually used are virtually created as needed. You just have to make sure that enuf info is available in the "nodes" to be able to apply a structural formula to. ________________ oop.ismad.com
Post #26,892 by Arkadiy 2/1/02 2:27:03 PM Reply	I understand all words , but cannot make out what you're trying to say. May be an example?
Post #26,895 by tablizer 2/1/02 2:59:35 PM Reply	how about this then We could compare a p/r "role pattern" to an OOP one: [link\|http://www.geocities.com/tablizer/prpats.htm#role\|http://www.geocitie...ats.htm#role] (I didn't show the OOP version. Jay posted a Java version once, but I don't remember where it is. Anybody volunteer one?) ________________ oop.ismad.com
Post #26,900 by Arkadiy 2/1/02 3:39:25 PM Reply	Odd. Not a single mention of "coddlet" anywhere.
Post #26,931 by tablizer 2/1/02 10:19:20 PM Reply	"A formula for a pattern or structure" ________________ oop.ismad.com
Post #27,029 by Arkadiy 2/2/02 9:36:22 PM Reply	Still odd. The only use of word "formula" on the whole page is here: >>>>>>>>>>>>>>>>>>>>>>>>>>> You will note that many of my examples don't include a lot of code. This is because many of the GOF-influenced patterns are mere "viewpoints" in the relational world, created by a trivial relational or Boolean formula, and not a physical code structure. This makes them easier and less intrusive to test and change. Thus, to us table fans, GOF-like patterns appear Neanderthalic. It is better abstraction to use formulas to represent repeating patterns than to physically repeat them. For one, the same items can more easily participate in multiple patterns. Think about it. <<<<<<<<<<<<<<<<<<<<<<<<<<< No matter how much I thnk about it, I don't get it. Do you mean using "WHERE" clause of a SELECT (or may be a view) instead of a list or a table holding needed elements? Fine technique, when you can employ it. But not really new or deserving its own term. Or did you mean something deeper?
Post #27,036 by tablizer 2/2/02 11:03:01 PM Reply	Jay, where is your "Roles" link? ________________ oop.ismad.com
Post #26,520 by ben_tilly 1/30/02 11:00:53 AM Reply	I think you would prefer what Code Complete has to say For one thing he isn't pushing OO. He isn't tying the idea of an abstract data type to a huge amount of structure, and then using it to sell a bunch of design patterns. He is trying to make a point about the value of abstraction and modularity. For another, he elsewhere suggests using table lookups as another useful abstraction technique. :-) As for your looking at things with tables, yes, Edgar F. Codd was a genius. His relational databases are a beautiful way to organize data into components such that people can combine, organize and extract it on the fly in very useful ways. It is not, however, a good way to rewrite OO. For a start the abstraction that is OO is applied to itself recursively. (You build abstraction layers on abstraction layers.) This kind of recursive abstraction is something that relational databases are bad at expressing (see the complications with keeping hierarchical structures in relational databases) and while you can rewrite any particular example in a table structure, in so doing you lose sight of this central key fact. What that means on a practical level is that you are unable to see or follow any of the transformations that make up modification and code reuse in OO. Yes, you can do both the starting and the finishing version. But you can't see how simple the change was for what it did. You can't see it as simple, and you can't see how you would do it. You are thinking relationally, and relational thinking simply sucks when it comes to modelling layering abstraction layers on top of each other. (Because that is a hierarchical action, and relational databases don't model nested hierarchies very well.) That is when the examples are simple. When they get complex, you might as well be dealing with people who are speaking Greek. No matter how easy they seem to find understanding each other, you can't understand any of them. It just sounds like incoherent babbling. And it will continue to sound that way until you stop having to mentally translate everything to and from a language in which the basic concepts simply cannot be stated. Cheers, Ben
Post #26,525 by admin 1/30/02 11:11:07 AM Reply	You must think in Russian! Think in RUSSIAN! 10 LRPD Points[tm] to the first person to name the movie. Very good points, and key I think to understanding why Bryce doesn't understand what we're talking about. Relational sets have a very different algebra than graphs. Yes, sets are very powerful (and they have their own native means for representing hierarchical relationships, such as nested set trees), but they aren't the entire world. Being able to think in both worlds vastly expands the range of solutions one can provide. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #26,534 by CRConrad 1/30/02 12:13:33 PM 1/30/02 12:17:43 PM Reply	Firefox, Clint Eastwood and the semi-telepathic MiG. [link\|http://us.imdb.com/Title?0083943\|Tagline: His job...Steal it.] Edited by CRConrad Jan. 30, 2002, 12:17:43 PM EST Expand All History
Post #26,536 by Steve Lowe 1/30/02 12:16:44 PM Reply	Second, was FireFox. (book was better than movie) ----- Steve
Post #26,556 by tablizer 1/30/02 2:25:20 PM Reply	Abstraction level is relative and graph-like IMO >> He is trying to make a point about the value of abstraction and modularity. << Does he use actual examples that reflect how one would actually do it in the real world? That is what I really really need to see: actual usages of such in practice so that I can see the code structure and how it behaves under different change scenarios (change impact analysis). >> For a start the abstraction that is OO is applied to itself recursively. (You build abstraction layers on abstraction layers.) This kind of recursive abstraction is something that relational databases are bad at expressing << This is another fundamental difference between us. Nested abstractions in general don't work in business applications IMO. To simplify (compartmentalize) things, views work best. The problem with levels is that what is a high-level detail from one user's perspective is a low-level detail for another. Relevancy is relative. Level is relative. (If Einstein and Codd had a baby together, he/she would know exactly how I think :-) Perhaps in other domains it works, but I don't see it in biz apps. I create abstractions per-task rather than per-level. It is a graph view of abstraction instead of a tree view of it. I think computer scientists keep over-using nesting and trees. They are an intellectually attractive concepts, but fail to accurately reflect real-world issues. (I think hierarchical file directories are fundamentally flawed, BTW.) >> This kind of recursive abstraction is something that relational databases are bad at expressing (see the complications with keeping hierarchical structures in relational databases) << I don't think they do a bad job at it. You just need to augment them a little with some standard tree-traversal operations in some cases (not that much different than IMS actually). Oracle has experimented with tree operations in SQL. Note that IBM's IMS database (born around1965) heavily used nested structures. It was found to be less than ideal and most were glad to upgrade to RDBMS. >> What that means on a practical level is that you are unable to see or follow any of the transformations that make up modification and code reuse in OO. << I am not quite sure what you mean by this. >> But you can't see how simple the change was for what it did. << This should be demonstrate-able, no? ________________ oop.ismad.com
Post #26,637 by ben_tilly 1/31/02 10:18:01 AM Reply	Nested abstractions do work in business When the CEO of a company says they will have a booth at a major conference, the CEO tells people to make it so. The CEO doesn't need to know the details of who to ask to get a prefabbed both. The secretary who gets that doesn't care where the raw construction materials come from. The person who buys the raw construction materials doesn't need to know about the manufacture of plastics beyond who sells them, and how much they cost. And so on. In short when you look at how our economy is structured, the whole thing is a series of abstraction layers. At every layer, whether it is between businesses or between people within a business, there is a hiding of details that the person asking doesn't need to know which really do need to be known to satisfy the request. That isn't theory. That is specialization in action, and was documented centuries ago by Adam Smith. This doesn't mean that any particular business problem should be solved with nested abstractions, or that OO is the right way of abstracting things. This just means that layering abstractions on abstractions is something that businesses do all of the time. Explain it in terms of actual people doing real jobs, and you can see it in practice. (OO models the people as objects and the jobs as method calls. That is all.) Now as for Code Complete, Steve McConnell isn't grinding any ideological axes. He gives real examples from real code. But he isn't focussed on overall design of projects. Instead his focus is on actual decisions made while coding. It is very practical and direct. One of his points happens to be relevant for this discussion, but his book is just plain good stuff to know. Furthermore if you want to see an example of OO design in Perl, I would point to LWP. Don't try to master its internal design, that is a mistake. The point of abstracting details into interfaces is to avoid having to learn those details. Instead try to use it. Here is one: use LWP::Simple; print "Please name the URL: "; chomp(my $url = <STDIN>); getprint($url); Try it out. Note the good old [link\|http://name:password@www.whatever.com/page.hml\|http://name:passwor...com/page.hml] syntax for handling names and passwords, how easy is it to modify your application to handle that? Switch the protocol from http to https to ftp, was that hard? Put a proxy server in the way, set the appropriate environment variables (eg set http_proxy to [link\|http://yourproxy:proxyport/\|http://yourproxy:proxyport/], ditto for https_proxy, ftp_proxy, then set no_proxy to addresses you get directly), did that do what you expect? If you allow the base URL to be given by the user, your code doesn't ever change at all. And wouldn't change even if 15 new protocols you had never heard of were added. What actually happens is, of course, wildly different based on what the protocol is. But you don't know, and you don't care. Because the person writing that program shouldn't have to know and shouldn't have to care. So getprint is a very simple functional wrapper around a common set of OO requests to a fully functional OO library whose design makes replacement of one protocol by another utterly trivial and straightforward. Cheers, Ben
Post #26,669 by tablizer 1/31/02 1:41:57 PM Reply	"Layers" is not appropriate for the most part >> In short when you look at how our economy is structured, the whole thing is a series of abstraction layers. << Abstractions, yes. "Layers"? Not really an appropriate description IMO. The abstractions are graph-structured "views", and not so much nested "layers". >> At every layer, whether it is between businesses or between people within a business, there is a hiding of details that the person asking doesn't need to know which really do need to be known to satisfy the request. That isn't theory. That is specialization in action, and was documented centuries ago by Adam Smith. << Yes, but graph (webbed) views, and not really layers. Roles, filters, call them whatever you want, but "layer" implies something higher or lower than the other, which is not appropriate to a relativist like me. Some details for a secretary are not important to the boss, and visa versa. For example, the boss may see HR details of an employee he is about to fire. However, the secretary may only see a note to remove the fired dude from the mailing lists. She sees less, he sees more. But, if she is asked to schedule a meeting, then the boss may only see the final time slot, whereas she may ponder several candidate time slots. In this case, she sees more and he sees less. (The opposite of the fire example.) (I realize the genders used here are stereotypical, but making them PC would be more typing to make things clear.) IOW, the "level" of details in this example is independent (orthogonal) of the employees' rank. Further, attaching behavior or detail level to rank is too heavy coupling because the tasks may be reassigned or rearranged later. Thus, one should use a very light form of coupling, such as tables of access rights, for example, instead of hard-wired "types". Things change. >> Explain it in terms of actual people doing real jobs, and you can see it in practice. << Yeah, teams temporarily or permanently coming together to solve a given task. Sounds very p/r to me. >> What actually happens is, of course, wildly different based on what the protocol is. But you don't know, and you don't care. << Exactly. Whether the protocol internally selected is based on polymorphism, case statements, or a table lookup is hidden away from the user of such thingies. I have a whole webpage devoted to "swappable device drivers" bringing up many of these philosophical issues. I would note that in biz apps, the division between "types of drivers" may blur, as the programmer is not trying to make a commercial-grade super-generic driver or split them up into different DLL's for shipping purposes. Thus, if two different "drivers" share enough code, then they may be merged and the differences managed with say IF/Else statements. Generally if more than 50 percent is the same, then merge them and use IF/Else statements to select the differences. However, if less than 50 percent is the same, then make them two different modules and call the shared parts. Your example is kind of a systems software example. I would like to see more of a business example. (I might look at it closer during the weekend regardless.) ________________ oop.ismad.com

Welcome to IWETHEY!