Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I want to ask you to provide me with some articles (maybe books), which you possibly have found very convincing criticising the OOP methodology.
I have read some in the WWW on this topic and I didn't really find a 'definitive demotivator'.
It's not much about my personal attitude to the OOP, but I really would like to have something constructive, rigorous foundation for any kind of discussion and just abstract thinking.
You can post some original research too, but please be very constructive (as my personal request).
Which version of OOP? Alan Kay's original vision? The bastardized modern form of it that misses the point entirely and thus encumbers us with bizarre access control, member variables, etc? Inheritance-centric? Prototype-based? Compositional OOP?
Each form of OOP has its strengths and its weaknesses; its advocates and its detractors; its domains of utility and its domains of uselessness. There's nothing magical about OOP that makes it the Killer Paradigm and there's nothing infernal about it that makes it the Killer (of Programmers) Paradigm.
I can't really point you to any books or articles that killed my interest in OOP as a Silver Bullet (as opposed to one of many techniques I can use to keep my projects survivable). I can point to the funniest critique of a specific brand of OOP, however: Steve Yegge's classic "Execution in the Kingdom of Nouns".
Rick Hickey's Are We There Yet ? - A Deconstruction of Object Oriented Time was an eye opener for me. It's the most logical OO criticism I have come across.
If you want a criticism of OO programming, here's what I'd recommend:
Learn Smalltalk
Learn Erlang
Learn Scheme
Once you've done that, you will have plenty of criticism of the common interpretation of OO programming.
(Hint: OO was in many ways intended to more closely resemble the Actor model of computation, but the common interpretation of it is effectively a modification of the procedural/structured model)
Problem is - most people don't really know Object-Oriented Programming, so many designs SUCK.
Read the works of Scott Ambler, including his (now pretty old) Building Object Applications That Work. This has been eye-opening for quite a lot of people.
Maybe not quite what you were looking for but have a look at the Jan/Feb issue of IEEE Software magazine: Object-Oriented Analysis: Is It Just Theory?. The basic conclusion is that OOA does not provide a good cost/benefit ratio so is poorly utilized.
Given that OOA is not effectively utililzed or supported in the "real world", I suspect that for larger development projects the overall system architecture, deployed object model and class hiearchy end up being sub-optimal and poorly understood (implemented) by various parts of the development team. A second article in the same journal: Four Trends Leading to Java Runtime Bloat point to some common OOP issues that detract from deploying high-volume Java (OOP) systems. The observations made in this article probably apply to most highly architected OOP applications.
Do not take this as OO bashing, it just reflects that as software practictioners we have quite a bit of work to do toward developing better person-to-person communication mechanisms to convey highly complex and abstracted process models.
When you define a process in natural language. You use sentences where you define the subject who will do an action on one or more objects.
The only fix point is the action, the predicate of the sentence.
I don't think assigning actions to objects is a good idea.
There is only one verb, but can be multiple nouns.
In OOP you can write a file in at least 3 ways:
file.write(data);
or
data.writeToFile(file);
or
OperatingSystem.write(file, data);
Which object should implement the method? You need to think about this too.
While in the procedural way, you probably write
write(file, data);
And the only thing you need to think is the order of the operands which is usally does not matter.
(Well file and data may not be the best example but you probably see the point)
You should really see Mr. B. Jacobs's:
OOP Myths Debunked
(also known as OOP Oversold.)
http://cat-v.org has a great page on Object Oriented Programming.
Most of the page consists of humorous but not terribly informative quotes. However, at the bottom of the page are a number of links to articles challenging OOP. They are:
Bad Engineering Properties of Object-Oriented Languages by Luca Cardelli.
Why OO Sucks by Joe Armstrong
Pitfalls of Object Oriented Programming – By Tony Albrecht of Sony Computer Entertainment Europe, Research & Development Division.
Object-Oriented Considered Harmful by Frans Faase.
Object Oriented Programming Oversold!
I Hate Patterns – By Parand Tony Darugar.
Why arc Isn’t Particularly Object-Oriented – By Paul Graham.
The questions about inheritance in the Java IAQ.
Stop Writing Classes – Great talk about how classes are often used and abused. By Jack Diederich.
If you are interested in alternatives to Object-Oriented Programming:
cat-v.org. From their 'about' page: Cat-v.org hosts a series of sites dedicated to diverse subjects that share an idiosyncratic intellectual perspective, questioning orthodoxy and fomenting elitism and high standards in topics from software design to politics, passing by art and journalism and anything else interesting.
Structure and Interpretation of Computer Programs. Specifically teaches functional programming. Available free online here, for sale here. I cannot recommend this highly enough. It is absolutely revolutionary. It will change the way you think.
Any and all writings/videos/lectures by Rob Pike and Steve Yegge. Of particular interest is Yegge's Whirlwind Languages Tour.
I'd recommend learning a different programming paradigm or reading pro arguments for specific paradigms (http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf). Besides OOP, I think the most widely used is the functional paradigm (search f.e. "Why functional programming matters"), but also have a look at the other ones. When you start looking at programming from a different perspective, the flaws of OOP start to appear automatically.
Simple exercise: define the objects IPerson, CMale and CFemale and implement the methods "sex" and "reproduce".
hows about steve yegge's execution in the kingdom of the noun
for java style OO
The Gideon Bible of object-oriented design patterns, aptly named Design Patterns. One of the best software design books I've ever read.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When I'm learning a new language, I often program some mathematical functions to get used to the control flow syntax. After that, I like to implement some sorting algorithms to get used to the array/list constructs.
But I don't have a standard exercise for exploring the languages OO features. Does anyone have a stock exercise for this?
A good answer would naturally lend to inheritance, polymorphism, etc., for a programmer already comfortable with these concepts. An ideal answer would be one that could be communicated in a few words, without ambiguity, in the way that "implement mergesort" is completely unambiguous. (As an example, answering "design a game" is so vague as to be useless.)
Any ideas?
EDIT: I have to remark that the results here are somewhat ironic. 10 upvotes and (originally) 5 favorites suggest that this is a question others are interested in. Yet the most upvoted answer is one that says there is no good answer. Oh well. I think I'll look at the textbook below, I've found games useful in the past for OO.
I can't imagine there could be a standard set of exercises that would naturally introduce OO features of a programming language to everybody. A lot of the introductory OO tutorials are full of Animals, Cats, and Dogs which does not really cut it for me at least. Find a problem domain in OO you've struggled with a lot, and try to use that as your set of stock exercises for each language you pick up.
The OO constructs that we are used to thinking in terms of may not make sense in a language. Javascript comes to mind which shakes the entire foundation of how we think about objects in general. That said, you shouldn't adapt to a language but rather adapt the language for your purposes. Over time as your knowledge repository grows and improves with experience, you'll naturally want to implement what you think is best in each programming language that you use regardless of what the language offers.
Good question...
In my opinion the best teacher is just find a simple example of OO features and try to write something alone, creating new examples for Yourself and trying develop simple application in which You can connect all features of OO .
Implementing algorithm like merge sort which don't use OO feature, cause they don't need it is useless. Try real useful programs.
I remember when learning OO i write application with general "Animal" interface with methods and class which inherit it, like "amphibian". it was fanny time ;)
Some fun: implement the Shape/Circle/Ellipse hierarchy without falling into the trap (it can be done very nicely in Java, Scala, etc.).
edit implement it before looking at the proposed solutions in the Wikipedia article :)
I've used Hunt The Wumpus. The original implementation in BASIC was not at all OO, but if you start fresh it lends itself pretty nicely to this.
Here's what I use:
http://homepage.mac.com/s_lott/books/oodesign.html
I've done it enough times that it's "standard" in my opinion.
This might be too specific, but it's what I credit for really getting me to understand OOP personally. For my work I had to write code to extract data from a large variety of different sources. It seemed straightforward to me at the time that I should tackle the problem from the perspective of designing various "DataProvider" classes. What only gradually became clear was how much code I could reuse by breaking the different kinds of providers down into hierarchical categories, like this:
DataProvider
TextDataProvider
HtmlDataProvider
CsvDataProvider
XmlDataProvider
BinaryDataProvider
...and so on. I would suggest that any problem like this--where you need to accomplish a certain kind of task (in my case, extracting data) in a bunch of different ways (e.g., from multiple sources)--will be a great opportunity to delve into OOP and hopefully learn to appreciate how useful it is.
I personally find the best way to learn OO, is to write your own testing framework.
I find a layout of a Test Runner, owning one or more Test Suites, which each have their own Test Cases enough of a starting point, but you can easily grow it from there, and it might even be something you care to use in the future.
Alternatively, if you want something completely throw away, there's always Enterprise FizzBuzz. :)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
What is the difference between a software development pattern?
A methodology such as agile DSDM etc how is OO classed as a methodology and a paradigm?
How can OO be applied to a methodology such as agile if itself is a methodology?
Whats the difference between a paradigm and a methodology or a development pattern?
Thanks for any replys.
"When I use a word," Humpty Dumpty
said, in a rather scornful tone, "it
means just what I choose it to mean -
neither more nor less." "The question
is," said Alice, "whether you can make
words mean so many different things."
"The question is," said Humpty Dumpty,
"which is to be master - that's all."
Through the Looking Glass.
Well, not my answer, Lewis Carroll's.
Looking at only one of the questions you asked: "...how is OO classed as a methodology and a paradigm?"
That, at least, has a fairly simple answer:
Object Oriented Design is an analysis methodology.
Object Oriented Programming is an implementation paradigm.
OOD involves analyzing a problem in terms of objects and their interactions. OOP involves implementing a solution as a set of interacting objects.
"Agile" (I hate that name -- though I'll admit "eXtreme Programming" is worse) is really about project management. Just for example, you can apply Pair Programming about equally to something like assembly language or C as to a language that explicitly supports object oriented programming (though being a relatively new idea, it's probably used most often in conjunction with relatively new languages).
Edit: How I'd separate "methodology" from "paradigm" is fairly simple (at least in theory).
Paradigm is really just a fancy word for "example". If I'm following that example to a meaningful degree, the source code (for example) to the program should contain direct, (fairly) clearly defined results from having followed that example. Just for the obvious one, a class publicly derived from another would be a pretty obvious indication of OOP.
A methodology, by contrast, doesn't necessarily show a direct, definable result in the source code. Just for example, there's unlikely to be much in the source code to indicate whether it was developed using "Agile" methodology. I might be able to take a guess if (for example) all the source code files contained comments indicating two authors, but (at best) it would a rather indirect indication of one specific piece of the methodology.
I said in theory, because things can get a bit "fuzzy" at times. If I try hard enough, I can probably write pretty close to pure procedural code, even in a language like Smalltalk that favors objects almost exclusively. Likewise, if I try hard enough I can write OO code in something like C that doesn't really support it. In a case like this, the indications of following the paradigm will usually be harder to find or define than in a more straightforward case.
Methodology is about people. Paradigm is about software.
A paradigm is a way of thinking about a problem - so objects, a relational database, lambda calculus are all models for getting a problem into your head
A methodology is a way of actualy building something based on the paradigm.
If you like, the paradigm is the architect, what are building? should it be a suspension bridge or an arch. The methodology is the engineering, how many cables, how thick, which subcontractors.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I asked a question previously about Dataset vs Business Objects
.NET Dataset vs Business Object : Why the debate? Why not combine the two?
and I want to generalize the question here: where is the proof that OOP is really suitable for very complex problems ? Let's take a MMO Game Engine for example. I'm not specialist at all but as I read this article, it clearly stands that OOP is far from being enough:
http://t-machine.org/index.php/2007/11/11/entity-systems-are-the-future-of-mmog-development-part-2/
It concludes:
Programming well with Entity Systems is very close to programming with a Relational Database. It would not be unreasonable to call ES’s a form of “Relation Oriented Programming”.
So isn't OOP trying to get rid off something that is here to stay ?
OOP is non-linear, Relational is linear, both are necessary depending on the part of a system so why try to eliminate Relational just because it isn't "pure" Object. Is OOP an end by itself ?
My question is not is OOP usefull. OOP is usefull, my question is rather why the purists want to do "pure" OOP ?
As the author of the linked post, I thought I'd throw in a couple of thoughts.
FYI: I started seriously (i.e. for commercial work) using OOP / ORM / UML in 1997, and it took me about 5 years of day to day usage to get really good at it IMHO. I'd been programming in ASM and non-OOP languages for about 5 years by that point.
The question may be imperfectly phrased, but I think it's a good question to be asking yourself and investigating - once you understand how to phrase it better, you'll have learnt a lot useful about how this all hangs together.
"So isn't OOP trying to get rid off something that is here to stay ?"
First, read Bjarne's paper here: http://www.stroustrup.com/oopsla.pdf
IMHO, no-one should be taught any OOP without reading that paper (and re-reading after they've "learnt" OOP). So many many people misunderstand what they're dealing with.
IME, many university courses don't teach OOP well; they teach people how to write methods, and classes, and how to use objects. They teach poorly why you would do these things, where the ideas come from, etc. I think much of the mis-usage comes from that: almost a case of the blind leading the blind (they aren't blind in "how" to use OOP, they're just blind in "why" to use OOP).
To quote from the final paragraphs of the paper:
"how you support good programming techniques and good design techniques matters more than labels and buzz words. The fundamental idea is simply to improve design and programming through abstraction. You want to hide details, you want to exploit any commonality in a system, and you want to make this affordable.
I would like to encourage you not to make object-oriented a meaningless term. The notion of ‘‘object-oriented’’ is too frequently debased:
– by equating it with good,
– by equating it with a single language, or
– by accepting everything as object-oriented.
I have argued that there are–and must be–useful techniques beyond object-oriented programming and design. However, to avoid being totally misunderstood, I would like to emphasize that I wouldn’t attempt a serious project using a programming lan-
guage that didn’t at least support the classical notion of object-oriented programming. In addition to facilities that support object-oriented programming, I want –and C++ provides features that go beyond those in their support for direct expression of concepts and relationships."
Now ... I'd ask you ... of all the OOP programmers and OOP projects you've seen, how many of them can honestly claim to have adhered to what Bjarne requests there?
IME, less than the majority.
Bjarne states that:
"The fundamental idea is simply to improve design and programming through abstraction"
...and yet many people invent for themselves a different meaning, something like:
"The fundamental idea is that OOP is good, and everything-not-OOP is inferior"
Programmers who have programmed sequentially with ASM, then later ASM's, then pascal, then C, then C++, and have been exposed to the chaos that was programming pre-encapsulation etc tend to have better understanding of this stuff. They know why OOP came about, what it was trying to solve.
Funnily enough, OOP was not trying to solve every programming problem. Who'd have htought it, to say how it's talked about today?
It was aimed at a small number of problems that were hugely dangerous the bigger your project got, and which it turned out to be somewhere between "good" and "very good" at solving.
But even some of them it isn't any better than merely "good" at solving; there are other paradigms that are better...
All IMHO, of course ;)
Systems of any notable complexity are not linear. Even if you worked really hard to make a system one linear process, you're still relying on things like disks, memory and network connections that can be flaky, so you'll need to work around that.
I don't know that anyone thinks OOP is the final answer. It's just a way of dealing with complexity by trying to keep various problems confined to the smallest possible sphere so the damage they do when they blow up is minimized. My problem with your question is that it assumes perfection is possible. If it were, I could agree OOP isn't necessary. It is for me until someone comes up with a better way for me to minimize the number of mistakes I make.
Just read yr article about Entity Systems, which compares ES to OOP, and it is flagrantly wrong about several aspects of OOP. for e.g., When there are 100 instances of a class, OOP does not mandate that there be 100 copies of the classes methods loaded in memory, only one is necessary. Everything that ES purports to be able to do "better" than OOP because it has "Components", and "Systems", OOP supports as well using interfaces and static classes, (and/or Singletons).
And OOP more naturally fits with the real-world, as any real or imagined Problem Domain, consisting of multiple physical and/or non-physical items and abstractions, and the relationships between them, can be modeled with an appropriately designed hiearchical OOP class structure.
What we try to do is put an OO style on top of a relational system. In C# land this gets us a strongly typed system so that everything from end to end can be compiled and tested. The database has a hard time being tested, refactored, etc. OOP allows us to organize our application into layers and hiearchies which relational doesn't allow.
Well you've got a theoretical question.
Firstly let me agree with you that OOP is not a solve-all solution. It's good for somethings, it's not good for others. But that doesn't mean it doesn't scale up. Some horribly complex and huge systems have been designed using OOP.
I think OOP is so popular because it deserves to be. It solves some problems rather wonderfully, it is easy to think in terms of Objects because we can do that without re-programming ourselves.
So until we can all come up with a better alternatives that actually works in practical life, I think OOP is a pretty good idea and so are relational databases.
There is really no limit to what OOP can deal with - just as there is no real limit to what C can deal with, or assembler for that matter. All are Turing-complete, which is all you really need.
OOP simply gives you a higher-level way of breaking down the program, just as C is a higher-level than assembler.
The article about entity systems does not say that OO cannot do this - in fact, it sounds like they are using OOP to implement their Entities, Components, etc. In any complex domain there will be different ways of breaking it down, and using OOP you can break it down to the object/class level at some point. This does not preclude having higher-level conceptual frameworks which are used to design the OOP system.
The problem isn't the object oriented approach in most situations, the problem is performance and actual development of the underlying hardware.
The OO paradigm approach software development by providing us with a metaphor of the real world, were we have concepts which defines the common accepted and expected properties and behaivour of real objects in the world. Is the way that humans model things and we're able to solve most of the problems with it.
In theory you can define every aspect of a game, system or whatever using OO. In practice if you do, your program will simply behave too slow so the paradigm is messed up by optimizations which trade the simplicity of the model from performance.
In that way, relational databases are not object oriented so we build an object oriented layer between our code and the database... by doing so you lost some of the performance of the database and some of its expressiveness because, from the point of view of OO paradigm a relational database is a full class, is an very complex object that provides information.
From my point of view OO is an almost perfect approach in the theoretical sense of the word, as it maps closely to the way we, humans, think, but it doesn't fit well with the limited resources of the computational development... so we take shortcuts. At the and, performance is far more important than theoretical organization or clearness so this shortcuts become standards or usual practices.
That is, we are adapting the theoretical model to our current limitations. In the times of cobol in the late 70's object oriented was simply impossible... it would imply to many aspects and too little performance so we used a simplified approach, so simplified you didn't have objects or class, you had variables ... but the concept was, in that time, the same. Groups of variables described related concepts, properties that today will feet into an object. Control sequences based on a variable value where used to replace class hierarchies and so on.
I think we've been using OOP for a long time and that we'll continue using it for a long time. As hardware capabilities improve we'll be able to unsimplify the model so that it becomes more adaptable. If I describe perfectly (almost) the concept of a cat (which involves a lot of describing for a lot of concepts involved) that concept will be able to be reused everywhere... the problem here is not, as I've said, with the paradigm itself but with our limitations to implement it.
EDIT: To answer the question about why use pure OO. Every "science" wants to have a complete model to represent things. We have two physic models to describe nature, one at the microscopic level and one for the macroscopic one, and we want to have just one because it simplifies things it provides us with a better way to prove, test and develop things. With OO the same process applies. You can't analytically test and prove a system if the system doesn't follow a precise set of rules. If you are changing between paradigms in a program then your program cannot be properly analized, it has to be disected in each one, analized and then analized again to see that the interactions are correct. It makes a lot more difficult to understand a system because in fact you have two or three system that interact in different ways.
Guys, isn't the question more about ORM than OOP? OOP is a style of programming - the thing that actually gets compared is a Relational Database mapped onto objects.
OOP is actually more than just the ORM! It's also not just the inheritance and polymorphism! It's an extremly wide range of design patterns and above all it's the way we think about programming itself.
Jorge: it's ok that you've pointed out the opitimization part - what you didn't add is that this step should be done last and in 99% cases the slow part is not the OOP.
Now plain and simple: the OOP style with all the principals added to it (clean code, use of design patterns, not to deep inheritance structures and let's not forget unit testing!) it a way to make more people understand what you wrote. That in turn is needed for companies to keep their bussiness secure. That's also a recepie for small teams to have better understanding with the community. It's like a common meta language on top of the programming language itself.
It's always easier to talk about concepts from a purists point of view. Once you're faced with a real life problem things get trickier and the world is no longer just black and white. Just like the author of the article is very thorough in pointing out that they're not doing OOP the "OOP purist" tells you that OOP is the only way to go. The truth is somewhere in between.
There is no single answer, as long as you understand the different ways (OOP, entity systems, functional programming and many more) of doing things and can give good reason for why you're choosing one over the other in any given situation you're more likely to succeed.
About Entity Systems. It's an interesting conception but it brings nothing really new. For example it states:
OOP style would be for each Component to have zero or more methods, that some external thing has to invoke at some point. ES style is for each Component to have no methods but instead for the continuously running system to run it’s own internal methods against different Components one at a time.
But isn't it same as Martin Fowler's anti-pattern called "Anemic Domain Model" (which is extensively used nowadays, in fact) link ?
So basically ES is an "idea on the paper". For people to accept it, it MUST be proven with working code examples. There is not a single word in the article on how to implement this idea on practice. Nothing said about scalability concerns. Nothing said about fault tolerance...
As for your actual question I don't see how Entity Systems described in article can be similar to relational databases. Relational databases have no such thing as "aspects" that are described in the article. In fact, relational - based on tables data structure - is very limited when it comes to working with hierarchical data, for example. More limited than for example object databases...
Could you clarify what exactly you are trying to compare and prove here? OOP is a programming paradigm, one of the many. It's not perfect. It's not a silver bullet.
What does "Relation Oriented Programming" mean? Data-centric? Well, Microsoft was moving towards more data-centric style of programming until they given up on Linq2Sql and fully focused on their O/RM EntityFramework.
Also relational databases isn't everything. There is many different kinds of database architectures: hierarchical databases, network databases, object databases ect. And those can be even more efficient than relational. Relational are so popular for nearly the same reasons why OOP is so popular: it's simple, very easy to understand and most often efficient enough.
Ironically when oo programming arrived made it much easier to build larger systems, this was reflected in the ramp up in software to market.
Regarding scale and complexity, with good design you can build pretty complex systems.
see ddd Eric Evans for some principle patterns on handling complexity in oo.
However not all problem domains are best suited to all languages, if you have the freedom to choose a language choose one that suits your problem domain. or build a dsl if that's more appropriate.
We are software engineers after all, unless there is someone telling you how to do your job, just use the best tools for the job, or write them :)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm a confused newbie and hobbyist programmer trying to get a grip on this, so forgive me if my question is a little off or doesn't make much sense.
I see a lot of questions on SO revolving around the use of design patterns, and I'm wondering if anyone has a good resources for learning about, and implementing design patterns? I understand the general idea, and know how/when to use a couple of them(Singletons, Factory methods) but I know I'm missing out.
(Just in case it matters, my language of preference is C# but I could learn from examples in other languages)
Head First Design Patterns
and the Design Pattern Wikipedia page are the best resources for beginners. FluffyCat is another good, free online resource for design patterns in both Java and PHP.
The Gang of Four book is where to go afterward, but it's fairly advanced, so I'd wait until you have a pretty firm grasp from the other resources.
Design patterns are great for various reasons:
gives you a starting for solving common problems.
gives developers a vocabulary to talk about certain ways of solving problems in a very compact manner.
when working with developers who know design patterns and you use design patterns in your solutions they will understand the solutions a lot faster.
But when your goal is just to learn design patterns I think you are missing the fundamentals. All design patterns are based on more common principles. High Cohesion, Low Coupling Open Closed Principle, DRY, Liskov Substitution Principle etc. For these fundamentals I would read the following books in this order:
Head First Object-Oriented Analysis and Design (Head First) [ILLUSTRATED] (Paperback)
Applying UML and Patterns (Hardcover)
Agile Principles, Patterns, and Practices in C# (Robert C. Martin Series) (Hardcover)
After that you are ready for the basic gang of four design patterns
Head First Design Patterns (Head First) [ILLUSTRATED] (Paperback)
The BIBLE
A nice website (don't buy anything, it is not worth it) http://dofactory.com/Patterns/Patterns.aspx (some implementations of this site are worth a discussion
The next step:
Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series) (Hardcover)
The POSA books
And always remember : the pattern is not the goal !
I'd add that Design Patterns book from the "Gang of four" is a bible for anyone who is seriously interested in design patterns.
My tip:
Read a lot about the patterns from different sources.
Trying to force as many patterns as possible into all the code you're writing as this point is not going to give good results. Instead, let the information rest inside your brain for a while (read: months).
Suddenly you'll find yourself stumbling upon a problem or piece of code and you'll vaguely remember that you've seen something that might work as a solution to this particular problem. Now is the time to look up the details on the pattern you are thinking of and try to apply it.
That's what has worked for me, anyway.
Design Patterns
This tutorial site contains following sub-sections
Intent of each design pattern
Real World Structure for the design pattern
A Problem statement
Detailed discussion on the problem
Checklist on how to arrive at a pattern
Rules of thumb while arriving at pattern.
Code snippets for the design pattern which includes C#, C++, Delphi, Java and PHP
This site also contains guide on Anti Patterns, UML and Refactoring.
Bruce Eckel has a book on design patterns, although it's Java, it's like all of his books amazing. And the best thing is, they are free!
C# 3.0 Design Patterns for a C# perspective on design patterns.
(source: oreilly.com)
An introductory book that I found useful and well written is
Design Patterns Explained by Alan Shalloway and James Trott (Addison Wesley).
Do not start from the Gang of Four book, for it is not an introductory book by any means.
I would recommend taking a look at Jean Paul Boodhoo's quintology (?) on Demystifying Design Patterns on DNRtv, urls supplied below. The videocasts touches on Singleton, Abstract Factory among others- the difference being that you can watch him code as he discusses the theory. Good to watch over lunch on a rainy weekday.
http://www.dnrtv.com/default.aspx?showNum=63
http://www.dnrtv.com/default.aspx?showNum=65
http://www.dnrtv.com/default.aspx?showNum=68
http://www.dnrtv.com/default.aspx?showNum=71
http://www.dnrtv.com/default.aspx?showNum=92
An annotation to the above comments.
A Quick Reference For GOF Patterns
Here is a good place you can start dofactory.com/patterns/patterns.aspx - You can find link to each pattern, along with corresponding implementations.
How ever, remember that these are GOF patterns. You might need to read and understand advanced patterns as well, once you gain enough expertise in OOAD. Head First Design Patterns is a good start, and after making some progress, go with Martin Fowler's Enterprise Application Architecture Patterns.
Applying Design Patterns - The Thought Process
Another main aspect - Applying Design patterns is as important as just knowing them. Reading these articles might help you as well.
Applying Design Patterns Part I
Applying Design Patterns Part II
Hope this helps
Head First Design Patterns is a good one like others already noted. Besides this, of course the original book and C# Design Patterns. Also there are good websites already mentioned.
Besides self-learning, I seriously recommend starting or attending a pattern study group in your area. See A Learning Guide To Design Patterns for explanation and great order to study the patterns in. We did this and I can honestly say that I would not understand as much as I do now. A weekly meeting with other interested people keeps you surprisingly disciplined when learning something abstract like design patterns.
Happy studies!
Before spending money on books I would recommend Wikipedia's excellent design patterns page. Also for something different Google for "design pattern screencasts" or search for "design patterns" on YouTube. Getting the same information presented differently often helps the penny drop.
The Gang of Four book is the definitive text on the most well known patterns but is not that easy to read and with C++ examples not everyone's favourite.
The Head First Design Patterns text is far more accessible but only contains a subset of the Gang of Four patterns.
The most important thing is to understand where and why a particular pattern is useful. Afterwards search the web for implementation examples in the language of your choice and experiment until you "get it". Understand one pattern before moving on to the next. Everyone understands some patterns better than others (and there are hundreds of lesser known ones).
Just keep plugging away.
(source: Amazon)
Patterns of Enterprise Application Architecture (Hardcover) by Martin Fowler
Refactoring to Patterns (Hardcover) by Joshua Kerievsky
Continuous Integration: Improving Software Quality and Reducing Risk (Paperback) by Paul Duval et.al.
Beyond Software Architecture: Creating and Sustaining Winning Solutions (Paperback) by Luke Hohmann
Design patterns are like any library function, read about them, then when a problem comes up, the design pattern will be in your "Toolchest". There are many design patterns books all patterned after the original "Gang of four" design patters.
For any programmers, I think that and the Refactoring book by Fowler are the absolute minimal requirements.
For websites, a very good site is http://ajaxpatterns.org, from one of the developers of the ajaxian website
The original Design Patterns book is a must-read for all programmers.
It is an excellent book on every level: layout, clarity, insight, depth. It's one of those great books that you first read cover-to-cover, and then use as a reference until you literally know it inside out.
You could start by the Wikipedia page, but treat yourself with the great book too.
Applying UML and Patterns by Craig Larman. Start from the basic of analysis, design and uses a simple Case scenario. Introduces most of the basic patterns in a simple way.
If you read about design patterns you'll notice that Java seems to have a few of them implemented.
Look at the source for any framework and you can glean info about design patterns. Personally I don't see them fitting in perfectly to any of my code, sometimes the examples in books and tutorials seem a little idealized, especially for the lone coder.
Design patterns aren't for lazy coders.
For me and my colleagues study Design Pattern that following on Pattern Study Group. They prepare a list of each pattern that we should learn in order and also have the opening questions that make more discussion in group.
I also suggest having a shufty at Refactoring to Patterns once you've read Head First Design Patterns.
Note: The code examples are in Java, but should be very similar to C# examples...
It does not make too much sense to me for someone with very little experience to delve too far deeply into design patterns. It is great to know they exist, but at this point you should focus more on other things rather than just learning about design patterns.
They are useful in context of a problem - as a concept for a new/beginner developer they are really not too much practical value aside form knowing that you should make use of them when and where you can.
EDIT
To clarify - many design patterns are a result of problems found in some domains. A new programmer can hardly be expected (IMO) to know the design pattern(s) to use for some set of problems. Just as we get a smattering of algorithms in CS studies, we need an understanding of the things we can do with patterns and their benefits, but when a person is still building hello world or discovering stl there is not much practical need for design patterns. Patterns are great. But they are not the silver bullet.
(Neither was CASE (tools), neither is/was UML, neither is SCRUM, neither is TDD, nor STL, nor Java, nor XML, etc. ) These are all just aspects of our profession and to treat these topics as the second coming is naive.
Patterns comprise the high level vocabulary programmers use to talk about abstract design. If you are reusing an abstract solution, it is helpful to refer to it by name. If you invent a pattern, it is professional to do a little checking to make sure it hasn't already been given a name. If it has been named, then the description may be useful.
After you code even a tiny bit, you will notice yourself writing something similar to what you coded before. This is a pattern. Even if it is a tiny pattern, it is worth noticing. Is there a better pattern? Do you see certain tiny patterns cooperating together to solve a larger problem? Well next time, when you want to solve larger problem, the entire pattern comes into your mind as a single chunk. Fleshing out the detailed lines of code becomes mechanical.
The more you notice patterns, the easier programming becomes, and the more you will appreciate some of the biggest and best patterns worked out by other programmers.
Try mastering the MVC pattern. One way or another, variations show up all over the place, even in tiny design decisions.
Once you understand the concept, go through the Eclipse source code or design, lots of really good examples of these patterns (no surprise, Gamma was one of the designers).
I have found Design Pattern articles on this website really easy to understand
Design Patterns in C#