Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Book Review: Elemental Design Patterns

samzenpus posted more than 2 years ago | from the read-all-about-it dept.

Software 129

jkauzlar writes "Believe it or not, it's been 18 years since Design Patterns by Gamma, et al, first began to hit the desks of programmers world-wide. This was a work of undeniable influence and usefulness, but there is criticism however that pattern-abuse has lead to over-architected software. This failure is perhaps due to wide-spread use of patterns as templates instead of understanding their underlying 'grammar' of this language such that it may be applied gracefully to the problem at hand. What's been missing until now is a sufficiently authoritative study of design patterns at this 'grammatical' level of abstraction. Jason McC. Smith, through a surprisingly captivating series of analytic twists and turns, has developed a theory of Elemental Design Patterns that may yet rejuvenate this aging topic." Keep reading for the rest of Joe's review.Much as developing a large taxonomy of star-types in astronomy lead to and enabled theories of star formation, or a classification of organic life lead to studies of genetics, it makes sense that the large volumes of collected object-oriented design patterns should somehow lead to a generic understanding of them. Smith actually approached this in an attempt to solve a very practical problem: given the variety of ways a particular pattern can be implemented, how can one be recognized programmatically with a degree of certainty?

What's most fascinating about Elemental Design Patterns is the analysis performed in working out a solution to the question of how a pattern may be defined in a way that's language-agnostic and flexible to differing implementations. This was a success: his resulting pattern recognition tool even found unintentional usages of well-known design patterns in a large legacy code base, which could then be refactored from the ugly 'accidental usage' to transform apparent chaos into maintainable order.

The basic idea is that every pattern is composed of elemental patterns. For example, the 'Factory Method' pattern may be decomposed into four EDPs (elemental design patterns): 'Create Object', 'Fulfill Method', 'Conglomeration' and 'Retrieve'. The 'Pattern Instance Notation', introduced in this book, and which serves as an extension to UML, helps visualize the relationships between the four sub-patterns and the larger pattern. No doubt readers will find the notation useful in their own work.

This premise's success or failure hinges on two questions: are the set of patterns really elemental? and can the set of patterns be complete? Oddly, the patterns listed in the book are NOT complete: "this book touches on only one-quarter, at best, of the possible EDPs that exist" (p. 107). The fact that this book (which defines 16 patterns in depth) is only the beginning of a project is not well-communicated. Those who might benefit from a complete listing of EDPs (i.e. analysis tool makers) might be puzzled at how to immediately put this book to use if it's not complete. After all, Smith insists in the Preface that "this book is meant to be used." To me, this implies it should serve as more than a basis for research or design-skills edification.

As for them being elemental, in the sense that all possible 'macro-patterns' may be built from them, Smith backs up this claim with the help of a mathematical formal system called rho-calculus, which is introduced in some depth in the appendix, but avoided in the body of the text for readability's sake. Readers wanting a full mathematical treatment are referred to Smith's Ph.D thesis.

What makes the book worth reading and re-reading is in the methods employed to analytically derive EDPs. As dull as I probably make it sound, Smith gives the entertaining first half of the book an almost 'novelistic', first-person quality in which the reader is engaged to experience Smith's insights first-hand. In a sense, the EDPs are 'unfolded' from simple concepts like the degrees of method or object similarity in a method-call relationship.

Understanding this point is important to understanding EDPs: a method call is not just a method call from a 'micro-patterns' perspective. Calling a very different method on the same object is semantically distinct from calling a very similar method on a very different object. The first is described by the EDP 'Conglomeration' (breaking larger tasks into subtasks); the second, by the EDP 'Redirection' (redirecting a process to another object). Of course, the terms 'similar' and 'different' are fuzzy qualifiers to programmers and there's bound to be some debate on how these terms are applied. Smith, in order to make this distinction, puts faith in the developer's ability to name classes and methods. But anyway, such 'semantic' relationships are the real building-blocks of the higher-level patterns. Once other object-oriented principles are considered, like inheritance, the EDP list grows.

The importance of Elemental Design Patterns from a designer's perspective should now be more clear. I kept stressing the word 'semantic' in the last paragraph because what this book strives to do is provide a *language* for describing object-oriented structure that, first of all, doesn't rely on the OO language itself (C++, Smalltalk, Java, Javascript, etc), and more notably, which takes into account the designer's purpose for employing simple devices like method calls and class extension. As I said earlier, a method call is not just a method call. There may be a dozen or so 'structural' reasons to call a method, and each reason is given it's own 'word' (i.e. EDP) in Smith's language. It stands to reason that a designer with a firmer grasp on his own intentions is a more effective designer.

You can purchase Elemental Design Patterns from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

129 comments

Sorry! There are no comments related to the filter you selected.

That was painful (5, Insightful)

Anonymous Coward | more than 2 years ago | (#40212345)

That review painful to read. Dunno if it’s the verbosity or what but it felt less technical and more like prose. I think too it got a bit too much into the books contents, almost trying to paraphrase the book. It’s supposed to tell me whether I want to read the book, not provide me the Coles notes version.

As for the topic itself, while I find it interesting someone has done serious analysis on the topic, I think in practice it comes down to three things:
1) Experience
2) Common sense
3) Checking your ego at the door

First one applies to everything. OO design is harder than people think. It takes long term experience and many failed approaches before one develops an intuitive sense of what is going to work at well in code as does on paper.. and what will survive the inevitable scope changes and end of project quick hacks with some elegance in tact.

Second one kinda ties in with the first one. Design complexity should match project scale and expected maintenance. Don’t abstract stuff that is very unlikely will ever need to be changed/will require massive re-write anyway. Abstract the hell out of stuff that would likely change.

Annd third one ties into the second one. A lot of OO insanity comes from people trying to show off how big their brain is by cramming every design pattern they can think of into the software. Hey look, I created an abstract factory that takes a creation behaviour (built from an abstract behaviour) and covered it up in a facade! Just code it the way it makes sense, not what makes the most badass class diagram!

That's not to say design patterns arn't useful. But I view them as problem solvers, not general usage code. You shouldn't instinctively try to use design patterns for everything.

Re:That was painful (2)

