It's been a little while again. I blame myself for installing World Of Warcraft again, too addictive.
Anyway, time for the Composite Pattern. This is one I'm having a little trouble with to describe clearly.
Let's start with the definition: "Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly."
Read more at http://blog.cumps.be/design-patterns-composite-pattern/
Time for the next part in our series, the Iterator Pattern.
Let's start with the definition: "Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation."
Read more at http://blog.cumps.be/design-patterns-iterator-pattern/
Time for yet another pattern, the Template Method Pattern. Have a look at all the other patterns in the series as well.
The definition: "Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure."
Read more at http://blog.cumps.be/design-patterns-template-method-pattern/
Today I'm going to tell you a little story about me. I think of myself as your typical description of a geek.
Passionate about all things technological, eager to find out how the inner details work together, a movie and music lover, and spending too much time behind a computer.
Having all those feats, over the course of twenty years, result in getting out of touch with the what interests the large part of the population.
I don't care about soccer, drinking, going out or making a complete fool out of myself. I can talk for hours about some architecture however, or about techy pranks.
But you know what? My surroundings don't have a clue what I'm talking about, usually ending up in me not bothering anymore. Same for taste of humor, I love the dry British kind, and everyone I know hates it.
This isn't some sort of self-pity post however. I'm fine with making conversation, but most of the time it's forced, and I constantly have to fight the analytical part of my mind to not interfere and kill the conversation.
That being said, I'd like to meet some other geeks from around the world to have a chat with, the international developer community.
Do you sometimes have the same feelings? Would you like to meet someone new? Talk about some random IT thing, or just about your life to a fellow geek?
Contact me! Tell me something about you, where are you from, how old are you, what do you do, some story. Please? :)
Writing all these articles is fun, but having dialogues is a lot more stimulating.
I hope to hear from you! :)
(Yeah, non-geeks can mail too, if you have some interest in IT or aren't bored by someone talking about it :))
Time for another, simple, design pattern. The Facade Pattern.
I'm going to need a break soon, getting a bit burned out, which never is a good thing.
Anyway, the definition of today's pattern: "Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use."
Read more at http://blog.cumps.be/design-patterns-facade-pattern/
What's a lonely geek to do late in the evening? Write about the Command Pattern of course...
Let's start with the definition: "Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undo-able operations."
Read more at http://blog.cumps.be/design-patterns-command-pattern/
A little follow up from yesterday's Singleton Pattern, where I asked for some help on how you would approach a generic singleton.
With the help of Andrew Stevenson and ExNihilo, we came up with the following Generic Singleton Pattern:
Read more at http://blog.cumps.be/design-patterns-generic-singleton-pattern/
Today we'll have a look at a well known pattern, the Singleton Pattern. Most people have already heard about this one.
The definition: "Ensure a class has only one instance and provide a global point of access to it."
Read more at http://blog.cumps.be/design-patterns-singleton-pattern/
Time to continue from yesterday's Factory Method Pattern by exploring the Abstract Factory Pattern.
Anyway, time for the definition and then some code to make everything clear. "Provide an interface for creating families of related or dependent objects without specifying their concrete classes."
Read more at http://blog.cumps.be/design-patterns-abstract-factory-pattern/