Slashdot Mirror
Book Review: Elemental Design Patterns
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.
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 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.
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 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 make your code better without the requisite attention to its applicability vis a vis the problem you are solving.
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???
Frankly if you hadn't thought up half of them yourself without being told about them then you don't have much talent as a coder but aside from that, all that bringing out a load of books about them did was give no talent coders a method of lego brick programming that usually gives rise to some half arsed semi working inefficient POS that someone who has a clue ends up having to spend months debugging and sorting out other issues. I know I'm coming across as an arrogant snob but since when did programming stop being a profession and start being a free for all for all liberal arts failures who can type a line of C# and suddenly think they're Turing?
... is that they do not scale very well to software that is supposed to be on the cutting edge of what is technologically possible today. When all you think about is in terms of named patterns, then there's a pretty good chance that you're just reinventing stuff that other people have done. Perhaps you are doing it faster, or on a newer platform, but in the end, it's still just reinvention. Real pioneering comes from thinking outside of the box, where nobody else has ever tried exploring before. If all you can do is think in terms of the named patterns that other people have already thought of, then I think that's generally only going to hold you back.
File under 'M' for 'Manic ranting'
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.
"If you want to be challanged, get a job doing something weird that hasn't benefited years of people doing the same thing and improving the process."
Its not about me being challenged - I can do that with my own homebrew projects. What worries me is amateurs getting into coding positions and writing appalling code that probably ends up costing a lot more in the long run that if they'd hired people who had a clue. When Boeing or Airbus wants to build a new plane they don't hire some kid who's good folding paper aircraft, they hire proper engineers. I don't understand why IT should be treated so differently. Just because almost anyone can write a hello world program doesn't mean almost anyone should be allowed to work in programming.
From my experience familiarity of DP usually ends at singleton and factory. Idiots absolutely insist on writing as many as possible. More advanced idiots include command to the list and insist on replacing function calls with them.
It was stated already but it really has to be reinforced, "patterns" are names or common practises in modern programming, a common parlance.
I don't have to show you what a factory pattern is, you either know it or you can look it up.
Whether or not "pattern use" is effective is solely on the shoulders of the programmers that employ them.
Yes, patterns often are needed due to the inflexibility of your programming language of choice (erm, Java), and yes, when you first learn about them you tend to use them everywhere and over-engineer things to death (guilty!). BUT, with some experience you realize that it's the idea behind them that is important. Especially if you're using some agile methodology, you basically only end up with patterns or a piece thereof as a result of some refactoring (see Joshua Kerievsky's excellent book on the subject), and you should also be ready to move away from them as soon as you realize you don't need them. Patterns provide a direction, but they're not necessarily an end goal.
I haven't read this new book, but breaking down patterns into smaller, more fundamental chunks could be very useful in that "refactoring toward patterns" attitude.
"In our tactical decisions, we are operating contrary to our strategic interest."
It's actually an interesting topic.. because while newer languages and toolstacks have lowered the bar.. they've also made the cost of failure lower.
You can be a complete knuckhead.. and write absolutely terrible code. But if your using java.. it'll still probably work and after a while of hacking out the bugs (with more ugly code) it'll attain a surprising stability.
More relevant is this thought that better code will translate into the dollars and cents everyone else seems so concerned with. Sometimes it does, sometimes it doesn't. We get cheap coders because analysis of the business case shows you save more from the cheapness of the coders than you lose from the crumbiness of the software. If it was the other way around, most businesses would knock it off and up their standards.
Good jobs where they care about the skillset and are willing to pay for it do exist in industries where bad software costs a metric fuck-tonne (industries like defense, aerospace, medical) but it's no longer the norm for stuff where it doesn't.
The main issue with most "design patterns" is that they are exactly that: templates.
Yet they're needed, and that's the real sad thing: "good" projects do use them and there's a lot of incredibly repetitive code made of decorators, abstract factories, "fluent interfaces" (not really a "design pattern" but the issue is the same).
And that's because C# / C++ / Java are "the industry norm" or whatever. Nobody wants to use parentheses:
(decorate (wrap-subject) xxx)
That's too hard. There are parentheses you see: people prefer to write the same templates all over C# / C++ / Java code.
Design patterns are one thing: workarounds for C# / C++ / Java / Objective-C defects.
When you program in a Lisp dialect, like, say, Clojure (to name one Lisp dialect who's gaining a lot of traction lately) you can burn 400 of the 600 pages of the original GoF book.
Back in the days, when I read the GoF I thought it was cool, amazing, etc.
Now I' beginning to think there may be other ways because "templates" leading to extreme repetition all over a codebase --and, worse, realizing that this is actually the "less worse" you can do in such languages-- may not be the only way...
"I know I'm coming across as an arrogant snob but since when did programming stop being a profession and start being a free for all for all liberal arts failures who can type a line of C# and suddenly think they're Turing?"
I was in the business for a long time and it has been going on since time imemorable. Which is one reason I quit, we seem to never learn. And just as bad after 15 or so years in the business when you have learned your are considered to old and get thrown away. One of the other reasons I quit.
putting the 'B' in LGBTQ+
The underlying concept isn't as hard as the review makes it sound. Using some formalisms, the author creates a set of blocks upon which you can build patterns like those in the Gang of Four book. By doing so, you can see what commonalities occur and hopefully, this leads to deeper insight into what patterns really are.
The review mentions some detection of patterns in "legacy code" but the idea of refactoring the code to better support those concepts that is mentioned in the review seems too vague to me.
There was a good book on how you could use refactoring to implement design patterns in existing code, but it wasn't as grounded on theory and automation as refactoring itself. The theory mentioned is this work could maybe serve as a foundation for such an idea.
If this sparks a new set of tools that help automate the redesign of code to follow better practices, that'd be really great. But, I think there is still some real work left to be done before that happens. And while it remains to be seen, the formalism applied could reap great benefits in that regard.
Come over to the hardware side. People are a lot more thorough when it costs several million dollars and three months to run the compiler.
"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.
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
Just one. Verifiable from a third disinterested party.
On the other hand, I can think of at least one case where patterns thoroughly fucked up what might otherwise have been a useful thing (i.e. Microsoft's UI Automation). The dimwitted, heavy-handed attempt at jamming otherwise perfectly understandable user interface categories into "patterns" is painful to read and far more difficult to program than it needs to be. I don't need "patterns" to click an OK button. I need an interface path [my.exe].dialog.tab.controlobject (e.g. objButton) and a method ("Click"). That's all. That's useful. I don't need "SelectionPattern" or "InvokePattern" or any other productivity sapping nonsense imposed by a business-impaired, 20-something with a brainwave. Wrapping that crap into useful, understandably named member functions is the first thing you have to do to make UI Automation even vaguely useful.
Alternatively you have implemented additional design patterns without knowing it.
I'm sure that he has.
The reason is that a lot of the classical design patterns are such obviously good ways of doing things, that good programmers use them naturally even without knowing or reading about them before.
That leads me to wonder, how useful are design patterns really? In the end what they really seem to be, is simply a way to communicate a good way of building software to people who do not intuit the use of these things naturally.
The real question is do they work for that task? After many years of experience working with programmers of many different levels, I do not think they achieve that goal. Programmers who do not naturally grasp all of the things the patterns try to teach do not end up building better software with some understanding of the patterns. Instead they end up with a slightly pattern based mess, sometimes with patterns that are not really used as they are meant to be, sometimes with a horrendous number of patterns stuck together to make a bloated monster.
Do many people really feel like they learned much from careful studies of pattern books? I went through a couple in CS course in college based around patterns but honestly I never felt like I learned anything I would not have simply come across on my own (and as you note, indeed I had been using many of the patterns without having known the "official" names).
One could also claim that for advanced programmers patterns gives you terms you can use to discuss the structure of software. But even that has been of very limited value in practice, when working with teams of advanced programmers...
I just can't see that design patterns are nearly as useful to learn for programming as something like algorithms, many of which are not nearly so intuitive a thing that you would discover easily.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
SO glad to read that others have tired of pattern-overload (along with the associated overarchitecture). I have worked for multiple architects who include facades just for the sake of "fulfilling the pattern" and others whose first order of business is to write a bunch of object factories (uhh, the runtime is usually best for this, since object creation is a core feature) and more facades (even to entity objects!). (then there is the other flavor of architect who sees him/herself as some kind of integrator, piecing together frameworks for every conceivable function and saying it's an application architecture)
Patterns manifest themselves when you write well-designed code; using patterns is not what makes the code good per se.
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 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 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?'.
The problem, of course, is that lots of people who are hiring programmers also don't have a good ability to detect the ones that have are really skilled -- spending the money that it would cost to get someone that has a clue would often mean they were still getting not-so-good programmers writing needlessly-expensive-to-maintain code, but paying top dollar for it.
Because most IT work doesn't involve the level of risk associated with garden variety moderate deficiencies in competence that aircraft engineering does. (The IT work that does have that level of criticality often has substantially higher standards, and skilled people applying the standards.)
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?
Looking for a job?
Want your resume written professionally?
DON'T USE TUNAREZ!!!
Please tell me where you work so I NEVER apply there.
For what it's worth I was talking in the general, not my specific case. As it happens I did exactly as I said in my first post after working for a standard issue software mill and getting frustrated by the constant cost cutting and fear of outsourcing. Got into a specialized field where mistakes are expensive and high quality code is worth the price. Experienced coders, formal testing, people who can define the difference between system and software architecture, etc. I'd seriously recommend this to anyone getting fed up of being told "it works, ship it!".
Now how do cheap coders save money?
I don't pretend to understand how it works, I just have faith that things happen for a reason. Business guy's arn't _that_ stupid (they are generally making money after all). Obviously there are going to be cases where it doesn't work for whatever reason, but I have to assume that since the practice is becoming more universal, it has to have merit. Either way I've washed my hands of the mess.
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.
When I was studying in computer programming, there was a whole course about just UML and patterns (it was called Software Analysis I think). The whole subject was extremely efficient at inducing analysis paralysis, it was boring as hell, the software we used to draw UML diagrams was shit, and it almost killed my ability to code. My advice (as a very non-professional coder, but a knowledgeable enthusiast nonetheless - take this for what it's worth) is to just stick to well-defined use cases, good documentation and tests if you're in a big project. Fuck patterns.
The reason why having the Singleton pattern is bad is exactly because you can get a pointer to it from anywhere. That's the problem. You have no way to control side effects to fields that anyone can access from anywhere with no indication in the calling signature.
Except that the dire warning has no teeth, because mostly singletons are used to access resources that generally are not changing during the life of the application.
People are told simply that singletons are bad, without considering there are a lot of uses for singletons that are not bad in that way at all.
Furthermore I challenge the notion that code elsewhere changing a singleton value is at all bad for testing - you simply need to model possible changes in the singleton and have whatever code is being tested react to that. Who cares if it's other code or the test harness changing values? It's all testing the code.
If singletons are not abused they can be a very helpful resource, and to if I had to choose between testing and singletons in terms of getting better code together, I'd choose singletons because of the flexibility they give you.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
+5 Insightful
The barrier to entry in programming is very low, but that does not mean that programming is simple and/or easy.
+1 Cynical
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".
I am particularly struck by the depreciation of inheritance and the promotion of composition (has a rather ithen is a). This is a design decision I very much indorse, and I have done so over the course of many years. It has caused me trouble, because C++ code geeks think that if you are not using inheritance, you are doing a bad job. They're wrong. I know that I even was not hired on a couple of occasions because I expressed this opinion. I was very pleased when I saw that Google uses the same strategy.
Why is Snark Required?
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?
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.
And no you don't come across as arrogant; just stupid. I hope your day job isn't programming, because even though programming is nothing more than a simple craft that anybody can learn, it does take a certain level of intelligence to produce something that is worth-while.
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 book" is NOT a real reason.
Table-ized A.I.
"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.
I know I'm coming across as an arrogant snob
No, you're coming across as an pretentious uninformed hack that draws overly broad conclusions.