Applied Java Patterns 114
| Applied Java Patterns | |
| author | Stephen Stelting and Olav Maassen |
| pages | 561 |
| publisher | The Sun Microsystems Press / Prentice Hall |
| rating | B |
| reviewer | David Kennedy |
| ISBN | 0130935387 |
| summary | Adequate Java implementation of "Design 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.
How does it compare with Bruce Eckel's Book? (Score:3, Informative)
[mindview.net]
Thinking In Patterns
How does this book compare to that?
S
Re:How does it compare with Bruce Eckel's Book? (Score:3, Informative)
If its anything like Bruce's other infatuations... (Score:2)
At least, that's been my impression so far of Bruce "Shiny objects are neat!" Eckel.
Re:grr (Score:1, Offtopic)
[officer_barbrady] All right people, there's nothing to see here, Move Along. [/officer_barbrady]
discussion on book (Score:3, Informative)
Very Interesting.
Design Patterns (Score:4, Insightful)
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.
Re:Design Patterns (Score:3, Insightful)
I'm a C++ guy, but I always was able to look at code in languages I hadn't programmed in as pseudocode
EJB's (Score:1)
Patterns are not language neutral (Score:2)
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...
Re:Patterns are not language neutral (Score:2)
I have a copy of Visual Basic Design Patterns. They actually manage to pull them off in VB6, though it gets a bit kludgey at times. VB.net isn't a problem though.
For the record, the book sucks.
Re:Design Patterns (Score:1)
Maybe it's just a prejudice I have against long code samples in books.
And therein lies the difference... (Score:4, Insightful)
Re:And therein lies the difference... (Score:1)
Re:And therein lies the difference... (Score:1, Flamebait)
Re:And therein lies the difference... (Score:1)
And therein lies another difference... (Score:2)
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?
Re:And therein lies the difference... (Score:2)
Tech pays the bills for me, nothing more. I'm good at it and I used to love it, but now it's just a job. and I love THAT.
Re:And therein lies the difference... (Score:3, Funny)
Developer - Also a coder but has a complex about being referred to as a "mere coder"
Software Engineer - Coder who has read GOF and knows how to use visio, has a complex about being referred to as a "mere developer".
Architect - Coder who has read GOF, knows how to use visio and can talk buzzwords to management thus securing the promotion. Could code, but isn't allowed to, eventually loses all perspective on facets of actual implementation. Has a complex about being called a "mere software engineer".
Eamples in C++ aren't really criticism (Score:2, Insightful)
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.
Re:Eamples in C++ aren't really criticism (Score:1)
And when you have no concept of separation between the syntax of a language and the semantics of a piece of code, you need a book in you language. Look on the bright side: More opportunity to make a buck selling another book in the language of the day. A .NET version of TAoCP anyone?
Me, this just gives another opportunity to feel superior, reading Gamma et.al in the original and being able to write Software in about 20 different languages. ;-)
I acutally like this book (Score:1)
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.
"gang of four": apropriate? (Score:1, Offtopic)
Re:"gang of four": apropriate? (Score:1)
Re:"gang of four": apropriate? (Score:2)
ps, love your site
Re:"gang of four": apropriate? (Score:1)
Since /.ers aren't known to be history buffs, you're likely to to have some nazi moderator mod you down. Oops.
Re:"gang of four": apropriate? (Score:2)
To expand on batkiwi's comment above, here's the Gang of Four [tuxedo.org] entry in the Jargon File:
Why Gang of Four is appropriate (Score:1)
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.
Help? (Score:2, Interesting)
Re:Help? (Score:1)
To my mind this is the major win for DP. The abillity to describe common approaches between a diverse group of programmers and systems in a way which allows them to learn, relate, and discuss approaches decoupled from implamentation in their pet language.
Re:Help? (Score:1)
Near as I can tell, design patterns are to programming what paint-by-numbers is to art. I haven't met a gifted programmer who made extensive use of them, but they seem to be a sort of helpful template for average coders of the sort hired in legion strength for "enterprise" projects in Java and the like.
Re:Help? (Score:4, Insightful)
> Near as I can tell, design patterns are to
> programming what paint-by-numbers is to art.
I can see how this comparison would occur to someone with little experience using Design Patterns. I think a better explanation is this:
Most anyone can, given a programming problem, come up with a solution that works. If you're working on a quick and dirty piece of code for one-time use, then using patterns might not be the answer. However, its very common that people want to add new features... support new file formats, etc. Most quick and dirty designs, even by good programmers start looking really bad when new features are added. If the system grows significantly larger than the original developer expected then the design becomes completely unwieldy and they start to see how it should have been designed in the first place. The next time that developer has to design a similiar piece of software they wont make the same mistakes.
This is where Design Patterns come in. A designer/programmer well versed in these patterns can see the end result of that first scenario before it happens. Learning design patterns helps teach good design faster. The solution to each common design problem is encapsulated in a well documented pattern.
> I haven't met a gifted programmer who made
> extensive use of them,
Wow, I've met alot of people who think they are gifted programmers and write really badly designed code that works (at first) who don't use design patterns.
On the other hand, if you judge code and design not by how much of a hack it is, but by how elegant it is, then Design patterns can make a huge difference. There is nothing beautiful about trying to cram a square peg in a round hole, even when it works.
So, instead of "paint-by-numbers", I see design patterns as a "magic eight ball" that can tell you what problems your design will have before you even start programming.
> but they seem to be a sort of helpful template
> for average coders of the sort hired in legion
> strength for "enterprise" projects in Java and
> the like.
While I am a fairly technical c++ programmer by trade, there is no reason to belittle java or "enterprise" programmers. There are some HUGE projects out there that simply cannot by done right by a few people hacking away. And I feel sorry for them when it becomes time for V2.
Burn, baby burn (Score:1)
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.
Re:Burn, baby burn (Score:1)
Funny, where I work we have a singleton template that lets me just say "Singleton foo;". All such declarations (with the same ClassName) actually get you the same object. I've used it a zillion times and never had a problem. I've never looked at the code for it (never had to!), but it never occured to me that it would be very complex. I'm not dissagreeing with you, I'm just curious what's supposed to be the big problem with singleton?
Re:Burn, baby burn (Score:1)
Singleton anxiety (Score:1)
FYI: Fixing Singleton in C++ (Score:2)
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).
D'oh (Score:1)
I hate it when I forget to change "you're" into "your" after an edit and don't notice in the preview. Sorry.
Re:Help? (Score:3, Informative)
Usually programmers "use these" without even knowing them (after all, they are common solutions to common problems).
Re:Help? (Score:4, Informative)
Here is a FAQ [oswego.edu].
Patterns are named solutions to problems, which resolve constraints in a a given context. They aren't rigid (like, say, a template), they are abstractions of commonly occuring problems and solutions that occur in programming. For instance, "one object needs to do something to another group of objects" might be a problem, and the Visitor pattern might help you find the solution. The code you use to implement the pattern might be radically different than the code someone else uses, but underneath the pattern is the same.
They come from Christopher Alexander's work in architecture, where he saw the same recurring patterns in architecture and felt that they arose from deeper truths about people and societies. An example of Alexander's architectural patterns: "Intimacy Gradient", which is a pattern that describes how the front of a home is less personal and intimate than the back of a home. For instance you might leave your stuff laying out in a back room, but you keep the front room neat for guests.
Very interesting from a philosophical point of view as well, and helps you to better understand why some programs/houses/objects are pleasant to work with, and others are a chore.
Here's a little about design patterns (Score:3, Interesting)
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.
Java Companion (Free Download) (Score:5, Informative)
Re:Java Companion (Free Download) (Score:1)
It is nearly the same document, only with a few added items, and both are written by James Cooper. It is a very good companion to the GoF book!
Re:Java Companion (Free Download) (Score:2, Informative)
I have this guy's book. "Java Design Patterns: A Tutorial" It is the worst Patterns book I have ever read. If you don't believe me just check the reviews at amazon. I've you're looking for thye definative Java Patterns, I suggest looking at another author. Mark Grand also sucks. So far the Stelting-Maasen book is the best I've seen, after the GoF Book.
Book Review Ratings (Score:1)
Subtle irony warning... (Score:2)
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.
Smalltalk version of Patterns book, my own project (Score:2, Interesting)
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
How much for... (Score:2)
why i don't give a rat's ass about design patterns (Score:3, Insightful)
Propoganda
Design Patterns in Dynamic Programming [norvig.com]
"Design Patterns" Aren't [plover.com] (google cache link [google.com])
Re:why i don't give a rat's ass about design patte (Score:1)
I was moving house and changing ISPs.
Singleton Pattern / Double-check Locking (Score:1)
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.
You forgot to make getInstance() static... (Score:1)
{
private static Something s = new Something();
private Something() {}
public static Something getInstance() { return s; }
}
Re:You forgot to make getInstance() static... (Score:2)
Re:Singleton Pattern / Double-check Locking (Score:2, Interesting)
Singleton foo;
and I'm done with it. Doesn't even matter if Something was originally designed for use as a singleton. (Yes, someone had to write the singleton template, but they only had to do it once, and in any case, it wasn't me)
Re:Singleton Pattern / Double-check Locking (Score:1)
Singleton<Something> foo;
Re:Singleton Pattern / Double-check Locking (Score:1)
Actually the way I've typically used this is in a module where the header only exposes static functions. The implementaion of these functions then call members of the singleton. This lets the object in question do what ever it needs to (one-time initialization, internal cacheing) without the caller having to even know it exists.
Re:Singleton Pattern / Double-check Locking (Score:2)
They specifically cover your solution in that article. Hint: yours only works if there are no Object references or more than one primitive member in the class.
Obligatory Contrarian View on Patterns (Score:4, Insightful)
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.
Can you recommend . . . (Score:1)
Re:Can you recommend . . . (Score:2)
I said *nothing* about dispatching code here from tables. In practice, it is not needed/helpful that often. The relationship between rows and behavior often does not stay one-to-one over the long-run. Thus, there is little or no benefit to tying them one-to-one most of the time.
However, just about *any* dynamically-typed or type-free language could do such. If you can hook say Python or Perl or LISP to a RDBMS, then you can do it. Heck, even MS-Access has an Eval() function IIRC if you want/have-to use that P.O.S.
really interesting (Score:1)
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.
Re:really interesting (Score:2)
I would have to see a specific example of a something in OOP that is better at being reused than a procedural/relational approach.
Note that "reuse" seems to be dropping off the list of "standard OO benefits" in OO circles. I have heard quite a few OO fans say, "reuse is not where it's at". And, I have cited some Wiki discussion groups and a Dr. Dobbs article that lean this way also. (Just follow the "myths" link on my website to "reuse".)
I am not sure exactly what the benefits of OOP are *supposed* to be. Some OO fans lean toward it being better to mentally grok, while others insist that it makes software more "change-friendly" (but not necessarily easier). Of course, I disagree with both of those claims.
Consistency of both design methodology and benefit reasons in the OO world is sorely lacking.
I personally think OOP is popular (among the S.E. elite) due to these two factors:
1. Some people just seem to think better under OOP due to their *particular* brain/phsycology.
2. Written OO material tends to overemphasize certain change patterns that OO is particular good at, at the expense of change patterns that OOP has a tougher time with. IOW, they present a non-representative (frequency-wise) list of change problems, and then conveniently show OOP "fixing" them.
Re:really interesting (Score:1)
> something in OOP that is better at being reused
> than a procedural/relational approach.
Although I'm not primarily a java programmer, a nice example that jumps out at me would be Java applets. You can simply inherit the majority of functionality that you do not need to change from code provided in the framework and simply provide your own implementation changes where appropriate. (I was going to use MFC as an example, but it sucks so I might have been disproving my own point). This amounts to creating an entirely new "noun" with fairly complex functionality in very few lines of code. Perhaps the cost here is knowing what does go one behind the scenes.
Certainly the same effect could be achieved by using OO-like practices in a proceedural (or possibly relational?) context, but it would not be nearly as elegant. I believe this is the case with the majority of OOP benefits.
Furthermore, designing using very specific "nouns" has the side affect of predisposing your code to reuse. When you go to program something else and need that same "noun" you already have it. I have found that proceedural programmers tend not design their software in a way that allows it to be immediately applicable to other tasks.
> 1. Some people just seem to think better under
> OOP due to their *particular* brain/phsycology.
hmmm.. never gave too much thought to this, but it seems most programming paradigms use some kind of analogy model to help their users. Nonetheless, if what you say is true, you are giving a good arguement FOR OOP.
> 2. Written OO material tends to overemphasize
> certain change patterns that OO is particular
> good at, at the expense of change patterns that
> OOP has a tougher time with. IOW, they present
> a non-representative (frequency-wise) list of
> change problems, and then conveniently show
> OOP "fixing" them.
I'm definitely interested in what you're suggesting. Do you have any references that catalog some of these different problems OO struggles with (and other paradigms do not)?
Most of the opinions that I have are based on either studying or maintaining code written with various approaches. I'm by no means an OO zealot and can appreciate elegance in any form. However, the OO code I've seen *tends* to be more readable/elegant than most proceedural. And the bad OO code is sometimes a result of using alot of proceedural ideas (or in some cases, design problems that could be fixed w/ GoF patterns
Re:really interesting (Score:2)
Inheritance is simply a form of "overriding" defaults. In p/r you can also make it so that blank table cells or that not supplying a named parameter result in some default behavior. It is not more code than inheritance.
But where inheritance fails is when changes are no longer hierarchical or not mutually-exclusive. You cannot easily "grab" behavior or attributes from a peer branch on the inheritance tree without a lot of code shuffling. P/r techniques allow one to use sets, for example, instead of trees if changes progress in a non-tree fashion. OOP requires a complete code structure change to go from tree-based feature management to set-based feature management.
IOW, p/r does not make the code structure resemble your currently-used data structure. That way you can change the data structure characteristics/shape without major code overhauls. You may have to change an expression or two, but you don't have to *move* large chunks of code around.
(* Furthermore, designing using very specific "nouns" has the side affect of predisposing your code to reuse. *)
I addressed "reuse" in a sister message.
(* I have found that proceedural programmers tend not design their software in a way that allows it to be immediately applicable to other tasks. *)
I find procedural programmers do all kinds of different *bad* crap if you let them. (Same with OOP.)
I will agree that OOP training *by tradition* encourages people to pay more attention to software engineering issues. However, the same could be done with p/r techniques, but is generally not.
It is like the Hypocratic Oath being part of medical training, but not say jet mechanics. It is tradition, not need, that makes it that way.
Are going to argue that bad OO is better than bad p/r? I know some OO fans who even disagree with this. They have some OO-gone-bad horror stories of their own. IMO, bad p/r is at least more consistent than bad OO in practice. OO training makes stupid programmers have more oddball ways to obfuscicate OO code.
Thus, we should probably compare good OO[1] to good p/r rather than bad to bad.
[1] If there is such a thing
(* Nonetheless, if what you say is true, you are giving a good arguement FOR OOP. *)
I did not say *all*, or even *most* brains are a better fit for OOP. There is just no decent data on this issue. It may not be practical to pack rat a language with every paradigm and construct just incase somebody thinks a given way.
(* I'm definitely interested in what you're suggesting. Do you have any references that catalog some of these different problems OO struggles with *)
I suggest you poke around my website. A starting point may be:
http://geocities.com/tablizer/change.htm#people
(AKA, "people types")
(* However, the OO code I've seen *tends* to be more readable/elegant than most proceedural. And the bad OO code is sometimes a result of using alot of proceedural ideas (or in some cases, design problems that could be fixed w/ GoF patterns *)
Well, I would be interested in seeing something specific, hopefully from my familiar domain (custom biz apps), and not say Chemistry. I have no feeling for the change patterns of such industries.
"Elegant" is often subjective, BTW.
Re:really interesting (Score:1)
Substitute Java servlets if it makes you feel better.. they work the same way.
I don't see reuse (was: really interesting) (Score:2)
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.)
Re:I don't see reuse (was: really interesting) (Score:2)
One cannot easily do set-based with inheritance-like structures with behavior. It takes a different approach altogether. The lack of guarenteed mutual-exclusion[1] means things may overlap or conflict if we try to do it the same way OOP inheritance does it. (Multiple inheritance can run into these problems, and thus it is mostly only used to inherit widely *different* things/interfaces to reduce chances of such collisions/conflicts.)
[1] This is *not* a bad thing, because it reflects the real world's change patterns (in my observation). Mutual exclusion is simply rarer than OO books make it out to be, at least in long-term biz modeling. A common example is OO books showing a bank account split into Checkings and Savings account subtypes. Well, some banks have offered *hybrids* in the past. Inheritance does not handle catdogs very well.
Re:Obligatory Contrarian View on Patterns (Score:2)
I have heard this claimed a jillion times, but have never seen an actual side-by-side code example, at least not from the biz domain.
Past attempts have failed mostly because:
1. They fail to consider the down-sides of their approach. IOW, they assume a certain change pattern that does not fit reality well, at least not as I perceive. For example, they will show how easy it is to add a "new subtype" in OOP. However, they rarely consider adding a new operation (to existing subtypes), or the fact that subtyping may be a bad model to begin with. Subtyping assumes a mutual exclusiveness for example. Polymorphism is heavily *tied* to the assumption of mutual exclusiveness. That is "coupling" in itself. I often (correctly) assume that features may drift orthogonal from each other over time, not M.E.
2. They present lame procedural/relational code that can be fixed. Some OO fans don't "get" good p/r IMO. They have never been taught well.
Re:Obligatory Contrarian View on Patterns (Score:2)
Each of these bundle a verb: The iterator bundles "traversing the data structure", the command bundles some piece of functionality, the strategy does the same thing but inverted relative to the command.
To me, the noun-like patterns were interesting and sometime useful (I always though "flyweight" was cool), but I've gotten a lot more milage out of the verb-like patterns.
I'll read your critiques here in a bit, but I would be curious about any response or reaction you'd have to my thoughts that many of the patterns are verb patterns. (Feel free to privately email if you don't want to do this on Slashdot.)
Re:Obligatory Contrarian View on Patterns (Score:2)
Most of the verb-centric patterns seem to be reinventing the database in my observation. For example, "iterator" may *duplicate* the interface and implementation of iteration for every class that needs it. In the p/r world, you don't have to reimpliment it over and over again. Plus, iterator lacks expression-based filtering, joins, sorts, indexing, etc. without yet more hand-coding and interface expansion.
Every participant class ends up carrying around the "baggage" to be able to do otherwise common, database-like operations on it. Sure, there are ways to factor some of this to a central spot, but it tends to have other side-effects, and your central package is a hand-built half-ess database anyhow. You might as well byte the bullet and do it right.
We would probably have to visit (pun) a specific example together. You mentioned taking this to email.
this book is just a poorly written rehash (Score:1)
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.
Double checked locking (Score:1)
For those unfamiliar with double checked locking, it's explained here [umd.edu].
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.
Design Patterns Java Workbook (Score:2)
It's sitting on my desk right now. I'm liking it...
Double-checked locking (Score:1)
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".
Re:What's a good programming language in general? (Score:2)
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
Re:What's a good programming language in general? (Score:2, Informative)
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...
Re:What's a good programming language in general? (Score:2, Insightful)
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 [cuj.com] 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.
Oh dear classic troll attempt... (Score:2)
The best programming language is of course the most obscure, that way you keep your job