Subj : Re: Change Patterns (was: Polymorphism sucks) To : comp.programming,comp.object From : Chris Sonnack Date : Tue Jun 28 2005 01:37 pm topmind writes: > (Well, with your attitude you probably will have to reproduce > by mitosis instead of sexual recombinant DNA, so in your case > treeness might be true.) Careful, your true character is peeking out. >>>> And, given that polymorphism exists outside of OOD, I'm not very >>>> surprised it wouldn't be ranked as OOD's most important feature. >>> >>> The poll was about its "best" feature, not necessarily its >>> unique features. >> >> No, you said "most important feature". > > Whatever. If you do not respect accuracy, how am I to take you seriously? > Either way, it did not say "unique feature". In other words, exactly what I said up at the top, there. If you do not demonstrate comprehension, how am I to take you seriously? >>>> Now, you COULD have a data processor that reads from and writes to a >>>> database...but you still have to develop the individual data handlers, >>>> so there's no code benefit, PLUS now you have to deal with an external >>>> system, deal with potential related errors and have a data transport >>>> layer to handle the IO. >>> >>> I don't consider the DB an "external system", but rather a >>> useful partner tool in the process, along with the >>> app programming language. Partners to divide-and-conquer. >> >> Regardless it IS still an external system, > > External to what? The running program, of course. Using a DBS requires a DBS (rule #1 in a gun fight: bring a gun). Even if you're lucky enough to have something that runs in RAM, you have a choice between bringing an entire DBS into your application or using IPC to something out of process. I would imagine that anything with any muscle has gotta run out of process and store data on disk. Unless there's a compelling need for that kind of overhead, it's not an appealing solution. > What if a language/library allows the DB/table engine to be compiled into > the EXE? Unless there's a compelling need for that kind of overhead, it's not an appealing solution. >> Your method requires shipping and installing an *external* *system* >> to the primary program. To justify this requires, well, justification. > > Why do you keep saying "external"? Is the GUI library "external". Is > the file handling library "external"? If I have to provide separate installable drivers, yes. If I have to install a database on the client system, yes. If the client has to run software in addition to my program, yes. With GUI and File libraries, the actual answers are usually no, no and no. With DBSes, the actual answers are usually probably, yes and maybe. >>> Further, I don't encounter much need to swap the input/output source >>> in real-time. >> >> "Swap the input/output source"? You apparently don't understand what >> I told you. If you can't even understand such a simple example, what >> makes your opinion worth anything? > > Of course the problem is with me and not your bad writing. If you don't understand an example, especially one provided in a fair amount of detail, you should ask for clarification. It's not just simple courtesy, you're likely to get called on it later. I'll summarize the example for you. Consider a common software component: a "blackbox" function that takes a data stream of some sort, does something with/about that data, and emits an output datastream. You like business examples, consider a case where the component reads an XML stream of POS (Point Of Sale) info and emits a report summarizing that data (this is not an imaginary example). From an engineering and maintenance point of view, not to mention from an elegance and simplicity point of view, you'd like to completely decouple the component from the data provider as well as from the data consumer. To use your own example, you might like to emit these reports to emails to managers, HTML to a website, and a database for archival. On the input side, you might normally get data from a web service taking SOAP messages, but you'd also like to get data from the disk for test and validation purposes. What your component does, in an OOP polymorphic solution, is take two input objects that are interfaces: an "Input" interface and an "Output" interface. You design your component to read from the Input and write to the Output. Now you can pass your component any pair of objects, so long as one supports the Input interface and the other supports the Output. If you want the ability to write to multiple outputs *simultaneously*, you design your component to take a list (or array or vector or collection or ...) of Output objects and just iterate over each for any output. Now here's the crucial point: In OOPLs, this is trivially easy to implement and is native to the language. No libraries, no IPC, no databases. Very low overhead, easy to implement, native to the language, fast running.... that's a hard combo to beat. >> Note about data integrity: I've yet to work with a production database >> that didn't suffer from horrible data integrity problems. I'm working >> with a system (which I cannot name) now that is case sensitive, so there >> are lots of "CHRIS/chris/Chris" data duplications. > > That can be remedied with DB triggers. And not all DB products compare > case differently. Some have configurable case management options if I > am not mistaking. Of course. It was a side comment about the particular database I happen to be dealing with now. >> I've worked with corporate production databases for almost two decades, >> and they are complex and difficult to manage. > > You should have seen their predecessors: I did. Many of the earlier projects were bringing legacy data forward. >>> Expensive? Go open-source. Try MySQL or Postgre-SQL. >> >> Not talking dollars. Talking cost of implementing, maintaining, etc. > > Oracle is not the only model of how a DB can be. Doesn't matter who. All DBSes have a cost of implementing and maintaining. With some, the cost is huge. With others, it's less painful. It's still always there, however. >> (And corporations rightfully tend to shy from OSS.) > > OSS basher too, eh? Hmmmm. Not at all. There are logical reasons for corporations to shy away. >>> It is essentially the same thing: sub-type classifications. >> >> I don't agree that a class that implements an interface is a sub-type. > > In practice it tends to be so, at least for domain-centric classes. Practice is affected by many factors beyond correctness. When talking about what a thing *is*, practice doesn't really apply. The fact is that implementing an interface does not *require* sub-typing. >>> (Not all polymorphism is related to sub-typing, but most is in >>> practice, at least at the domain level.) >> >> I disagree. I do a lot of VB programming. VB supports interface >> "inheritance" but has no concept of implementation inheritance. >> My polymorphic VB objects are not sub-types. > > Maybe not from the language's perspective, but conceptually > they are usually subtypes. The irony is that, to the extent that's true, it reflects either the innate hierarchical nature of the problem being modeled or a hierarchical way of breaking it down. >> If the code needs to decide what sort of object is at hand in many >> places, then you have many case statements you must first find and then >> change. And in my experience, you will have a lot of places where the >> code needs to think, "Gee, is this a Savings Account, Checking Account, >> or that new fangled Combo Account." EACH ONE OF THOSE must be located >> and changed. > > Most case lists are not mirror duplicates of each other in my > experience, at least over the longer run. Which makes the problem that much worse. If they WERE close or duplicates, they'd be easier for search engines to find (among all the other case statements). > If there are lots of them, it is often a sign that tables should be > used instead. So now, every time you dispatch a method on an object, you need to go do a DBLookup() function of some sort? Eewwww. >> Compare this to a system using a generic Account object. If you add a >> new sub-type, that's it, you're basically done. > > Yes, that is the most common change scenario promoted by OO books. > But it is relatively improbable in my experience. IT'S YOUR OWN "REAL LIFE" EXAMPLE!!!! In the other thread, you've been trying to get them to accept it as a reality. Now you're disowning it? To quote your own words about a dozen lines later: > I've heard it with my own ears. No matter what taxonomy I present, > you can always claim it may be fake. No, see, I took your ball an ran with it. Now you've turned face. > Then present some stable business hierarchies. The hierarchy of positions in my company hasn't changed in decades (CEO, Senior VPs, VPs, etc on down the line). Nor has the hierarchy of business units changed significantly. BOMs are nicely handled hierarchically (and, in fact, would be very unwieldy if handled as flat lists) CAD/CAM hierarchies are, well, hierarchical, and thankfully so. Hierarchies and fractals have a lot in common in that there are self- similar *levels* and in the concept of "drilling down" (or "zooming back"). The tree structure--as much as you try to find fault with it--IS a fundamental, natural relationship. Databases fail to efficiently model trees, because trees are "triangular" in nature. Databases are tabular, or "rectangular", in nature. These are mutually exclusive natures. In places where one shines, the other usually does not, and vice versa. >> The "Family of Man" is a huge hierarchy. > > Wrong. Human genetics is not a pure tree. A directed > graph may be a better description. If you mean some branches re-connect, that doesn't stop it from being a tree (just stops it from being certain kinds of tree). There are all sorts of trees. And on the small scale, such as when you graph the genealogy of a family, it is entirely treelike. >> The files on your disk are >> arranged in a hierarchy for very good reason (what would you recommend? >> putting them all in an RDB and searching for the ones you want?). > > > Yes! Hierarchal file systems suck!!!! They are fine when you have 200 > files, but don't scale. I have MANY tens (if not hundreds) of thousands of files on my laptop. What do you mean it doesn't scale? If the best you can do is wave your hands and declare, "They suck!!!!!", then you've said nothing. > I encounter times I wish I could query for files with SQL all the time. SQL is just a query language, nothing prevents it from being applied to any dataset you like. Now imagine you have all the power of SQL, PLUS part of your filtering ability is to restrict the search to a subset of records (verses the entire dataset). Wouldn't you call that a win? >> Companies and armies are hierarchically structured. Etc. Etc. Etc. > > Not really. More hand waving saying nothing. Yes, really. I can trace a unique path from me to the CEO. It's 100% tree shaped. As for armies, have you ever heard the phrase "chain of command"? What do you think that involves, if not a tree? > One of my first exposures to the problems of trees happened when I was > building a budget summary app that presented budget allocation in a > hierarchical fashion (among other things). > > They kept bastardizing the structure such that a given office would > appear in *multiple categories*. So you mistook the original problem as being tree shaped, but it wasn't. So what? Not EVERYTHING is a tree, obviously. >>>> One thing I think is true is that OOD is harder, and does require >>>> a higher skill set, than simpler forms of programming. >>> >>> That is because OOD is ill-defined, ill-documented, ill-evidenced, >> >> That's nonsense. It's because OOD is more sophisticated and abstract. > > Yeah, too "sophisticated and abstract" to document and science-atize. That's true of software construction in general. It's an extremely complex task, intellectually on par, I believe, with law and medicine. All three fields, in their daily practice, break new ground (like researchers), but also need to produce approximately immediate useful results (not like researchers!). And all three fields deal with a large network of inter- connected data that often reacts holistically. Software development has rightly been called, "an exercise in managing complexity." There IS a lot of science that informs law, medicine and computer, um, science, but as a real world practice, there's a fair bit of art and craft to it, too. >> I'm coming to understand you're an evangelist. I don't do evangelists. > > Well, you sure did a damned good *impression* of one. If you pay attention, you'll see I'm standing here in the middle of the road. You're the one over there in the ditch trying to baptize everyone. -- |_ CJSonnack _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| .