Forgot your password?
typodupeerror
Software Books Book Reviews Technology

Book Review: Elemental Design Patterns 129

Posted by samzenpus
from the read-all-about-it dept.
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.
Elemental Design Patterns
author Jason McC. Smith
pages 368
publisher Addison-Wesley Professional
rating 9/10
reviewer Joe Kauzlarich
ISBN 978-0321711922
summary Software Design
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.

*

This discussion has been archived. No new comments can be posted.

Book Review: Elemental Design Patterns

Comments Filter:
  • That was painful (Score:5, Insightful)

    by Anonymous Coward on Monday June 04, 2012 @03:26PM (#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.

    • by Gr8Apes (679165)
      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
    • Re:That was painful (Score:5, Informative)

      by Eponymous Hero (2090636) on Monday June 04, 2012 @04:04PM (#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]
    • by greg1104 (461138)

      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.

    • by jkauzlar (596349)

      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

      • by Anrego (830717) *

        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

        • by jkauzlar (596349)
          Thanks, I understand what you mean and it makes sense. This was a different sort of book than I usually review here, so I wasn't sure how to approach it, especially since it's hard to easily summarize what exactly the author's intentions are. Thanks again for the constructive criticism.
  • by darjen (879890) on Monday June 04, 2012 @03:26PM (#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: (Score:2, Insightful)

      by Anonymous Coward

      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: (Score:2, Insightful)

        by stanlyb (1839382)
        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".
      • 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 lang

    • by Anrego (830717) *

      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.

      • by vux984 (928602)

        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.

    • 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".

      • 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?
        • by plopez (54068)

          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.

        • by Anonymous Coward

          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

          • by Jason Smith (3310)

            "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

            • by Mr Z (6791)

              Sometimes, it just takes a more approachable book with a shallower ramp to get your boat off the shore and sailing. I found the GoF book thicker than paste and more effective than a bottle of sleeping pills at putting me out for the night. A senior developer at my company then pointed me to some other books, such as Head First Design Patterns. It may've been a little on the goofy side, but it did present (most of) the patterns in a clear and motivated way.

              Once I read through that book and largely "got i

        • by Darinbob (1142669)

          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.

          No

          • 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.
            • Everything you do half hearted or by following a hype is useless. However by dismissing it as useless you will never get the experience to understand it and to finally exploit its usefulness!
              People who find SCRUM useless don't understand it and use it wrong. After that gets pointed out they claim: the only awnser SCRUM fanboys have is: you use it wrong.
              Well, frankly if you can not do SCRUM or have no benefit from doing it you are on CMM level 1. Perhaps you schould learn how to do software in a team first.
              T

              • SCRUM is extremely useful if followed correctly, and I would not dismiss a fully functional SCRUM team's effectiveness. However, I've seen SCRUM used as a crutch by a dysfunctional management team that was using the hype of SCRUM and the effectiveness of SCRUM as an excuse to blame the coders when the project wasn't doing well (because of poor direction).

                Design patterns seem similar to SCRUM in that, when used correctly and effectively (as an algorithm reference, not coding with strict adherence to specifi

                • Well, frankly, I never saw a discussion about design patterns at all. People just use them, thats it. Sometimes one acquires a habit, and I find that interesting and encourage him to introduce his way to the team, so we have a new "local pattern". However this discussion that is often going towards: everything is hype, just code C and you are fine makes me ... hm, surprised, unwell?

      • 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 th

    • by Darinbob (1142669)

      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 irrat

      • by Nerdfest (867930) on Monday June 04, 2012 @04:33PM (#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'.

    • by GreatBunzinni (642500) on Monday June 04, 2012 @04:40PM (#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

      • by olau (314197)

        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.

        This is nice and all - but I find in practice that people who are all gung-ho on patterns spend most of the time up in a sky where what they say is correct, but not terribly relevant to getting things done. To use your example, if you talk about an observer pattern rather than describing the mechanism, you are providing much less information about what you're doing.

        The principles themselves, as a sort of distilled experience, are important, no doubt about that.

        • This is nice and all - but I find in practice that people who are all gung-ho on patterns spend most of the time up in a sky where what they say is correct, but not terribly relevant to getting things done. To use your example, if you talk about an observer pattern rather than describing the mechanism, you are providing much less information about what you're doing.

          Any reference to a specific design pattern is nothing more than a reference to very concise but detailed description of the mechanism. An adequ

    • Singleton (Score:4, Informative)

      by Chemisor (97276) on Monday June 04, 2012 @04:49PM (#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.

    • Depending on the type of work you are doing, it might be that the majority of your architecture is already in place (e.g., web frameworks like Rails). It could also be (as someone else implied) that the patterns are there and you aren't recognizing them. I hope you don't mind, but I checked your profile and it said "java web dev". You're not going to escape using Java for just about anything without using design patterns. You may not be implementing them, but the libraries you are using make use of them ext

  • by i kan reed (749298) on Monday June 04, 2012 @03:29PM (#40212395) Homepage Journal

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

  • 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

    • by Anrego (830717) * on Monday June 04, 2012 @03:39PM (#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.

      • by Darinbob (1142669)

        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 a

        • I call this the "onion architecture" and it is a mortal enemy of DRP (don't repeat yourself). It is generally sold as though it were an implementation of the SRP (Single Responsibility Principle). It isn't. The whole point of *both* principles is to help manage complexity, cohesion, and coupling. If they come into conflict, I choose the simpler. Most people in my experience don't though; they simply go to one extreme or the other - 10 classes to do the work of one, or one to do the work of 10.
        • by gweihir (88907)

          There is no silver bullet. There never will be one.

          If you disagree, go read "The mythical man-month". Required reading for anybody that does software, IMO.

      • by lwriemen (763666)

        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.

        I'm not quite sure what you mean by "crazier", but you later seem to equate it to more classes later.

        The more complete the class diagram, the easier the software is to maintain. This statement requires a qualifier: Good separation of concerns must be done before class modeling begins. i.e., subject matters must be divided into independent entities, which are then individually modeled.

        "Complete" means all the information possible (about the subject matter being modeled) is exposed by the class model. If this

    • by gweihir (88907)

      Indeed. Actually understanding the problem and its implications cannot be replaced by anything. There are these managers that think programmers can be replaced by cheap drones that just follow a process. That can and will never work until we have strong AI (and then we might have the problem of how to motivate the AI to work for us....). Just look at more classical engineering, where they often _can_ make the whole thing out of standardized and well known components. Nope, still needs a human being with act

  • 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???
    ................
    • by shmlco (594907)

      "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

    • by Anonymous Coward

      3some pattern???

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

  • 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 st

    • by Anrego (830717) * on Monday June 04, 2012 @03:51PM (#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.

      • by Viol8 (599362)

        "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 pap

        • by Anrego (830717) *

          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 d

          • by stretch0611 (603238) on Monday June 04, 2012 @05:52PM (#40214001) Journal

            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?

            • by Anrego (830717) *

              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

        • by shmlco (594907)

          "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.

        • 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-main

        • by chthon (580889)

          +5 Insightful

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

      • by alexo (9335)

        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.

        When I was young(er), we had just one name for almost all of the design patterns: "another level of indirection".

    • by plopez (54068)

      "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 q

    • by Darinbob (1142669)

      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.

  • ... 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
    • by Anrego (830717) * on Monday June 04, 2012 @03:56PM (#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.

      • by mark-t (151149)
        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 fro
    • 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.
    • by shmlco (594907)

      "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.

      • by mark-t (151149)

        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. Th

        • by shmlco (594907)

          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 th

    • by ratboy666 (104074)

      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 imp

      • by Jason Smith (3310)

        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 domai

    • by Jason Smith (3310)

      *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 tha

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

      • by mark-t (151149)

        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 appro

        • 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.

          This is so wrong it hurts.

  • 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),

    • 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 pattern

  • 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.

    Ther

    • by Jason Smith (3310)

      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. :)

  • What we need... (Score:4, Interesting)

    by jholyhead (2505574) on Monday June 04, 2012 @05:02PM (#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?'.
  • 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.

    • by Jason Smith (3310)

      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. :)

  • Take a look at the coding style standards for C++ at Google. They contradict much typical practice in the C++ world, http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml [googlecode.com]

    Classes Classes are the fundamental unit of code in C++. Naturally, we use them extensively. This section lists the main dos and don'ts you should follow when writing a class.

    Doing Work in Constructors In general, constructors should merely set member variables to their initial values. Any complex initialization should go in a

    • Well, having an explicit "init()" method means they don't understand what the constructor is ment for. Lazy as I am, the first thing I would do is: writing a factory method that uses the constructor and calls init().
      MI ... well, perhaps google for taligent and the frameworks they built.
      Fact is, most people (especially those defining rules like the ones above) don't know how to use MI efficiently, so they abolish it.
      Abolishing a certain set of features (or restricting their usage) of your programming languag

  • The biggest problem with the pattern movement is that little attempt has been made to document both the upsides AND the downsides of each and to compare and contrast in practical terms, especially from the view of likely future changes. Designing technology is largely about managing and weighing tradeoffs.

    If you cannot explain clearly why you picked pattern/technique A over pattern/technique B or C etc., then you probably don't know what the hell you are doing. "I did it because it looked so cool in the boo

It is much easier to suggest solutions when you know nothing about the problem.

Working...