Book Review: Elemental Design Patterns 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?
| 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 |
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.
That was painful (Score:5, Insightful)
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: (Score:2)
Re:That was painful (Score:5, Informative)
Re: (Score:2)
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: (Score:3)
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
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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: (Score:3)
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 y
Patterns over hyped? (Score:5, Insightful)
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)
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)
Re: (Score:2)
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
Re: (Score:1)
Re: (Score:3)
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: (Score:2)
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 stuf
Re: (Score:2)
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: (Score:2)
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? (Score:5, Insightful)
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: (Score:2)
Re: (Score:2)
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: (Score:1)
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
Re: (Score:3)
"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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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?
That is why I wonder if patterns are useful (Score:2)
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
Re: (Score:2)
God damn but I wish I had mod points for you right now. My sentiments exactly.
Re: (Score:2)
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
Re:Patterns over hyped? (Score:5, Insightful)
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? (Score:4, Informative)
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
Re: (Score:2)
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.
Re: (Score:2)
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)
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.
The singleton in reality (Score:2)
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
Re: (Score:2)
Singletons don't give you flexibility. They lock you in. You can not make a derived class from them, you can not instanciate more than one object from them. You need a global access method to use them (or do you do the mistake and use the global variable directly? If so you can not even change the instance 'behind the scene' because references to the old instane might linger around) ...
Sooner or later you will have singletons refering to other sinletons and in my eyes this will become a great mess.
Re: (Score:2)
In decades of software development this has simply not been a problem. A singleton is something you do not inherently NEED to subclass, or have more instances of - because having one instance is the whole point!
Generally I've not had much cross-talk between singletons, because they end up being edge nodes representing resources used across an application by the many class instances that make up an application.
Yes, I always use a global access method to get the instance... yet another reason they are no dan
Re: (Score:2)
My point is that you only make singleton when want that there is only one single instance. In other words: having more than one would cause harm. If having more than one is not causing any harm, having a singleton is wrong.
Regarding subclassing: the question is not if you need to, the question is if you want to. Having two very similar applications but being forced to duplicate code because the older one uses this particular code via a singleton seems pretty stupid.
Re: (Score:2)
Nearly every program uses a singleton whether they realize it or not: the heap, or global store, or whatever you want to call the well that 'new' and 'malloc' dip their metaphorical buckets in.
I use singletons in applications where I have either a static resource pool that I need to manage, or the application itself is statically allocated. Now, I don't use singletons much or at all on "workstation" applications.
Where I use them mostly is in embedded environments where the specific configuration of the sy
Re: (Score:2)
But, in the common situations that most people will encounter, the singleton isn't very common at all.
That is not true at all. In every language I have worked in, I have had cause to have something like a singleton at times.
In my most recent work as an iOS developer the system itself has a number of singletons core to applications - the application object itself is a singleton, as are a number of other resource management classes like the class to save default values, or a class to get information about th
Re: (Score:2)
I should have phrased that differently. After all, I started off my comment with: "Nearly every program uses a singleton whether they realize it or not". And, the examples you cite are great examples.
What I was really trying to get at was that unless you're writing the low level resource managers yourself (as I was), it's uncommon to need to write new classes that are explicitly singleton (along with all the trappings of adding multiple-creation avoidance, etc.). Central resource managers and the top-lev
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
What if your container needs to return things to you in some particular order, like LIFO, FIFO, static priority-order, or the like? For those, the most efficient structures are usually stacks, queues, and heaps, respectively. Hashes make decent associative arrays, and if your total number of keys is relatively stable, then can perform better than RB trees, AVL trees and the like.
Hashes are no silver bullet: Hash keys take time to compute. You can get lumpy performance if your key space varies dramaticall
Re: (Score:3)
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
Why do we bother numerical ratings? (Score:3)
I can't remember the last book review that wasn't 9/10.
Re: (Score:2)
To be fair, 3 weeks is a long time.
What has been missing is critical thinking. (Score:1)
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
Re:What has been missing is critical thinking. (Score:4, Insightful)
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: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Who cares of funny names? (Score:2)
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: (Score:2)
"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
Re: (Score:1)
3some pattern???
Your ideas are intriguing to me and I wish to subscribe to your newsletter.
Re: (Score:2)
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
Design patterns were the worst thing to happen... (Score:2)
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
Re:Design patterns were the worst thing to happen. (Score:5, Insightful)
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: (Score:2)
"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
Re: (Score:2)
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
Re:Design patterns were the worst thing to happen. (Score:4, Insightful)
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: (Score:2)
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
Re: (Score:2)
"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: (Score:2)
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
Re: (Score:2)
+5 Insightful
The barrier to entry in programming is very low, but that does not mean that programming is simple and/or easy.
Re: (Score:2)
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".
Re: (Score:2)
"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
Re: (Score:2)
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: (Score:2)
+1 Cynical
Re: (Score:2)
"In my experience (from somebody who was a Liberal Arts major before I studied programming); it is far easier for a Liberal Arts major to learn computer programming than it is for a computer programmer to acquire critical thinking skills."
LOL! :o)
Ah , I do like trolls. LIberal arts doesn't involve thinking - ie problem solving - its just memory. A parrot could do it.
The biggest problem with design patterns... (Score:2)
Re:The biggest problem with design patterns... (Score:4, Insightful)
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: (Score:2)
Re: (Score:2)
Re: (Score:3)
"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: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:3)
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
Re: (Score:3)
*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
Re: (Score:2)
How can you think outside of the box when you don't know where the box is?
Re: (Score:2)
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
Re: (Score:2)
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.
In defense of Patterns (Score:2)
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),
Re: (Score:3)
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
Interesting theory, but is it practical (Score:2)
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
Re: (Score:3)
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)
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: (Score:3)
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
Thats what I have been waiting for. (Score:2)
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: (Score:2)
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. :)
Google's C++ coding standards (Score:2)
Re: (Score:2)
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(). ... well, perhaps google for taligent and the frameworks they built.
MI
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
Know why, and know why not (Score:2)
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
Re: (Score:2)