My workmate asked me this question today and I couldn't really give him short answer without using examples...
So let me ask you guys this question "What are design patterns" and try to give short answer that is the easiest to understand
My workmate asked me this question today and I couldn't really give him short answer without using examples...
So let me ask you guys this question "What are design patterns" and try to give short answer that is the easiest to understand
Design patterns are different approaches or tools or guides to solve Software Design problems. Mastering them, helps you
That would be my short explanation without using examples. But I always like using examples anyway, so if i had to provide examples too, I'd pick these to demonstrate the 'if you see this, do that' way of working with design patterns
When you know you have to provide an 'undo' feature in your transaction you know that the Command Pattern is a way to go
When you have to use a Resource manager, it would be nice to use the Singleton pattern
But while designing the AI for your RGP game NPCs, you can use Strategy pattern or Template pattern. Some might even choose Decorator Pattern. There's not always a definite winner. Depends on what suits you better.
Common scenarios of dividing responsibilities, tasks and information among modules, and defining the relations between them?
Design Patterns are patterns you use to construct a class based on certain conditions.
Example:
If there is a class that should be only 1 instance in the whole application (like a database adapter class) you go for Singleton
pattern, which is a pattern for constructing an object once. Only 1 instance.
When you have classes with a lot of attributes and default values you go for Builder
, which lets you construct an object by chaining it's setters
MyClass myClass = new MyClass.Builder()
.setTitle("my title")
.setBody("this is a body for the class")
.setEnabled(true)
.build();
When you have operations between business objects that are related but none of them owns the other, you go for Facade
, which creates a facade of your business to handle said objects.
I.E: you have Movies
, Sales
objects, but you can only create a Sale
if there are movies in the inventory. You can't use Sales
to check Movies
but you can create a facade called Store
and handle both object's operation like Store#createSale()
.
When you have event-based code execution (like on click), you go for a Listener
or Callback
.