Gr8Apes (679165) | more than 2 years ago | (#40212761)

You shouldn't have posted anon... these are some good points. I'd go further - most software components should be designed with no more than 4 basic patterns in them - this allows for maintenance folks and others to come along later and understand what's going on without 6 months of due process. Note - these are components, not solutions. Components themselves generally should have very little internal abstraction - this means that a component should be testable and verifiable. If you abstract things within it, this becomes a much more difficult process. Lastly, components should follow functional boundaries as much as possible, again, this eases testing and makes for "complete" units.

Re:That was painful (0)

Anonymous Coward | more than 2 years ago | (#40212781)

Whenever someone mentions design patterns to me, my eyes water and my mind goes numb and I jump to number 3. Everything has its place, but some people take patterns to the extreme.

When I was a contractor so many places brought this subject up only to find they weren't really using them or not using them correctly.

Getting my Masters I had one professor who obsessed over them, it drove me nuts, I learned an awful lot but sometimes it took way longer trying to implement a pattern for everything when I could have had it done two days and 100 lines ago. Patterns always seemed to be labels for things that were obvious to me anyway.

Re:That was painful (1)

plover (150551) | more than 2 years ago | (#40213117)

Patterns always seemed to be labels for things that were obvious to me anyway.

That's almost the exact definition of what a pattern is supposed to be. It should be an obvious name, so we can all talk about the same basic concept with a common shared language. They aren't magic beans you drop in code. they are concepts.

After you grok the concepts they contain, then they become magic beans that you can drop into your code. See the difference?

Re:That was painful (0)

Anonymous Coward | more than 2 years ago | (#40213187)

You sound like you fall into number 3. When I wrote that I knew someone who point that out to me, and go "see". Oye

Re:That was painful (2)

plover (150551) | more than 2 years ago | (#40213535)

I fall into the category of "write simple methods that are easily proven with automated unit tests." When it comes to patterns, if I see one, they tell me "because you did it this way, it means X to performance, Y to maintainability, and Z to correctness."

I care a lot more about design principles than about design patterns. Give me simple and clear code first. When it follows a pattern, I'll understand the consequences quicker. If it's close to a pattern, I'll stop and think about the differences. Why did you do this? What does this change solve? Your design doesn't have to follow a published pattern, but it has to have a valid purpose.

Re:That was painful (4, Informative)

Eponymous Hero (2090636) | more than 2 years ago | (#40212823)

i have mod points to give you but you are maxed. there is a word for what you're talking about: anti-patterns. http://en.wikipedia.org/wiki/Anti-pattern [wikipedia.org]

Re:That was painful (0)

Anonymous Coward | more than 2 years ago | (#40213397)

This comment was painful. First of all, prose is prose and reviews summarize books. get over it. Second, checking your ego at the door? I've seen untold numbers of lines of crap code written by 'cowboy programmers' who don't like to design in advance, who don't take design seriously or don't want to learn from book-readin'. I've spent years of my life debugging and rewriting that software after the fact, because a) it was impossible to figure out what the original guy was trying to do (i.e., he or she didn't adhere to common practices/patterns), b) it wasn't extensible, modular, etc (all byproducts of using patterns).

Of course, they DO lead to over-design and that's what experience is for to avoid, but to be knowledgeable and curious about how other people are designing software is the difference between an average developer and a good one. Mostly your post is not far off, but the righteous attitude is a real problem in this industry. Some people deal with software on the scale of hundreds of thousands or millions of lines of code, but most developers deal with smaller apps, and mostly web apps. In the former camp, the dev and design process simply has to be a lot more strict and these 'big words' (as you see them) come in handy pretty often.

Re:That was painful (0)

Anonymous Coward | more than 2 years ago | (#40213557)

Much of the wheel-spinning in this area comes from a failure to define two common terms: design and architecture. In the systems engineering world (http://www.sstc-online.org/Proceedings/2005/PDFFiles/JOC846.pdf) design is "the plan for fulfilling functional requirements" and architecture is "the plan for fulfilling non-functional (aka: quality or performance) requirements". With these terms defined, everything else falls into place.

What design patterns should be used? It depends on what functional requirements are being fulfilled.
Is architecture pattern X appropriate? Only if there is some non-functional requirement driving it.

Start with high-level capabilities, analyze and decompose them into detailed functional and non-functional requirements, then choose the appropriate design and architecture patterns for each requirement. If a pattern can't be traced to a requirement, then it isn't needed.

Re:That was painful (1)

greg1104 (461138) | more than 2 years ago | (#40213797)

Hey look, I created an abstract factory that takes a creation behaviour (built from an abstract behaviour) and covered it up in a facade!

You are such a newb; obviously this is useless unless you then wrap the result in an iterator.

Re:That was painful (1)

Anonymous Coward | more than 2 years ago | (#40214393)

A bit of knowledge is a dangerous thing. I find it's better to start solving the problem at hand and let the patterns emerge naturally rather than shoe-horning the problem into a predefined design pattern from the start.

When I was young and inexperienced I used to just code whatever needed to be done to solve the problem with a view to cleaning up duplication and other mess later, but usually never got round to it, so my programs worked but lacked maintainability. Over the years I've learnt various stuff from the coding world, OO, Design patterns, TDD etc and tried to apply these things to *everything*. The result, an overengineered codebase that had abstractions over abstractions and took ages to get anything done, it was needlessly over complicated. These days when I write something, I try to not think about what pattern would fit the problem, but rather just start coding and keep an eye out for patterns as they emerge. Then once I identify some duplication or something that looks very much like a pattern, refactor!

Think coding Taoism - Let the code show you the "way" rather than forcing it into something it's not... ;-)

Re:That was painful (0)

Anonymous Coward | more than 2 years ago | (#40214901)

That would seem to be the first two items listed.

As you (and OP) said.. it takes experience to get to the point where you can even understand design patterns, and then years of using them wrong and seeing _why_ certain things work and certain things don't before you can use them effectively.

It also takes common sense to, as you said, not just blindly apply them to anything or worse, contort your software to fit them for the sake of it.

Re:That was painful (2)

jkauzlar (596349) | more than 2 years ago | (#40214683)

Reviewer here.. you say 'It's supposed to tell me whether I want to read the book, not provide the Coles notes version.' So, how should I know whether you want to read the book? I'd prefer to tell you what it's about and you're free to decide whether it's something you'd be interested in. I did find it interesting, but I really don't know the scope of the potential audience for such a book.

As for your critique of design patterns in general, you're spot-on, but nothing new. The same critiques have been made repeatedly for at least 10 years and yet people continue to find a few patterns catalogues useful. I mean, they're basically just common ways of structuring code, so how could that not be useful? Though, as you say, just don't use them as goals to be achieved in order to have cooler-looking class diagrams.

Re:That was painful (1)

Anrego (830717) | more than 2 years ago | (#40215857)

Not to pile on the hate (I didn't find the review hard to read per se.. and nothing wrong with some elegant phrasing) but I too found the review got a little too much into the topic.

Maybe it's just personal preference, but when I read a review, I am not yet ready to delve into the subject matter. I'm primarily looking for a quick overview of the subject area, scope, and target audience (specifically whether I fall into it), tone (cheerful, funny, dead seriousy, insightful, technical, etc.) and quality (well written, poorly written, lots of pictures, wall of text, etc.) to determine whether I want to commit some brain time. If I have to start thinking while reading the review, I may as well be reading the book ;p

This is more like a critique of the book or a discussion piece than a review. Which isn't a bad thing either. Certainly judging from the comments, I think it has served more to get people talking about design patterns vice the book itself or its subject matter (which I think is the case for most vook reviews anyway, I mean what discussion can be had about a book no one has read yet. How does one discuss a review).

Patterns over hyped? (4, Insightful)

darjen (879890) | more than 2 years ago | (#40212355)

I am a senior developer at a large publicly traded company. We have some pretty high volume systems, and I have yet to really use any other patterns besides MVC in my daily activities. I have also worked at several smaller consultant firms and never used them much before my current place. Maybe it's just because the type of problems I have been working on aren't complicated enough?

Re:Patterns over hyped? (2, Insightful)

Anonymous Coward | more than 2 years ago | (#40212391)

I always through most of the patterns in the Design Patterns book could have been better described as 'Workarounds for language(or library) limitations'

Re:Patterns over hyped? (1, Insightful)

stanlyb (1839382) | more than 2 years ago | (#40212431)

Seconded. And as of the "design pattern" hype, man, thank you for describing and defining how exactly i am walking and running. Man, if it was not you, i could not imagine even moving my left foot in front of my right foot, then my right....then my left.....MAN, god bless you, now when i am walking, i now that i am using "DESIG PATTERN WALKING UNDER THE SUNSHINE".

Re:Patterns over hyped? (0)

Anonymous Coward | more than 2 years ago | (#40212457)

I always through most of the patterns in the Design Patterns book could have been better described as 'Workarounds for language(or library) limitations'

As a good example of this in practice, see how Guava's EventBus [googlecode.com] replaces a huge chunk of the Publish-Subscribe pattern.

Re:Patterns over hyped? (1)

softwareGuy1024 (2564569) | more than 2 years ago | (#40212913)

Interesting, seems very similar to Qt's signals and slots.

Re:Patterns over hyped? (2)

JonySuede (1908576) | more than 2 years ago | (#40214069)

they both are reification of the Publish-Subscribe pattern. Patterns are use mostly to discus about code in a general way after the fact. It is quite rare to you go on choosing a mediator or a flyweight but looking back at a code base it is easy to find instances of patterns, whatever the language as they are implementation independent. The other use of pattern is to give a distilled experienced to a beginning programmer.

Re:Patterns over hyped? (0)

Anonymous Coward | more than 2 years ago | (#40213431)

That's great! Can you convince my boss to let us switch to lisp?

Re:Patterns over hyped? (1)

2.7182 (819680) | more than 2 years ago | (#40215713)

I think your comment (a joke?) is just the right response to the abuse/misuse of OO oriented programming. It's really not that complicated - the situation is a hammer looking for a nail. When you find a nail you are sooo happy to have a hammer. But when you find you need a hex wrench to put together your Ikea book shelf, well, then you end up with a bad situation. (I'm sure an equivalent comment has been said many many times before...)

I used to regularly teach data structures in the lates 90s when this stuff was the rage. There was a lot of pressure from the students actually to do more of it, since they were young vulnerable to the pressures of fads. As a person largely interested in numerics and scientific programming, I find it irksome that this stuff is sold by (some) people as a cure all. I was really surprised one day when I was discussing something like the behavior of arithmetic in C++ and the first thing the kid does after he opens his laptop is start defining a class in order to test what I was saying.

Anyway, being a zealot isn't a great idea. But if I had to pick one thing to do everything in (you shouldn't!), Lisp wouldn't be a bad choice. Lisp and Fortran are old languages that are still around not just for legacy reasons.

Re:Patterns over hyped? (1)

GreatBunzinni (642500) | more than 2 years ago | (#40215993)

This doesn't make sense, and I am lead to believe that you actually don't know what a design pattern is. After all, no matter how complete a programming language or library might be, you still need to put stuff together, and when you put stuff up together you better choose to put them together in the best way possible, that actually solves your problems.

To better explain what design patterns are, we can compare them to a more mundane field: civil engineering/construction. You see, while a programming language and API represents the individual building materials used in construction, such as mortar, concrete, steel rebar and I-beams, design patterns represent a specific way which these buildig materials are put together and made to work, such as reinforced concrete slabs, prefabricated joists, trusses, columns, beams, etc... It is helpful to think of a construction project in terms of individual components, by decomposing the entire structure into structural elements and the construction techniques that are used to implement them, than wasting time thinking about how you will arrange individual pebbles in a concrete mix, or how a rebar will be gripped by the concrete.

So, in essence, design patterns provide you with a very convenient and useful way to think about pre-made solutions to specific problems, while saving you the time and need to reinvent the wheel each time you need to create a new component.

Re:Patterns over hyped? (1)

Anrego (830717) | more than 2 years ago | (#40212411)

I find a lot of them are very useful in extremely special circumstances.

There are some though that I do use on a fairly regular basis. The biggest ones being the factory pattern and observer/strategy patterns.

I also the Singleton more often than I like to admit.

Re:Patterns over hyped? (1)

vux984 (928602) | more than 2 years ago | (#40213583)

I also the Singleton more often than I like to admit.

Singletons are the modern global variable. We've all been trained to shun globals... and rightly so... but I think its gone too far.

People are afraid to use use globals and singletons, even where they make sense.

Sure every user control on your web page could open its own database connection and you can avoid a global or singleton by doing so.... but that doesn't mean you should.

Re:Patterns over hyped? (4, Insightful)

thePowerOfGrayskull (905905) | more than 2 years ago | (#40212437)

Alternatively you have implemented additional design patterns without knowing it.

That's something I've seen a lot - just because someone doesn't know a name for something doesn't mean that they can't use it. In interviews I've asked people to explain the factory pattern (arbitrary example) to me - and had them draw blanks. But a few questions reveals that they're familiar with it, and just never associated it with the name "factory pattern".

Re:Patterns over hyped? (1)

Quince alPillan (677281) | more than 2 years ago | (#40212741)

Oddly, I've never come across the concept of Object Oriented Design Patterns with specific names, nor have I heard of this book or the previous version before today. Are these patterns and their specific names commonly laid out across multiple titles that every junior programmer should come across, or are they esoteric and specific to the people who have read these books?

Re:Patterns over hyped? (1)

plopez (54068) | more than 2 years ago | (#40212875)

Yes and yes. It's considered esoteric because may haven't read up on the topic and everyone should at least be introduced to the concept of recurring design solutions.

You might want to either purchase the books at the book store of your choice or check them out of your local library.

Re:Patterns over hyped? (1)

Anonymous Coward | more than 2 years ago | (#40212881)

The original Design Patterns book linked in the summary was written by four people (so-called "Gang of Four") back in the '90s. These are patterns that were found to be almost as useful as encapsulation and polymorphism familiar to C++ and Java programmers, but which cannot be conveniently expressed as a primitive in a language (unlike inheritance, for example). Some of them came out of the Smalltalk community in the '80s.

Experienced object-oriented programmers are expected to know many of these patterns. In a nutshell, the larger the codebase and the more tiers involved in your solution, the more these patterns are useful, even essential. Also, it will help you understand the base class libraries for Java and .NET since those were obviously quite informed by design patterns.

Unfortunately the Gang of Four book was written partly as a pattern reference, so it's not so easy going as a tutorial for those without either a CS degree or 10+ years programming experience. I'd advise start by looking for tutorials on the web.

I would take some of the snarky comments here with a grain of salt. Those who spend most of their efforts in the presentation tier might not see the usefulness of many of these, other than MVC.

Re:Patterns over hyped? (2)

Jason Smith (3310) | more than 2 years ago | (#40214735)

"Unfortunately the Gang of Four book was written partly as a pattern reference, so it's not so easy going as a tutorial for those without either a CS degree or 10+ years programming experience."

Exactly. In my experience as an educator, I've seen both undergraduate and graduate students struggle with the GoF book when handed it with only the edict "Thou shalt do this." What inevitably happens is that they start copying and pasting the sample implementations as rote mantras, instead of seeing the underlying concepts as mutable pieces that they can work with to create a solution that fits what *they* need.

That's where the EDPs come in. They give a ground level set of concepts and taxonomy to start composing the more abstract notions in the GoF text. For those new to patterns, they give an introductory way of approaching the literature, and thinking about even the most basic concepts of programming independent of implementation details. For folks who have been using patterns for years, they give (perhaps) a new way of looking at the tools to give them new uses.

The design patterns literature is full of an immense amount of good information... when it's used well. When it's just copied and pasted, it can easily lead to worse problems.

Re:Patterns over hyped? (1)

Darinbob (1142669) | more than 2 years ago | (#40213221)

These aren't academic books, they probably aren't taught in schools. But there are many managers and team leads out there who have read and memorized them and who assume every programmers knows it all as well. The books tend to be bought in bulk by teams; some team member reads it and becomes converted and convinces other team members are encouraged to purchase the books, or a manager puts it on a list of titles all new hires should purchase (all charged to the company too). It's a word of mouth thing.

Now the book is not bad. There's some good stuff in there, but parts feel contrived. Overall the book's biggest flaw though is that some people treat it like a silver bullet that can solve all your problems. The ideas are more important than trying to treat it as a reference book, and memorizing names of the patterns is just a silly thing to do.

Re:Patterns over hyped? (1)

Quince alPillan (677281) | more than 2 years ago | (#40213339)

So it's a bit like SCRUM. Cult-like with some good gems, generally not taught in academic circles, treated as a silver bullet to solve all problems by non-coders, and ultimately useless unless its used as intended, which it generally isn't.

Re:Patterns over hyped? (0)

Anonymous Coward | more than 2 years ago | (#40213267)

thePowerOfGrayskull's observation that people "implemented additional design patterns without knowing it" is dead-on. I've been a developer since prior to the publication of the Gang of Four "Design Patterns" book, and the only real use I got from it was to give names to things developers were already doing. Which I suppose is helpful in communicating. But at no point in my career before or since did I take a pattern from the book, and make use of it in a design; it's always been solving a problem based on what makes sense to do, or by reference to actual similar implementations that I'd encountered. I think that's true for most developers. So I'm inclined to agree that patterns are over-hyped; these books are just recognizing and naming things, and creating a taxonomy. That good solutions have similarities is a matter of form following function - to go from pattern to implementation, rather than recognizing a pattern in the implementation afterward, gets the cart before the horse.

That is why I wonder if patterns are useful (1)

SuperKendall (25149) | more than 2 years ago | (#40213287)

Alternatively you have implemented additional design patterns without knowing it.

I'm sure that he has.

The reason is that a lot of the classical design patterns are such obviously good ways of doing things, that good programmers use them naturally even without knowing or reading about them before.

That leads me to wonder, how useful are design patterns really? In the end what they really seem to be, is simply a way to communicate a good way of building software to people who do not intuit the use of these things naturally.

The real question is do they work for that task? After many years of experience working with programmers of many different levels, I do not think they achieve that goal. Programmers who do not naturally grasp all of the things the patterns try to teach do not end up building better software with some understanding of the patterns. Instead they end up with a slightly pattern based mess, sometimes with patterns that are not really used as they are meant to be, sometimes with a horrendous number of patterns stuck together to make a bloated monster.

Do many people really feel like they learned much from careful studies of pattern books? I went through a couple in CS course in college based around patterns but honestly I never felt like I learned anything I would not have simply come across on my own (and as you note, indeed I had been using many of the patterns without having known the "official" names).

One could also claim that for advanced programmers patterns gives you terms you can use to discuss the structure of software. But even that has been of very limited value in practice, when working with teams of advanced programmers...

I just can't see that design patterns are nearly as useful to learn for programming as something like algorithms, many of which are not nearly so intuitive a thing that you would discover easily.

Re:Patterns over hyped? (0)

Anonymous Coward | more than 2 years ago | (#40212625)

The main use of Design Patterns is so that you can say "Hey, I'm a smart software engineer. Are you a smart software engineer?" It's reserved pretty much for interviews. Sort of like how Google has very, very long interviews which boil down to the question, "Did you just get out of grad school? 'Cause we think practical knowledge is stupid compared with what you learn in grad school and never use in real life software development."

Really, though, the main thing is having built up the experience and breadth of knowledge to know where to look if you run into a particular type of problem. "Design Patterns" was utterly useless to me (except possibly for interview preparation) because the problems and solutions presented were all pretty fucking obvious to me or had severe failings that'd make them poor choices in any of my work. Working as a developer has constraints both on the types of problems you work on and the types of solutions you're allowed to pursue, so it's perfectly reasonable to think that almost none of the book will ever serve you practically. In fact, if you pick up "Design Patterns" and think to yourself "Oh, I should use this! And this!", the odds are you're like a kid applying to colleges who uses the thesaurus to make a much worse essay than they'd write if they didn't have a thesaurus.

Re:Patterns over hyped? (1)

stanlyb (1839382) | more than 2 years ago | (#40214063)

I remember, when i was asked which container is the fastest one, and i was extremely surprised when i was told that the HASH table is the fastest one.... What the frack? What kind of idiots would try to find the fastest type of container, and always, i repeat ALWAYS would find out that the hash table is the fastest one!!!!!!
Nevertheless, now i know why some big companies and some big sites are having their servers unable to handle a few hundreds of thousands requests even with their unlimited budget. You wonder why? I will answer you: HASH TABLE.

Re:Patterns over hyped? (2)

Jason Smith (3310) | more than 2 years ago | (#40214771)

I think you understand design patterns better than most people, to be honest. Copying and pasting a design pattern is the worst way of going about it, IMO. The bit that most people seem to miss, is that if it's not what you need, alter it to suit your purpose.

That was actually a main reason for writing this book - to try and provide folks with an easier ramp-up to the existing design patterns literature in a way that got across the point that these patterns are both a) composed of smaller pieces that are understandable, and b) made to be custom-tailored.

It's not the structure of a design pattern that is important, it's the concepts that it embodies. Fulfill those concepts in a way particular to your language, problem, or system, and you're still using that pattern, even if it doesn't look much like the example source provided.

Of course, it really isn't obvious that that's the case when we haven't had a good underlying taxonomy for those concepts... hence the book.

Re:Patterns over hyped? (1)

Darinbob (1142669) | more than 2 years ago | (#40213043)

I haven't really used patterns either. I was at a company though where several engineers were religiously devoted to patterns. They would quickly denigrate code or designs that did not match any of the listed patterns in their book, or if something did match a pattern but diverged from the API. I've been in meetings where half of the time was spent arguing which of two patterns most closely matched the design. So I have been trained by experience to regard design patterns as something that induces irrational behavior.

Now there's nothing wrong with design patterns per se. If a project has a certain set of patterns then it makes sense to follow them to keep the project coherent and understandable. But the idea of universal patterns that the entire world should follow and adopt to the letter is silliness. But then, things like this are just so rampant in computer science. So many goofy ideas that get follow unthinkingly without understanding them or knowing where they apply and where they don't. The cargo cult style of programming is still wide spread, we have armies of consultants spreading methodologies around, and I still run across people who look visibly worried when they see a "goto" in code.

Re:Patterns over hyped? (4, Insightful)

Nerdfest (867930) | more than 2 years ago | (#40213207)

Patter are simply giving names to the same things we've been doing for many, many years, and they're useful because of that. You can now describe your approach to a solution without showing actual code. Obvious examples most people will recognize are the Observer patter, Publish/Subscribe, and Factory. Many people implement these themselves long before someone gave an 'official' name to the solution. You use the right solution for the problem at hand, patterns just give a name to it ... or at least that's what they're supposed to do. I realize that some people consider it a contest to see if they can 'collect the whole set'.

Re:Patterns over hyped? (3, Informative)

GreatBunzinni (642500) | more than 2 years ago | (#40213301)

I am a senior developer at a large publicly traded company. We have some pretty high volume systems, and I have yet to really use any other patterns besides MVC in my daily activities. I have also worked at several smaller consultant firms and never used them much before my current place. Maybe it's just because the type of problems I have been working on aren't complicated enough?

I would guess that you do in fact use other patterns, but you actually do so without knowing. That isn't a bad thing, because ultimately what really counts is getting stuff done, and not write some kind of whitepaper announcing to the world that your company's current work is the result of an academically perfect implementation of a wide variety of design patterns.

Nonetheless, I find design patterns to be very important and extremely helpful, mainly because they can be seen as a set of pre-defined solutions to a set of well-known problems. In other words, they represent building blocks which have been adequately studied and therefore provide important properties that are already known beforehand.

Knowing these properties is extremely helpful when designing an application, because it lets you minimize the amount of work you will need to do to add some features, or even completely avoid it. By knowing design patterns you are able to come up with solutions to potential problems simply by identifying them and adopting the adequate design patterns to side-step it.

As an example, let's imagine we were developing some sort of 3D modelling application. We could start by defining that the application would consist of a database component, which stores all the information regarding the model, and a GUI component.

As you are already familiar with the MVC pattern [wikipedia.org] , we could design the database component with as a model and implement any representation of the 3D model as a different view. But let's go a bit beyond that.

In a 3D modelling application, we can expect that for each database component we might have multiple views. In addition, we might have an indeterminate number of components which might need to be aware of any information stored in the database. A nice way to pull this off is to design the database component as an observer pattern [wikipedia.org] . By doing this, you are free to extend the 3D modelling any time in the future to add a new component without any trouble at all. In addition, you are also able to completely replace other components by simply taking them off and plug in a replacement.

A 3D modelling application also needs to provide the user with a way to operate on the 3D model. Yet, more often than not we don't know everything the user wants to do and how he wants to do it. This means that it is a good idea to implement these operators in a way that you are free to add them in the future without being forced to rummage through half the source code tree. A good way to do this is to implement these modelling operators as a visitor pattern [wikipedia.org] . By doing this, you've just defined a generic interface for every operator you might need, and basically you only need to add a single class to implement any extra feature for the 3D modeller. In addition, if you also make sure you also include the inverse operator for every operator then an undo system will pretty much write itself.

The list goes on and on. You can implement your scene graph by employing a composite pattern [wikipedia.org] , you might implement the components to import models from an assorted list of data formats by writing each component as a strategy pattern [wikipedia.org] , you may implement a series of UI animations and input states around a state pattern [wikipedia.org] , etc etc etc.

And the best thing about this is that, by knowing design patterns, you are able to better express what you are doing and what you want others to do by referring to design patterns. For example, instead of talking about implementing a system of callbacks between a server and a set of clients by setting a common interface used to pass messages around and keep all clients coherent with the current state of the server... Just talk about implementing an observer pattern.

So, do familiarize yourself with design patterns. They may not solve all your problems and some of them may not be simple to wrap our head around them, but I assure you that once you do the amount of problems you will have to deal with will reduce significantly.

Singleton (3, Informative)

Chemisor (97276) | more than 2 years ago | (#40213417)

Well, singleton is useful, if only because it is the only way to implement the application object right. Doing it as a singleton allows access from outside the object, handles constructor exceptions, and ensures the destructor always gets called. Making the app object into anything else is bad:

If the app object is a global variable, you can not have exceptions in its constructor; terminate always gets called. Also, you do not get to control initialization order, so if you have any other global objects, they may or may not be initialized before it.

If the app object is a local variable in main, you can not get a pointer to it from anywhere else (and you commonly need to). The second problem is that the destructor will not be called if someone uses exit() (signal handler) or terminate() (some EH problem), causing many problems of resource leaks if the app object is the root of your object tree, as is often the case.

If the app object is a static variable in main, that solves the exit() problem, but you still need to set a global pointer to access it.

Making the app object a singleton, first called from main in a try block, avoids all of the above problems.

Re:Singleton (1)

Anonymous Coward | more than 2 years ago | (#40216259)

Go check out the Google TechTalks about testing on Youtube. It has this gem (paraphrasing): "You all think that global state is bad, right?" then a bit later "You all think that the Singleton pattern is just fine, right?" and then the amusing conclusion "you know that the Singleton pattern is global state, right?" The reason why having the Singleton pattern is bad is exactly because you can get a pointer to it from anywhere. That's the problem. You have no way to control side effects to fields that anyone can access from anywhere with no indication in the calling signature.

Your testers have to know about the global state that is being depended upon, and they have to set that up correctly, creating many possibilities for one test to impact the next one. If it's a dependency, it gets passed in to the constructor of the object. If you have too many constructor parameters then you have too many dependencies, it's just that making them explicit is making you aware of that instead of having it be a hidden gotcha' for everyone else dealing with that code.

Singletons are just a slightly better way of doing global state, but it's still global state. If you want cleanup in the face of exit(), you can make a global variable with no public interface that does your cleanup.

The singleton in reality (1)

SuperKendall (25149) | more than 2 years ago | (#40216857)

The reason why having the Singleton pattern is bad is exactly because you can get a pointer to it from anywhere. That's the problem. You have no way to control side effects to fields that anyone can access from anywhere with no indication in the calling signature.

Except that the dire warning has no teeth, because mostly singletons are used to access resources that generally are not changing during the life of the application.

People are told simply that singletons are bad, without considering there are a lot of uses for singletons that are not bad in that way at all.

Furthermore I challenge the notion that code elsewhere changing a singleton value is at all bad for testing - you simply need to model possible changes in the singleton and have whatever code is being tested react to that. Who cares if it's other code or the test harness changing values? It's all testing the code.

If singletons are not abused they can be a very helpful resource, and to if I had to choose between testing and singletons in terms of getting better code together, I'd choose singletons because of the flexibility they give you.

Re:Patterns over hyped? (0)

Anonymous Coward | more than 2 years ago | (#40213649)

The "Design Patterns" book is overrated and full of trivial patterns. For a truly excellent book of useful patterns check out "Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions". The whole book is online here: http://www.eaipatterns.com/

Re:Patterns over hyped? (0)

Anonymous Coward | more than 2 years ago | (#40215431)

I am a senior developer at a large publicly traded company. We have some pretty high volume systems, and I have yet to really use any other patterns besides MVC in my daily activities. I have also worked at several smaller consultant firms and never used them much before my current place. Maybe it's just because the type of problems I have been working on aren't complicated enough?

You've yet to recognise them you mean. I've yet to see a system that didn't use Singleton...and if you're using standard Frameworks I guarantee you're using Factory or Factory Method for things like database drivers, even if you are not actively building them.

The problem is that people throw KISS principle out the door and try to use a pattern to solve every problem, even problems that did not exist. For example Factories, Factory Methods, Proxies and Bridges are all about building a system that can cope with components being swapped out for a different implementation. Well that's great if your system has or is likely to develop that need. Otherwise it's a collassal waste of time and effort and bogs the system down needlessly.

Why do we bother numerical ratings? (2)

i kan reed (749298) | more than 2 years ago | (#40212395)

I can't remember the last book review that wasn't 9/10.

Re:Why do we bother numerical ratings? (0)

Anonymous Coward | more than 2 years ago | (#40212755)

I once got an A on a Elngish comp paper for fessing up to never having read the book I was to cover in the paper. To my credit the paper wasn't "TL;DR. The End."

What has been missing is critical thinking. (1)

Anonymous Coward | more than 2 years ago | (#40212417)

Having seen patterns applied out of pure habit or subscription to programming dogma, what has stuck out in my experience has been the lack of any meaningful discussion around why a particular pattern was appropriate for the task at hand. See: EJB. See: people attempting to Hibernate their entire database. See: loads of unnecessary abstract classes. Just like Acai berry isn't going to make you skinny without exercise and regulated food intake, neither is any prescriptive development methodology going to make your code better without the requisite attention to its applicability vis a vis the problem you are solving.

Re:What has been missing is critical thinking. (3, Insightful)

Anrego (830717) | more than 2 years ago | (#40212523)

I think you nailed it in the first sentence.

People have it in their heads that the crazier the class diagram, the easier the software will be to maintain. Obviously this isn't the case. Sometimes a design pattern can be used to provide useful abstraction or turn a complete hack into an elegant solution (or provide new and exciting hacks.. see: singleton) ,, but often it just adds extra classes that abstract things so core to the program that they will never change without a complete do-over .. or just adds useless layers of indirection that make it impossible for future maintainers to figure out what the hell anything does without using a debugger.

I think applicability comes down to justification. Can you justify the usage of this pattern? If not.. don't use it! Treat them as things to use when there is a reason, not things to just always use.

Re:What has been missing is critical thinking. (1)

Darinbob (1142669) | more than 2 years ago | (#40213403)

True, sometimes the silver bullet doesn't do the job. You have to break the rules, especially if the rules are just very loose guide lines. For instance, having software layers (ala OSI networking). Some people treat the division between layers as extremely important and inviolable; A calls B which calls C and finally D does the work, and A must never even know that D exists. But sometimes you can eliminate a large amount of code and speed things up by letting A query C or D directly.

A lot of problems arise by applying design rules at too fine a layer. When a project is huge having fine grained abstraction does not simplify the design. Split things into large chunks instead, and let each chunk be somewhat independent.

There's this holy grail of programming that it can be turned into a engineering discipline similar to hardware design. Or as I've heard someone put it, they wish they could design software the way people design bridges, with formulas and standardized parts and so forth. And design patterns are indeed used by some people as a sort of software parts catalog. Except that I think many of these people do not know what it is actually like to design hardware and bridges. Bridges often start with a very abstract design of what it should look like before the engineering part gets done, then there is an iteration that happens when the pragmatism conflicts with the idealism. In hardware I often see the same sorts of bugs and causes of bugs that you see in software; typos, over engineered parts, changing requirements, shortcuts, inadequate testing, etc.

Who cares of funny names? (1)

stanlyb (1839382) | more than 2 years ago | (#40212491)

Singleton: Some poor language are missing the plain old structures, and did not bother to implement them thread safe BY SPECIFICATION
Factory: God bless the reflection, and you, yes you man, that forgot to implement it in your little pity language, you go to hell
Builder: Really? What is next? Every time i write 3 lines of code i have to say that i used 3some pattern???
................

Re:Who cares of funny names? (1)

shmlco (594907) | more than 2 years ago | (#40213039)

"Singleton: Some poor language are missing the plain old structures, and did not bother to implement them thread safe BY SPECIFICATION"

Ah... no. Singletons are typically used as resource managers, like managing a pool of objects, or perhaps controlling access to a hardware resource, where you need to ensure that there's one instance and only one instance.

It's true that you're more likely to need them in languages that don't implement threads as part of the language syntax, but the flip side of that is that as a developer you're probably not going to be able to dictate your personal language preferences (biases) to every employer and on every project.

"Builder: Really? What is next? Every time i write 3 lines of code i have to say that i used 3some pattern???"

You don't have to say anything. Design Patterns simply pointed out that a lot of code tends to be organized into certain patterns, and having an idea of what those patterns are and their associated benefits and tradeoffs may help you write better code.

Or in your case, at least help you to write adequate code... (grin)

Re:Who cares of funny names? (1)

Anonymous Coward | more than 2 years ago | (#40213505)

3some pattern???

Your ideas are intriguing to me and I wish to subscribe to your newsletter.

Re:Who cares of funny names? (0)

Anonymous Coward | more than 2 years ago | (#40213705)

So your argument is that languages designed from the lessons learned from older languages are better than the (raw) older languages?

Re:Who cares of funny names? (1)

stanlyb (1839382) | more than 2 years ago | (#40214141)

Look at the pity C++. It does not even have a proper reflection implemented? For god sake, it does not even have PREBUILD libraries. Really, what the frack? Why should i have all the templates source code, and why should i have to compile it every time i instantiate one template only!!!
Callbacks? Thanks god the newest standard c++11 has lambda functions, AT LAST. but when i try to persuade my coworkers to use them, they look at my like alien (in its ET meaning) and keep using the stupid BOOST.
And no, my argument is that since the boom of the OOP some 15 years ago, a normal sane developer would expect more dynamic and more sane features implemented, instead, we are served with plain, old, gang of four. Let them burn in hell.

Design patterns were the worst thing to happen... (1)

Viol8 (599362) | more than 2 years ago | (#40212575)

Frankly if you hadn't thought up half of them yourself without being told about them then you don't have much talent as a coder but aside from that, all that bringing out a load of books about them did was give no talent coders a method of lego brick programming that usually gives rise to some half arsed semi working inefficient POS that someone who has a clue ends up having to spend months debugging and sorting out other issues. I know I'm coming across as an arrogant snob but since when did programming stop being a profession and start being a free for all for all liberal arts failures who can type a line of C# and suddenly think they're Turing?

Re:Design patterns were the worst thing to happen. (5, Insightful)

Anrego (830717) | more than 2 years ago | (#40212679)

Design patterns served the purpose of giving names to the things that as you said, most coders already came up with. When I say strategy, or observer, or behavior, or singleton .. everyone knows what the hell I'm talking about.

I know I'm coming across as an arrogant snob but since when did programming stop being a profession and start being a free for all for all liberal arts failures who can type a line of C# and suddenly think they're Turing?

When we did what we do with everything.. made it easier. It's the natural progression. People said "hey, this is hard.. if we did it this way, it'll be less hard". Rinse and repeat. There's still hard stuff out there, but it's not common _because_ the common stuff has been made easy. If you want to be challanged, get a job doing something weird that hasn't benefited years of people doing the same thing and improving the process.

Re:Design patterns were the worst thing to happen. (1)

Viol8 (599362) | more than 2 years ago | (#40212767)

"If you want to be challanged, get a job doing something weird that hasn't benefited years of people doing the same thing and improving the process."

Its not about me being challenged - I can do that with my own homebrew projects. What worries me is amateurs getting into coding positions and writing appalling code that probably ends up costing a lot more in the long run that if they'd hired people who had a clue. When Boeing or Airbus wants to build a new plane they don't hire some kid who's good folding paper aircraft, they hire proper engineers. I don't understand why IT should be treated so differently. Just because almost anyone can write a hello world program doesn't mean almost anyone should be allowed to work in programming.

Re:Design patterns were the worst thing to happen. (1)

Anrego (830717) | more than 2 years ago | (#40212927)

It's actually an interesting topic.. because while newer languages and toolstacks have lowered the bar.. they've also made the cost of failure lower.

You can be a complete knuckhead.. and write absolutely terrible code. But if your using java.. it'll still probably work and after a while of hacking out the bugs (with more ugly code) it'll attain a surprising stability.

More relevant is this thought that better code will translate into the dollars and cents everyone else seems so concerned with. Sometimes it does, sometimes it doesn't. We get cheap coders because analysis of the business case shows you save more from the cheapness of the coders than you lose from the crumbiness of the software. If it was the other way around, most businesses would knock it off and up their standards.

Good jobs where they care about the skillset and are willing to pay for it do exist in industries where bad software costs a metric fuck-tonne (industries like defense, aerospace, medical) but it's no longer the norm for stuff where it doesn't.

Re:Design patterns were the worst thing to happen. (3, Insightful)

stretch0611 (603238) | more than 2 years ago | (#40214001)

You can be a complete knuckhead.. and write absolutely terrible code. But if your using java.. it'll still probably work and after a while of hacking out the bugs (with more ugly code) it'll attain a surprising stability.

And with this crap code, people will spend twice the amount of time (or much more time) trying to maintain it or even trying to add a simple enhancement. In addition, the system will be such a piece of crap that it will be short listed for a complete rewrite. A system with well written code does not need a rewrite every 2-3 years... It can last. I have web-based systems that are 10 years now and still do not need a re-write. When a change is requested, it is easy to find the right place to make the modifications and when you go back into a certain block of code, it is easy to understand what the code is doing even if you have not looked at it in over a year. That saves money in the long run, not cheap coders.

We get cheap coders because analysis of the business case shows you save more from the cheapness of the coders than you lose from the crumbiness of the software.

Please tell me where you work so I NEVER apply there.

You get what you pay for, and slop code will always cost more in the long run. In addition, an expensive developer who truly understands what he is doing will code faster and with fewer errors. Depending on how bad of a hack job is done by your cheap coders it may even save money with the initial expense.

Back in 2002, I was outsourced/offshored. I was one of the first to go because I found a new job immediately and left instead of training my replacement. I spoke with my friends/colleagues that were left behind and the first assignment to the offshore company would have taken me 16 hours to complete. They billed a total of 120 hours for the same work. In addition it went all the way into production and failed miserably with a syntax error... They did not even test it!!!

Now the outsourcing company actually told us that money was the only reason why we were offshored. They said that the client rate was $90/hour for us and $60/hour for the offshore help. If you do the math, that meant the project cost was $7200 for the cheap coders, instead of $1440 for the expensive developer. Not to mention, I am sure some MBA is telling the executives that their cost saving plan saved the company $3600 on this change alone and that they deserve bonuses when really, they just lost $5760.

Now how do cheap coders save money?

Re:Design patterns were the worst thing to happen. (1)

Anrego (830717) | more than 2 years ago | (#40214167)

Please tell me where you work so I NEVER apply there.

For what it's worth I was talking in the general, not my specific case. As it happens I did exactly as I said in my first post after working for a standard issue software mill and getting frustrated by the constant cost cutting and fear of outsourcing. Got into a specialized field where mistakes are expensive and high quality code is worth the price. Experienced coders, formal testing, people who can define the difference between system and software architecture, etc. I'd seriously recommend this to anyone getting fed up of being told "it works, ship it!".

 

Now how do cheap coders save money?

I don't pretend to understand how it works, I just have faith that things happen for a reason. Business guy's arn't _that_ stupid (they are generally making money after all). Obviously there are going to be cases where it doesn't work for whatever reason, but I have to assume that since the practice is becoming more universal, it has to have merit. Either way I've washed my hands of the mess.

Re:Design patterns were the worst thing to happen. (1)

shmlco (594907) | more than 2 years ago | (#40213127)

"When Boeing or Airbus wants to build a new plane they don't hire some kid who's good folding paper aircraft, they hire proper engineers."

When I need to have the brakes fixed on my car, an aerospace engineer would be overkill.

For adding a few customization features and pages to a WordPress installation, a PHP guy with a year or so's worth of experience is probably all most people need. Or can afford, for that matter.

Re:Design patterns were the worst thing to happen. (1)

DragonWriter (970822) | more than 2 years ago | (#40213645)

What worries me is amateurs getting into coding positions and writing appalling code that probably ends up costing a lot more in the long run that if they'd hired people who had a clue.

The problem, of course, is that lots of people who are hiring programmers also don't have a good ability to detect the ones that have are really skilled -- spending the money that it would cost to get someone that has a clue would often mean they were still getting not-so-good programmers writing needlessly-expensive-to-maintain code, but paying top dollar for it.

When Boeing or Airbus wants to build a new plane they don't hire some kid who's good folding paper aircraft, they hire proper engineers. I don't understand why IT should be treated so differently.

Because most IT work doesn't involve the level of risk associated with garden variety moderate deficiencies in competence that aircraft engineering does. (The IT work that does have that level of criticality often has substantially higher standards, and skilled people applying the standards.)

Re:Design patterns were the worst thing to happen. (1)

chthon (580889) | more than 2 years ago | (#40217557)

+5 Insightful

The barrier to entry in programming is very low, but that does not mean that programming is simple and/or easy.

Re:Design patterns were the worst thing to happen. (0)

Anonymous Coward | more than 2 years ago | (#40212803)

It was stated already but it really has to be reinforced, "patterns" are names or common practises in modern programming, a common parlance.

I don't have to show you what a factory pattern is, you either know it or you can look it up.

Whether or not "pattern use" is effective is solely on the shoulders of the programmers that employ them.

Re:Design patterns were the worst thing to happen. (1)

plopez (54068) | more than 2 years ago | (#40213019)

"I know I'm coming across as an arrogant snob but since when did programming stop being a profession and start being a free for all for all liberal arts failures who can type a line of C# and suddenly think they're Turing?"

I was in the business for a long time and it has been going on since time imemorable. Which is one reason I quit, we seem to never learn. And just as bad after 15 or so years in the business when you have learned your are considered to old and get thrown away. One of the other reasons I quit.

Re:Design patterns were the worst thing to happen. (0)

Anonymous Coward | more than 2 years ago | (#40213113)

Come over to the hardware side. People are a lot more thorough when it costs several million dollars and three months to run the compiler.

Re:Design patterns were the worst thing to happen. (1)

Darinbob (1142669) | more than 2 years ago | (#40213437)

The goal is to end up with a POS that has a detailed design, so that when it fails you point to the pile of design docs and say "see, we did all the necessary work, everything's been coded to the design, you'll have to blame someone else". They provide absolution.

Re:Design patterns were the worst thing to happen. (1)

chthon (580889) | more than 2 years ago | (#40217575)

+1 Cynical

The biggest problem with design patterns... (1)

mark-t (151149) | more than 2 years ago | (#40212593)

... is that they do not scale very well to software that is supposed to be on the cutting edge of what is technologically possible today. When all you think about is in terms of named patterns, then there's a pretty good chance that you're just reinventing stuff that other people have done. Perhaps you are doing it faster, or on a newer platform, but in the end, it's still just reinvention. Real pioneering comes from thinking outside of the box, where nobody else has ever tried exploring before. If all you can do is think in terms of the named patterns that other people have already thought of, then I think that's generally only going to hold you back.

Re:The biggest problem with design patterns... (3, Insightful)

Anrego (830717) | more than 2 years ago | (#40212735)

On the other hand, if you spend all your time re-solving things which have already been solved.. you aren’t going anywhere fast either.

Ultimately design patterns already existed. Most of the commonly used ones are intuitive enough that most programmers arrived at them on their own. The main purpose served was creating a common vocabulary.

Re:The biggest problem with design patterns... (1)

mark-t (151149) | more than 2 years ago | (#40213307)

Well I don't ever pretend to say that being imaginative should *ever* be a substitute for at least being aware of what else is going on around you, or knowing what other have done before. It goes without saying that any good programmer should be very well read. My only concern is that design patterns tend to put programmers, especially newer ones, into boxes that they will have a very hard time learning how to think outside of. They've learned all these terms that have been ingrained into them right from year one in computer science, and all to often, particularly with younger programmers, you see people applying named patterns to some problems for the sake of the pattern itself, rather than because it was really the best way to solve a particular problem. Design patterns, at least to me, come across as a means to sound impressive when discussing your software... like you know all the technical buzzwords, but in the end, they don't actually help you understand how to solve any real problems that programmers have to face.

Re:The biggest problem with design patterns... (0)

Anonymous Coward | more than 2 years ago | (#40214821)

common vocabulary? oh please. that's like agreeing on...

tabs vs spaces, do "blank lines" contain a semicolon
to polish or not to polish, prepending s or _ to local / static variables, m for member variables
mixed case variable names or word separated with _

all said a waste of time.

Re:The biggest problem with design patterns... (1)

O('_')O_Bush (1162487) | more than 2 years ago | (#40212815)

On the other hand, it is really hard to be cutting edge and innovative when you spend almost all of your time and resources reinventing and maintaining your own versions of the wheel. Design patterns have important uses no matter the area of software, but it takes wisdom to tell the difference when a DP makes sense and when it doesn't.

Re:The biggest problem with design patterns... (2)

shmlco (594907) | more than 2 years ago | (#40213255)

"Real pioneering comes from thinking outside of the box, where nobody else has ever tried exploring before. If all you can do is think in terms of the named patterns that other people have already thought of, then I think that's generally only going to hold you back."

Ummm... this smacks of a distain for formal education, which I typically find in people who lack formal education and training.

Regardless, patterns are simply tools in the box. They're not the ONLY tools in the box.

Re:The biggest problem with design patterns... (1)

mark-t (151149) | more than 2 years ago | (#40213601)

I have no disdain at all for a formal education. But, particularly in computer science, the important thing to take from such an education is learning how to learn... because practically everything concrete that you learned in school will be obsolete before you graduate. Of course you need to learn what other people have done before you so that you don't reinvent the wheel. For what it's worth, I ended up learning about design patterns for one course I took in my last year just before I graduated. They seemed to make a whole lot of sense at the time, but it it took me some number of years after that, and in the real world of corporate software development, before I realized the problems that they bring with them

Regardless, patterns are simply tools in the box. They're not the ONLY tools in the box.

I can sort of agree with where you're coming from with this. My experience with younger programmers has often been that they are very eager to point out how they have used such-and-such a design pattern to approach a particular goal, and while that might sound impressive, it leaves one wondering if they had spent as much time thinking about the best way to accomplish the goal as they did finding a way to squeeze the problem into one particular design pattern.

I am reminded of when I recently had the misfortune of working on a project with another younger programmer who seemed extremely eager to apply design patterns to every stage of the development process, all too often without regard for whether it was the best way to solve a particular problem. I hold him no ill-will in all of this, of course... he was eager, energetic, and very well meaning. But it just seemed that sometimes he was using particular design patterns just for their own sake.

This experience, unfortunately, is far from unique. Maybe you're right about design patterns being practical... but it strikes me that there's something wrong with how they are being taught to people these days...and I find that teaching them tends to make too many programmers think alike, reducing the variety of creativity that will spring forth from a programming team.

Re:The biggest problem with design patterns... (1)

shmlco (594907) | more than 2 years ago | (#40213897)

Young and inexperienced programmers often suffer from the "when the only tool you have is a hammer..." mentality. This could be design patterns, or their insistence on using a single language for everything, or for always using a particular platform or framework.

Regardless, patterns are interesting in that they're largely platform and language agnostic. They're just ways of thinking about a problem, and the true test of using them is knowing when they fit a given situation... and when they don't. Knowing the benefits and the tradeoffs.

Which comes from experience.

Re:The biggest problem with design patterns... (1)

ratboy666 (104074) | more than 2 years ago | (#40213751)

The biggest problem with design patterns is that they codify repeated constructs.

And, since we are teaching developers that repeating these constructs by rote is "the right thing to do", there is less call to actually push the problem to where it belongs...

The language implementation itself.

If you keep repeating "Factory", "Observer" (whatever), then why wouldn't you want something that can actually represent the concept?

Reducing the concepts into a (hopefully) smaller set should make this more directly implementable. Or, at least provide the building blocks to permit direct Pattern implementation is a library sense. (although, I have not read the book, nor the thesis, just going by the summary here).

But, I agree with you. Cutting edge development must take place in uncharted areas, and the use of patterns is "known space". It should be really known space, though, in that the Patterns must be subsumed (like subroutines and I/O libraries). Stressing about Patterns all the time will be... (or should be) wasteful.

Peter Norvig wrote an interesting article about this:

http://www.norvig.com/design-patterns/ [norvig.com]

(http://norvig.com/bio.html)

In the article, he shows how 16 of 24 GoF patterns simply disappear, or become considerably less relevant by proper language support.

However, if the programming community at large insists on weaker languages, we may need to take smaller steps, and the book being reviewed may be a useful step in that direction.

Re:The biggest problem with design patterns... (2)

Jason Smith (3310) | more than 2 years ago | (#40214689)

I completely agree. In fact, in the book I show where some languages, such as C#, have started implementing some of these EDPs as basic primitives. I also show how these ideas are implemented in a number of languages (Java, C++, C#, Obj-C, Python, even straight C in a couple of cases) to demonstrate how the language feature set can radically change how you choose to implement a concept.

Ultimately, that's what design patterns are: concepts. How they get implemented is unique to a language, a problem domain, and a set of constraints and requirements you're working with.

Change the language expressibility, and you change how you can approach the concepts.

Re:The biggest problem with design patterns... (2)

Jason Smith (3310) | more than 2 years ago | (#40214847)

*Absolutely*. To me, one of the biggest wins of design patterns is that they let me quickly solve, describe, or *avoid* problems that others have solved, described, and found ways around.

In fact, the material for the book came from my research in creating a system for the automated detection of design patterns in source code. It was originally intended to find the patterns to help document the system, but it quickly became obvious that the biggest benefit was that it defined the sections of the system that *didn't* need documentation. Other people had already done so. Instead, it let the developers concentrate on the portions of their code that were unique to their implementation. i.e., their innovation.

I find patterns to be incredibly useful, obviously, but they are often most useful not for what they define, but what they *don't*. The negative space of the system, once it is seen as a system of patterns, is where the real fun starts.

Re:The biggest problem with design patterns... (1)

not-my-real-name (193518) | more than 2 years ago | (#40215667)

How can you think outside of the box when you don't know where the box is?

Re:The biggest problem with design patterns... (1)

mark-t (151149) | more than 2 years ago | (#40216589)

You don't need to know where the box is to think outside of it. In fact, the less you know about the box, the easier it *IS* to think outside of it.

But don't misinterpret that as any sort of indicator that I don't value a conventional education. It's important to learn what other people have done in the field so that you don't unessarily reinvent the wheel.

My experience with people who have been "raised up" using design patterns is that they mostly tend to think very similarly in how they would approach a given problem. While this might seem to be helpful in terms of everybody on a programming team working in a consistent style, the problem I've found is that the lack of diversity tends to, more often than not, lead to suboptimal solutions, because different ideas aren't considered and weighed out.

patterns and idiots (0)

Anonymous Coward | more than 2 years ago | (#40212783)

From my experience familiarity of DP usually ends at singleton and factory. Idiots absolutely insist on writing as many as possible. More advanced idiots include command to the list and insist on replacing function calls with them.

Re:patterns and idiots (0)

Anonymous Coward | more than 2 years ago | (#40212905)

If I see anyone use the goddamn singleton (simpleton?) pattern again I'm gonna go ballistic. I just got done refaptoring a project where damn near every class was a simpleton. I don't understand why the pattern exists at all. It's exactly like having a global object, except it gets allocated at some random-ass point in the runtime and it lives on the heap instead of the static block (because the heap never gets corrupted or anything when you're trying to debug a crash, oh no sir!).

Look, if you want to use a global object, if it's really necessary, hey go for it. Don't "singleton".

In defense of Patterns (1)

DrEasy (559739) | more than 2 years ago | (#40212869)

Yes, patterns often are needed due to the inflexibility of your programming language of choice (erm, Java), and yes, when you first learn about them you tend to use them everywhere and over-engineer things to death (guilty!). BUT, with some experience you realize that it's the idea behind them that is important. Especially if you're using some agile methodology, you basically only end up with patterns or a piece thereof as a result of some refactoring (see Joshua Kerievsky's excellent book on the subject), and you should also be ready to move away from them as soon as you realize you don't need them. Patterns provide a direction, but they're not necessarily an end goal.

I haven't read this new book, but breaking down patterns into smaller, more fundamental chunks could be very useful in that "refactoring toward patterns" attitude.

Re:In defense of Patterns (2)

DragonWriter (970822) | more than 2 years ago | (#40213569)

Yes, patterns often are needed due to the inflexibility of your programming language of choice

Patterns, qua patterns, are only needed due to inflexibility of the programming language. With a sufficiently-flexible programming language, any given "pattern" is instead a piece of library code that needs written once, rather than a template that needs to be reimplemented each time it is used.

Of course, real programming languages aren't perfectly flexible, so any real programming language is going to have patterns that are useful -- but which patterns is going to vary based on the limitations of the particularl language.

Them templates in languages with no reader macros (0)

Anonymous Coward | more than 2 years ago | (#40212955)

The main issue with most "design patterns" is that they are exactly that: templates.

Yet they're needed, and that's the real sad thing: "good" projects do use them and there's a lot of incredibly repetitive code made of decorators, abstract factories, "fluent interfaces" (not really a "design pattern" but the issue is the same).

And that's because C# / C++ / Java are "the industry norm" or whatever. Nobody wants to use parentheses:

(decorate (wrap-subject) xxx)

That's too hard. There are parentheses you see: people prefer to write the same templates all over C# / C++ / Java code.

Design patterns are one thing: workarounds for C# / C++ / Java / Objective-C defects.

When you program in a Lisp dialect, like, say, Clojure (to name one Lisp dialect who's gaining a lot of traction lately) you can burn 400 of the 600 pages of the original GoF book.

Back in the days, when I read the GoF I thought it was cool, amazing, etc.

Now I' beginning to think there may be other ways because "templates" leading to extreme repetition all over a codebase --and, worse, realizing that this is actually the "less worse" you can do in such languages-- may not be the only way...

Interesting theory, but is it practical (1)

ndykman (659315) | more than 2 years ago | (#40213025)

The underlying concept isn't as hard as the review makes it sound. Using some formalisms, the author creates a set of blocks upon which you can build patterns like those in the Gang of Four book. By doing so, you can see what commonalities occur and hopefully, this leads to deeper insight into what patterns really are.

The review mentions some detection of patterns in "legacy code" but the idea of refactoring the code to better support those concepts that is mentioned in the review seems too vague to me.

There was a good book on how you could use refactoring to implement design patterns in existing code, but it wasn't as grounded on theory and automation as refactoring itself. The theory mentioned is this work could maybe serve as a foundation for such an idea.

If this sparks a new set of tools that help automate the redesign of code to follow better practices, that'd be really great. But, I think there is still some real work left to be done before that happens. And while it remains to be seen, the formalism applied could reap great benefits in that regard.

Re:Interesting theory, but is it practical (2)

Jason Smith (3310) | more than 2 years ago | (#40214873)

Do you by any chance mean Kerievsky's _Refactoring to Patterns_? Have a well-work copy on my desk, and between that and Fowler's _Refactoring_, I see a fairly clear path from the EDPs to patterns-based refactoring.

It was one of the use cases, after all. :)

Show me on increase in ROI due to "Patterns" (0)

Anonymous Coward | more than 2 years ago | (#40213259)

Just one. Verifiable from a third disinterested party.

On the other hand, I can think of at least one case where patterns thoroughly fucked up what might otherwise have been a useful thing (i.e. Microsoft's UI Automation). The dimwitted, heavy-handed attempt at jamming otherwise perfectly understandable user interface categories into "patterns" is painful to read and far more difficult to program than it needs to be. I don't need "patterns" to click an OK button. I need an interface path [my.exe].dialog.tab.controlobject (e.g. objButton) and a method ("Click"). That's all. That's useful. I don't need "SelectionPattern" or "InvokePattern" or any other productivity sapping nonsense imposed by a business-impaired, 20-something with a brainwave. Wrapping that crap into useful, understandably named member functions is the first thing you have to do to make UI Automation even vaguely useful.

Patterns (0)

Anonymous Coward | more than 2 years ago | (#40213293)

SO glad to read that others have tired of pattern-overload (along with the associated overarchitecture). I have worked for multiple architects who include facades just for the sake of "fulfilling the pattern" and others whose first order of business is to write a bunch of object factories (uhh, the runtime is usually best for this, since object creation is a core feature) and more facades (even to entity objects!). (then there is the other flavor of architect who sees him/herself as some kind of integrator, piecing together frameworks for every conceivable function and saying it's an application architecture)
Patterns manifest themselves when you write well-designed code; using patterns is not what makes the code good per se.

What we need... (3, Interesting)

jholyhead (2505574) | more than 2 years ago | (#40213559)

...is a book that assumes you know all of the GoF patterns and gives a list of times when you shouldn't use each one.

Most people's beef with design patterns is that inexperienced coders sit down and think 'what pattern could I apply to this problem?' or 'how can I change my problem to fit a pattern?' instead of 'what pattern, if any would make this code easier to understand and maintain in the long term?'.

Re:What we need... (1)

AnnoyingCow (2654755) | more than 2 years ago | (#40214073)

...is a book that assumes you know all of the GoF patterns and gives a list of times when you shouldn't use each one.

That is so true. I think what might help in the original GOF book is to put more emphasis on the "Applicability" and "Consequences" sections in each pattern. Afterall, patterns are just a bunch of trade-offs in design (e.g. the Visitor pattern makes adding new operations easy, but it makes adding new ConcreteElement classes hard), and the trade-offs need to make sense in the problem context for the pattern to be beneficial.

Something I keep reminding myself is that "complexity is not free", and meanwhile keep trying to understand the true essence of each problem in order to correctly apply the correct balance of "simple design".

Re:What we need... (2)

Jason Smith (3310) | more than 2 years ago | (#40214961)

God yes. One of the early examples I saw of this was a Hello World that ran to a couple thousand lines of code, using every conceivable design pattern at once. It was horrendous.

Engineering is trade-offs, in almost every case. Adding an abstraction to encapsulate a bit of complexity doesn't dodge the fact that under that abstraction you are *adding complexity*. Sometimes the complexity is necessary, and sometimes it is a kludge. Knowing the difference requires understanding what the various underlying concepts you are adding actually mean, how they interact, and what they cost you in terms of implementation or design flexibility given your implementation language, constraints, etc.

The EDPs are a way of conveying that information about the underpinnings of the current design patterns literature, so that the huge amount of information at our fingertips gets new utility... and hopefully so rising programmers can have a smoother introduction to the literature than we did.

Re:What we need... (0)

Anonymous Coward | more than 2 years ago | (#40214885)

It exists! It's called AntiPatterns [amazon.com]

Thats what I have been waiting for. (1)

StillNeedMoreCoffee (123989) | more than 2 years ago | (#40214249)

Given a design language, the next step is to design a design pattern optimizing compiler, using a set of transforms to reduce canonical forms to optimized merged patterns.

Re:Thats what I have been waiting for. (1)

Jason Smith (3310) | more than 2 years ago | (#40214921)

I see that as one very useful direction, absolutely. Frankly, this isn't that different than what we do now, in turning a set of concepts of programming (such as data types, functions, and so on) into bits.

The EDPs form a bridge between the higher-level abstractions of the existing design patterns literature, and language constructs. From there, it's turtles all the way down. :)

Fuck Patterns (1)

Azure Flash (2440904) | more than 2 years ago | (#40214807)

When I was studying in computer programming, there was a whole course about just UML and patterns (it was called Software Analysis I think). The whole subject was extremely efficient at inducing analysis paralysis, it was boring as hell, the software we used to draw UML diagrams was shit, and it almost killed my ability to code. My advice (as a very non-professional coder, but a knowledgeable enthusiast nonetheless - take this for what it's worth) is to just stick to well-defined use cases, good documentation and tests if you're in a big project. Fuck patterns.

Re:Fuck Patterns (1)

jholyhead (2505574) | more than 2 years ago | (#40216799)

Fine if you're doing Mickey Mouse projects, but if you have to maintain a code base with a few hundred thousand LoC, you'll be glad to see code structures you recognise.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>