I want to explain design patterns to my niece, but always struggle in doing so. It is largely due to my lack of clear understanding of design patterns. How do you suggest explaining patterns like MVC,Singleton,Factory,Repository etc in such simple terms that even kids of 10 years old can understand.
I'm looking for examples which can ease in helping understanding patterns. Examples with toys,movies,music etc.
I think the beginning of the Wikipedia article is probably a good start:
A design pattern is a general reusable solution to a commonly occurring problem.
Or are you wanting to explain the specifics of those particular patterns?
It depends why you want to explain it. If you just want to explain the idea of patterns, I'd draw on examples from architecture in A Pattern Language. These researchers found that certain aspects of a building or a room made people enjoy living or working in that building or room - all over the world in different cultures, with different building materials, and in different kinds of neighbourhoods. Like "Light on Two Sides" for example. Rooms with windows on two walls are just so much nicer than those with only one (or none.) There are patterns like that in software too - even using different programming languages, some patterns recur. And even in very different software - a game, something for financial calculations, the engine inside Facebook, and so on.
Then if you want to talk about a particular pattern (not sure why, to a ten-year old) you could start by giving examples of where its used before you try to explain how it works. So Composite lets you avoid explicit recursion when you're figuring out the weight of a suitcase by adding up the weight of the container and the total of all the containers and loose things it holds, but it also works for calculating salary burden in a corporation or capacity in a manufacturing complex. If that is even a little interesting to the ten year old you could try to explain how it works.
Design patterns exist because some people realised that there were ways of getting bits of software to work well together, and wanted to share their insights.
You can think of design patterns in the same way that you think of groups of people. For instance, sometimes we have one person who facilitates all our meetings. That's like a Controller pattern, which facilitates interactions between objects.
Or imagine an audience, where someone at the front of the room watches for people putting their hands up, then repeats the question so everyone else can hear, or maybe reacts by answering it. That would be similar to a Subject / Observer pattern.
There are patterns which behave like translators (the Adapter pattern), like security guards (the Proxy), like experts in a field (Singletons), or like people who check your car is working (Validators).
The difference between objects and people is that we can pretty much create as many objects as we want, and have multiple different copies of them. That makes it important to understand what responsibilities objects should have, keep their responsibilities small, and try not to duplicate what they do, so that the software doesn't get too complicated. The experts have a great deal of experience in this, and they've given us these patterns of how effective software interacts so that we can decide what kind of role is the best metaphor for the job we're trying to do, and get the pieces of software to collaborate in the most appropriate way.
Tell her that they are used to build up individual components of a system, like cooking techniques are used to build a meal/dish. Imagine you are making dinner, with potatoes, meat and veg. You decide you want the potatoes boiled and mashed, the meat grilled and the vegetables steamed. You use your grill design pattern to cook the meat, boil and mash patterns for the potatoes and steam pattern for the veg.
Most of these design patterns are part of object-oriented design. You cannot really explain them to someone with no understanding of OOD. You could describe the goal that you achieve with given pattern, but not how it works nor why do you need it. Unless of course you go into explaining the whole OOD.
Design patterns were first described for architecture. Things like location of the square, buildings, and other generally repeated layouts. You might start there. Things like main entrance faces the street, door towards corner of the room, and anything else you can think of. The original author's patterns were not widely used. He is reported to now state that patterns themselves are not enough.
Discuss moving things around the room. Put a chair in front of the door. Would it make sense to move the windows or door elsewhere. Why or why not?
Try something like setting a place at the table. Try arranging things by size going away from you. Not the normal pattern and hard to work with. Set it up normally. It this a suitable layout for a quick glass of juice? Patterns are not always appropriate.
We live with patterns all the time. Take three or four books and start paging through them. There is an obvious pattern in the layout; title page, table of contents, content, and index. Not all components are required, but it would be confusing to see them out of place.
Design patterns are to software development what jigs are to woodworking. It's a tool with which you can make well known 'cuts' to use in larger projects.
Note, that you don't need the jig to make the cut, it's just easier in some circumstances.
I feel my other answer stands for the general case, but the OP commented asking for specifics (so I felt it deserved a seperate answer). Sadly I'm not familiar with the Repository pattern, but I'll take a stab at the others. As a rule, I think the best way to explain these is through what problem you want to solve, why you want to solve it and how the problem accomplishes it.
This pattern is used when we want to guarantee that there is only one of something. The pattern is accomplished by preventing others from creating our object.
This pattern is used to help keep things modular with all benefits that come with that. The View is the "user interface", the Model is the data (including business logic), and the Controller is how the user actions manipulate the model. With this modularity, nothing stops me from having multiple views / controllers to work with the same model. For an overly simplified example, I can interact with my email ("model") through a web site, desktop application, and my iPhone ("views + controllers"). If I have a shared group mailbox, I could create a controller that would not send email, and reuse the same application view and email. (yes overly simplistic, but hopefully understandable :) )
Additionally, with this well defined seperation of concerns, changes in one (ideally) do not require changes in another. Concrete example, if i need to support reading/writing to a MySQL database instead of an Oracle database, I would only need to change my model, and my view/controller does not change.
Have to be careful here since there are many similar patterns called Factory... I'll talk about the Abstract Factory, but you should know there is also a Factory Method pattern as well.
Basically, I would use an Abstract Factory when I know what steps I want to perform, but the steps on how to accomplish these inividual steps could vary. For example, I could be building an application where I need to create a dialog box with a button on it. By having my code use a hypothetical UI factory, if I need my code on Mac or Linux instead of Windows, I just provide a different factory, and the rest of my code does not change. For a a potentially wilder example, I could have a Web Factory and suddenly most of the code backing my desktop application is now also powering a rich website :) (ok impractical for other reasons, but in theory :) )
To an 10 year old who want to be a hacker - I would say.
Imagine if you could have some of the best hackers in the world sitting next to you when you were hacking away.. and every now and then they would say.. "you know if you do it like this... [insert pattern]... then you code will be [faster/safer/more maintainable/etc]" how cool would that be.
Now that I assume she is keen on the idea - I would not waste my time explain each pattern I would set her "hacking task".. and then post apply a design pattern and explain the value... then just point her to some good resources and see where it goes.
But mostly she will need to learn them via mentoring.
