Abstraction level is relative and graph-like IMO

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!