Slashdot Mirror
Applied Java Patterns
Check your sources.
The title is published by Sun Microsystems Press, and the two authors are instructors for Sun Microsystems. As you would expect, this means you won't find any discussion of Java's darker corners; this isn't a particularly damning criticism in a book about Design Patterns, but it does mean that, for example, you won't see discussion on why double-checked locking implementations of the Singleton pattern don't work. (I might be reading more authorial/editorial bias into this than was intended of course -- I'm a bit paranoid. Too much caffeine, I expect.)
What's the book about?
From the blurb:
"[...] After briefly reviewing the fundamentals of design patterns, the authors describe how they can be applied effectively to the Java platform and present proven techniques for all types of patterns, from system architecture to single classes. Next, they present a pattern catalog."
In other words, what we get is an adequate intro, followed by about 275 pages of pattern catalog (mostly from Gamma et al, with a few threaded items from Doug Lea's Concurrent Programming in Java). This is what you're buying the book for, and on the whole it's decent material.
It continues:
"In addition, they identify patterns in the core Java APIs and present techniques for pattern use in distributed development. [this title] also features a section on pattern use in systems built with J2EE and Jini technology and coverage of the servlet, JSP, and EJB APIs."
Just about! This entire section is very much secondary to the catalog. The core Java APIs discussion is about 20 pages, the distributed section about a dozen, and the rest only 15! I've seen as much discussion of the pattern usage in the JDK in asides in, for example, Bloch's Effective Java (an excellent book by the way).
Of much more interest are the appendices. In reverse order -- Appendix B is a welcome bibliography. Appendix A is an odd decision on the part of the publisher. Appendix A is "Full Code Examples." Normally I'd think that this is a good thing, but appendix A is 224 pages, as compared to 273 for the whole pattern catalog. I feel it would have been better delivered on a CD. I realise this adds, what? $5?, to the cover cost, but the book would have been substantially thinner, with a knock-on effect on price.
A more important consideration is that this appendix distracts from the catalog, and adds little (other than working framing code) to the discussion of the patterns.
Target audience?
Experienced Java developers - but ones who haven't been exposed to Design Patterns before. I doubted that this was a huge audience, but then realised that Java is often used as a teaching language now, and I may be wrong in assuming most graduate programmers would be comfortable with the C++ and Smalltalk examples in Gamma et al. I could see this being a useful niche title for those mono-linguists starting out their professional careers.
What's good?
Overall, this isn't a bad title. It's decently written on the whole, has passable explanations of the main Patterns, and is presented clearly. It's just that there's nothing superb about it, and the problems (below) offset the overall competent tone. (It's a weird book to review: the majority of the content isn't original, and as a repackaging exercise I can't comment on, say, how brilliant it is to have a name of the Factory concept at long last.)
What's bad?
Too much for a simple port of GoF to Java. Let's start with the obvious flaws and then move onto "missed opportunities":
- Diagrams
Sorry, but there is no way that the UML diagrams in this title are acceptable in a professional publication. They're woeful, jagged-edged screen-capture affairs. - Appendix A
As discussed above, the book has a schizophrenic feel with a LOT of material relegated to, or repeated in, Appendix A. A much more useful approach would have been to provide more material on the applicability of each pattern, or to flesh out some of the alternative implementations discussed. - The example application
This title tries to do something laudable, but ill-thought out. What they do is start to discuss an example application (the Personal Information Manager) in the first pattern, and then carry that example through to all the other examples. This isn't a bad idea, but think about it. How do you use your pattern books? I flick through mine. I pull it off the shelf and read one pattern, or pass it to a colleague saying, "You want to change that to a [whatever]."When reading this title my flatmate was struggling with some OO design homework -- flicking to the pattern under discussion (Composite) starts us into another discussion of the PIM! This isn't what I want and puts me off the title immediately as I feel like I'm missing some background. The examples need to be more standalone. (To be fair, this only affects the blurb text, the code is independent.)
- Oh editor, where art thou?
While talking over the Composite pattern with my confused flat-mate, I noted that the Deliverable snippet actually gives the code for the ProjectItem again (page 163). Sadly, it's also wrong in Appendix A. On the full read-through this type of simple proof-reading error occurred too often. - Oh code reviewer, where art thou?
Here's a hint for publishers. When writing a book for a professional audience which necessarily thrives on pedantry, try and have examples peer-reviewed first. Much of the code in Appendix A is not great. Now, I realise we're developing educational examples here, and we want to keep the focus on the pattern, but the impression given by the full code examples isn't good. Continuing the above example, the error handling of the Composite pattern is feeble. (Static ints defined in an exception class and then if-elsed on the main class to get printable versions? Yeugh.) I'm being picky here, but this is a book about better design, and people-in-glass-houses, etc. In addition, the core concepts aren't original, and so it's this (slightly sub-standard) example code which gives the added value, or rather, should. - Fly-leaves
You know what I love most about Design Patterns? The fly-leaves -- to find a pattern I open the cover, skim the list and turn to appropriate page. Brilliant for a reference title. Applied Java Patterns misses a simple trick here. A hardcover edition would also be nice. As would those nice GoF ribbons. (My apologies if there is a softcover version of the GoF book featuring neither fly-leaves nor ribbons and I've been comparing apples to oranges.)
So, overall the impression that this book gave me was of an opportunity missed. Too many little details wrong, or lacking when compared to the GoF title.
Alternate titles?
There is another Java Design Patterns title: Addison-Wesley's Java Design Patterns -- A Tutorial, by James W. Cooper (2000, ISBN 0-201-48539-7). I can't say I recommend this title either -- it's much thinner, comes with a CD, takes a more tutorial tone, but suffers many of the same flaws (sloppy editing, lack of 'flickability,' chunks of dodgy code and some bloody examples).
Sorry, but the undisputed king still reigns -- the original GoF book is still superior in almost all respects. Only a lack of recent examples, and the fact that the examples are only in C++ and Smalltalk can be called criticisms. (Details: Design Patterns: Elements of Re-usable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. Addison-Wesley, 1995, ISBN 0-201-63361-2)
If you feel that the GoF book is a bit, well, academic and intimidating for your taste then might I suggest a side order of John Vlissides's companion volume, Pattern Hatching: Design Patterns Applied (1998, ISBN 0-201-43293-5). This slim volume talks about applying patterns -- where, how, etc -- in a clear way, using a tutorial approach. The example system developed helped me "get" some of the concepts first time through. The examples are in C++.
I don't want to give the idea that there are no new Design Pattern books worth reading - for example, for J2EE work I think highly of Core J2EE Patterns by Deepak Alur, John Crupi, and Dan Malks (2001, Prentice-Hall, ISBN 0-13-066586-X).
So, to sum up, this isn't a bad book, but it does feel like a pale imitation of the GoF title, and offers very little to anyone who develops in Java but has access to the GoF book. Any publishers or wannabe authors listening? Seems like now might be a good time to think about issuing The Design Patterns Java Companion, along the lines of the existing Smalltalk title. (Hmm, maybe I should take my own advice ...)
You can purchase Applied Java Patterns from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Bruce Eckel has a book
Thinking In Patterns
How does this book compare to that?
S
There should be a swear jar for people who say "this isn't the we're looking for. Move along." Either that or it should be legal to hit them in the face.
Losers. There's no all-pervading cultural reference that controls *my* destiny.
-- Proud descendant of semi-nomadic cattle-herders.
Very Interesting.
The original "Design Patterns - Elements of Reusable Object Oriented Software" is absolutely definitely the best book to describe design patterns. Ok so it has some C++ code, but if you are a Java coder worth your salt, you should be able to follow it to some extent.
The main point is that design patterns are supposed to be language neutral! Most of the "Design Patterns in XXX" books pretty much break the idea, as they tie a pattern in to an implementation. The pattern of course is a collection of; pattern name, problem, solution, consequences, and not just some code.
My point is that some of these books are great, and some are poor. But the original really is the only one to give you the real feeling of the patterns philosophy.
It seems that to produce a design patterns book that is language centric misses the point. They are patterns, they should be able to be implemented in any language, not just the one of the authors choosing.
Have you considered Java?
trg
Dear Bill, do you have a
I like the way it is set up. that it is clear and it has a consistant feel hrough out the entire book. It's far superrior for reference to the GoF.
It's an easier read for most people. And it covers more patterns. Gives more code examples. And uses one language which adds conistancy.
I think this book was very well done and I would much prefer reading it then the GoF.
Hrm, doesn't anyone think that these people calling themselves the "gang of four" is a bit, like, wrong? I mean, the original "gang of four", Mao's henchmen in the cultural revolution, were terrible people. I mean, it's like if some people wrote a book on 4th generation programming languages and called themselves the "fourth Reich" or something. Or created a foundation for OO design research and called themselves "Al Qaeda". ('al qaeda' = 'the foundation' in Arabic Eeh, whatever.
autopr0n is like, down and stuff.
You'll probably elicit more concensus if you ask "Which religion is the right one?"
..
I've had success in C++. Others have in Java. Every lang has its strength and weaknesses; when you use them often has more to do with what platforms and technologies and APIs you'll be hooking into, and whats been used in the past when you join companies and projects. There's no true abolute
"Old man yells at systemd"
And my parents said I'd never amount to anything. Actually, I have nothing to say in this article :-P
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
My experience is that Java is great for learning to program in OO, because it adheres more cleanly to modern ideas about OO-programming.
Implementing an interface for example is a different thing in Java from extending a class, where in C++ both things are done with inheritance. This makes for a more clean seperation of ideas.
Also, when you look at the Java API, patterns are virtually everywhere (look at the Java Collection Framework to see what I mean).
That being said I would to add that though Java is a great choice for teaching, I'm still not very much convinced about it's merits in normal software development, especially when it comes to building GUI applications...
PageTurner Reader: open-source e-reader for Android with cloudsync. http://pageturner-reader.org
Two things. One, programming takes a lot of time and work, and you will be well rewarded for the time you put in to learning C++.
Two, no one uses every feature of C++. I don't think any compiler even now supports the full ANSI C++ standard. I was just reading a CUJ article about separate template compilation and how it's just now being implemented, since it's doesn't really work as many people thought it would. People still do great things with C++ though. The C++ philosophy is to enable you to do what you want; if Bjarne sees something that might improve 5% of programs with a 5% speed hit on the other 95%, he'll add it (I'm thinking of multiple inheritence here, and don't quote my numbers). So don't worry about the complexity of C++, just use what you like.
I'm intrigued by your ideas and would like to subscribe to your newsletter.
But unfortunately a bit too obvious.
:-)
The best programming language is of course the most obscure, that way you keep your job
An Eye for an Eye will make the whole world blind - Gandhi
Yeah, I think that is why the 80's New Wave band Gang of Four ("I Love A Man in Uniform") failed as well--they were too hurt by the comparison you mentioned. I'd have to wait for the VH1 Behind The Music to find out for sure. Anyway, they just happened to pop onto Spinner when I read your comment. Strange.
THEY didn't coin the name, other people did, since it takes too long to say all 4 author's names. It's common to refer to a programming book simply by it's author's name, so "gang of four" stuck. Blame whomever first said it.
ps, love your site
Pardon my ignorance, but I haven't encountered this concept of "Design Patterns" (capitalized) before, and I wonder if one of you wonderful helpful egalitarian types (I know there have to be at least a couple on /.) would actually be willing to explain it for me so that I don't have to try to work it out from hints & snatches in this discussion. Please?
"The best argument against democracy is a five minute chat with the average voter."
--Winston Churchill
Since /.ers aren't known to be history buffs, you're likely to to have some nazi moderator mod you down. Oops.
No, Thursday's out. How about never - is never good for you?
Java Companion is a free (PDF) download of a good treatment on the subject. As a practicising java developer there's no substitute for the GoF Design Patterns especially the discussion on each pattern. But sometimes it's hard to gather the full meaning because a C++ demonstration is used replete with multiple inheritance or even just inheritance that may be realised in Java as composition. With Java, one requires little bit help, some lateral thinking to come up with an equivalent. The download has helped me immensely.
To expand on batkiwi's comment above, here's the Gang of Four entry in the Jargon File:
In Soviet Russia, Jesus asks: "What Would You Do?"
Design patterns with new technology (like EJBs and servlets) are trickier to envision, that is why books like these are valuable.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
It would be nice if the book reviewers gave the scale that they rated books on (or were required to use a standard rating system). It is hard to compare reviews when one reviewer uses A - F, the next uses 1 - 5, and the next uses 1 - 10.
Applied Java Patterns is an adequate Design Patterns reference for those who must have a Java version of the classic Gamma et al (aka Gang of Four, or GoF) Design Patterns
If you feel you need the Java version of the original GoF (gang of four) book, I have a recommendation: Skip the book, and buy Eckel's "Thinking in Java," because you have some catching up to do if you can't translate the original design patterns into Java (or any other OO language, for that matter).
Too many developers use design patterns as either (1) a crutch due to poor design methodology or (2) sparkle and glitter in order to impress the boss with an otherwise sound design methodology. Learn the language first, work with the language, and write some software before worrying about design patterns. The original GoF book will work with any OO language, but you will have to supply the necessary skills to get the job done. Another design pattern book isn't going to help you.
I have no problems applying the Smalltalk version to Java, etc.
Really, I think that it is best to be language agnostic: happily use any language someone pays you to use.
my own project:I like to write (a lot!) and I am just starting a new Free Web Book project that I not-so-humbly call "The Software Design Book" that uses what I call "light weight" UML (i.e., only use case, class, and sequence diagrams) and lots of my own philosophy. Anyway, an early version will join my other two free web books on my site in a week or two.
-Mark
You could not implement most of the GoF patterns in a language that doesn't support the core OO concepts ("Design Patterns for assembler" anyone ?).
Or rather, I would suggest that most if not all languages have un-documented patterns waiting to be published - but what works well in a java environment doesn't work in assembler and vice versa.
"A pattern is an idea that has been useful in one practical context and will probably be useful in others". (martin fowler).
Of course there are other definitions, but most include the word "context". The language in which you are approaching the problem is definintely part of that "context" - so I think there is definitely a place for an explanation of how to implement well-known patterns in a specific language.
Having said that, I think there's a trend towards "rip-off" pattern books which add too little value - I recently read "J2EE design patterns applied", which allegedly expands on the Core j2ee patterns book. It's not very good...
It's all very well in practice, but it will never work in theory.
Propoganda
Design Patterns in Dynamic Programming
"Design Patterns" Aren't (google cache link)
public class Something {
private static Something s = new Something();
private Something() {}
public Something getInstance() { return s; }
}
You see in Java, unlike C++, we have a classloader that manages the loading (and thus creation) of a single instance of a class. If you are calling Something.getInstance, presumably the class-loader will then load the Something class at that time, instantiate a sole instance, and return it to you, without having to worry about the details of thread-safety and creating multiple instances.
Anyway, using the Singleton pattern is not entirely "good programming practice", as it is often used to create "Global Variables" in disguise.
GOF-style patterns get carried away with "using code to model your nouns". I find using relational techniques and tables superior because they do not depend on the physical structure of code (beyond relational formulas), but rather use as-needed "virtual patterns". It is like the differences between doing calculus by counting rectangle approximations under the curve and diriving dirivatives via formula transformation. GOF is a bunch of rectangles hand-weaved together in my viewpoint; a bunch of classes hand-indexed together the old-fashioned way. I would rather let the database engine and compact formulas do most of the weaving for me.
In procedural/relational design, the programming code is less tied to the "noun-model". Thus if you want to change the noun model or have multiple simultaneous noun models in play, the code does not need large-scale overhauls in its structure. This makes p/r more change-friendly IMO, and most software expenses are on maintenance, not creation.
If you tie your code tightly to noun models, like GOF and OOP tend to do, then your code needs more rework if you change your noun model/relations. Pretty simple.
Paul Graham has made similar comments about patterns, although he uses relational's cousin: functional programming and set theory, to do similar "virtualizing". (In essence, he uses relational-like formulas in LISP.)
More reading on my opinion of GOF-style patterns:
http://geocities.com/tablizer/prpats.htm
http://geocities.com/tablizer/whypr.htm
What we have in this slashdot story is TWO overhyped techologies: Java and GOF-like patterns. A 2-for-1 bargain. PHB's and fad chasers will love it.
Table-ized A.I.
The only way I would find this offensive if it somehow demeaned any of the authors, which it doesn't, and it is a catchy title, and while Gamma et al are famous, they are also notorious (where is Tablizer when we need him?), so the name is fitting.
Can you recommend a language/relational dB combination under Windows that allows you to do what you advocate, including using relational tables to dispatch code?
Agreed. That book can be found at http://www.amazon.com/exec/obidos/tg/detail/-/0201 184621
public class Something
{
private static Something s = new Something();
private Something() {}
public static Something getInstance() { return s; }
}
I looked at this book, and decided not to buy it because it didn't really offer that much other than implementations of the GoF patterns in Java, and to be honest, they were basically crap. I'd say that this book might actually do more harm than good if it were being used in a teaching environment.
I noticed that there are some comments criticizing the fact that the GoF book has examples in only C++ or smalltalk, which is perhaps what promted the authors to produce this book.
The thing is though, the GoF text is trying to express some pretty fundamental programming concepts, that can be readily implemented in ANY language - granted it helps if your choice language supports inheritance/polymorphism.
The bottom line is that C++ is basically similar to smalltalk which is basically similar to Java which is basically similar to C#.
Any programmer worth his salt should be able to understand what the examples in the GoF book are trying to get across if he knows even one of those languages. They're not _that_ different. And besides, it might help if you have to look at the code a little harder.
Now if the examples were written in some language that was an absolutely radical departure from your standard OO language, say Lisp for example, then I could understand some complaints, but seriously, the language is not that big of a deal.
Just for fun, the language whiners should check out Donald Knuth's "The Art of Computer Programming" series - he defined his own language for those examples. His language is kind of like assembly, but it kind of isn't. Doesn't match any language today, but I bet you won't be able to find anyone who will say that those books are not an absolute treasure trove of information, despite the implementation language.
I found the ideas on your site to be really interesting... Obviously, you are taking exception to the idea of OOP and not patterns. I certainly see the value you in your approach. You appear correct that in some circumstances, a change in overall design could be realized just as quickly using a relational model (in some cases.) (I'm sure you would argue more quickly, but I am not convinced of that)
Where it appears to fall short is in the area of reuse. Your code is written extremely specifically for the task at hand and does not seem like it could be moved over to a new domain. (I haven't had a chance to browse all of your articles so maybe you address this.)
The functional programming models you talk about tend to be more similiar to the OOP approach (heavy use of polymorphism) only using far less "nouns".
Anyways, thanks for the link to your site which seems to be a really interesting resource.
For those unfamiliar with double checked locking, it's explained here.
The basic claim, is that code like this:
public class Singleton{
private static Singleton instance;
public Singleton getInstance(){
if (instance == null){
synchronized(Singleton.class){
if (instance == null)
instance = new Singleton();
}
}
return instance;
}
}
doesn't work, and the only way to fix it is put the first (instance == null) check into the synchronized block, incurring the synchronization penalty every time the method is called.
You could also simply avoid lazy initialization and instantiate the singleton when the class is loaded.
Hey I got this main window object that has got all these child window widget objects -- they call that Composite. When I click on a widget, it notifies the main window -- they call that Observer. What I really want is to synch my edit box with the spin control, but I don't want to complicate the edit box by making it an Observer -- I will have the main window observe the spin control and forward that action to the edit box -- they call it Mediator (it is also known in the industry as Visual Basic).
If GoF patterns are putting a name to commonly used OO techniques that you have probably already reinvented yourself, they are tres useful in explaining what you are doing to students, new programmers. If GoF patterns are "PHB says that I have to restructure my code to use patterns", I would agree with your flame -- they become a tool in search for a use.
My biggest Pattern gripe is Singleton -- I have yet to see a clean implementation that does not require a lot of cut-and-paste to implement each Singleton. That darned thing is friggin hard to implement right -- Vlissides even admits in Pattern Hatching that he does not have a bulletproof C++ version of Singleton.
Language food fight predicted. Duck!
Has anyone tried the Design Patterns Java Workbook by Steven John Metsker?
It's sitting on my desk right now. I'm liking it...
Lately democracy seems to be based on the skybox, the Happy Meal box, the X-box, and the idiot box.
...between software engineers and mere coders.
--
CPAN rules. - Guido van Rossum
...it'll be longwinded, over-enthusiastic, and discarded as soon as Bruce moves on to his next programming fad.
At least, that's been my impression so far of Bruce "Shiny objects are neat!" Eckel.
--
CPAN rules. - Guido van Rossum
I think I have been looking for an inherit-from-a-base-class instead of using a template.
Java sucks at GUI apps because of Swing's overuse (and misunderstanding of) patterns.
Whoever designed that shit should be fired.
Your links are slashdotted, it appears.
A new design pattern: The Blank Screen Pattern
I got through to one, but odd how the table of contents have no href links. If this is how anti-pattern people do content, they will turn off a lot of people. Few are going to walk into a house if they have a hard time finding the door. The Door-free House Pattern?
Why is this topic *not* also under "Developers"? Tablizer might have a point afterall about "tree-happy mutually-exclusive taxonomies" here on slashdot itself.
Try adding $15 to the price.
And I can't put the CD in my lap and look at it when I'm coding. And since I 'ding have a few hundred dollars to spend on a laptop I can't take code on a CD with me. I can take a book. Dead trees also don't require batteries. I applaud the use of dead trees as opposed to 1s and 0s as a distribution format.
advanced jawa patrons?
nerft poft.
i nid it mynelf.
Egotism and arrogance aren't necesarily desireable corrolary features either!
Software Engineering is a much maligned, poorly-understood and often pretended-to discipline. But that doesn't mean that most "mere coders" don't perform engineering functions (note the definition of engineering involves applying thought and ingenuity to a problem).
And a lack of any sort of humility on behalf of "Software Engineers" isn't likely to help bridge the gap between conventional engineering disciplines and the very active world of software production.
Instead of displaying an annoying disdain for your fellow slashdotter (whom I may not agree with but I'm not going to trash for an ego boost), can't you make your point without the attitude?
-- Mal: "Well they tell you: never hit a man with a closed fist. But it is, on occasion, hilarious."
My site was not slashdotted.
I was moving house and changing ISPs.
You can make a pretty straightforward Singleton template easily enough, as long as your compiler is up to speed on basic template work (which almost all mainstream ones now are, so you're fine unless you're working in the legacy world). I refer my honourable friend to Modern C++ Design by Andrei Alexandrescu for one simple possibility (and many other useful tricks with Singletons and templates generally, if you're compiler's up to it).
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I hate it when I forget to change "you're" into "your" after an edit and don't notice in the preview. Sorry.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The basic idea is that certain problems arise frequently in designing code, and often people come up with very similar designs to implement the solutions. This gives rise to two ideas.
A design pattern is simply a named, streamlined solution to a common problem.
Many people, not least Gamma et al. in their book Design Patterns (Addison-Wesley, 1995, IIRC), suggest that if you find the same sort of idiom solving similar problems in two or three different places, then it's likely to be worth looking for the underlying common idea behind those solutions, streamlining and naming it, and thus producing a new design pattern. Some design patterns are quite general and occur in many OO designs in diverse fields, and others occur frequently in a particular field but are irrelevant elsewhere.
Design patterns are basically useful in two ways.
The final important thing to remember is that design patterns are never a goal in themselves. Code is not good just because it follows patterns or bad just because it doesn't. The benefit of patterns is simply that they make it easier to do what you might have done anyway, but probably with less effort, more confidence and better results.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
"you won't see discussion on why double-checked locking implementations of the Singleton pattern don't work. "
... nor should you.
Two scenarios:
1.There must be only one Singleton instance at a time, and if this rule is broken it has negative consequences for the correctness of your application, or a large performance overhead.
Make the getInstance() method synchronized.
2. A short-lived second instance is not a huge problem.
Don't worry about it.
There is far too much emphasise placed on the avoidance of synchronization, when greater gains can be made by optimizing other things like your algorithms. The performance cost has been reduced in VMs in the last few years anyway. The double locking idiom existed purely to avoid synchronization, and never worked anyway.
I heard a great quote at JavaOne a few years ago: "The cost of synchronization is less than the cost of stupidity".
${YEAR+1} is going to be the year of Linux on the desktop!
(* I wasn't making any claims about their worth, just that they are a great example of how OO design facilitates code reuse. Substitute Java servlets if it makes you feel better.. they work the same way. *)
// use defaults
// select specifics
// defaults
// pass in options
I don't see code reuse. Could you point out something more specific?
You could get something similar with associative arrays, named parameters, and tables. Example:
handle = createThing()
handle = createThing(featureA=foo, featureB=bar,
featureC=narq, etc.)
Dictionary:
declare myDict[]
handle = createThing(myDict)
myDict["featureA"] = foo
myDict["featureB"] = bar
etc...
handle = createThing(myDict)
I am not showing table versions here. Plus, one can use *set-based* defaults. Inheritance cannot do this very well without emulating my approach the hard way and overhauling pre-existing inheritance-based code.
IOW, OOP has a hard time going from inheritance-based defaults to non-tree-based structures. Sets are a super-set of trees, and thus can be both without significant code structure overhauls.
Tree-based "reuse" is too limiting in many cases. The world just simply does not change in a tree-wise fashion; that is the bottom line and I stand behind that observation to my deathbed!
There is no natural force to herd things into tree-wise change patterns (except for some narrow domains). I keep saying it, but it does not sink in. You guys keep going tree on me.
Get your heads out of the trees! Many of the more experienced OO fans have already realized this, and promote "delegation" (referecing) instead. Go ask them if you don't beleive me. (The problem is that delegation is reinventing relational technology from scratch the hard way.)
Table-ized A.I.