@Chimanet what other design patterns are u familiar with?

Is true, d calender class return d same instance of d same calendar

Service facade pattern, i hide all my business logic and data access code behind a service interface. From my presentation layer or web layer i jst call my service public methods

people don't appreciate oop structures and design patterns till they work on enterprise open source apps.

Using chimanet's example.

Lets suppose the factory class has a method that registers a car as sold, u don't want an inheriting class to over-ride such method. Factory classes are mainly used to collect the most basic common methods for a class and to hide some important business methods.

spikes C:
Lets suppose the factory class has a method that registers a car as sold, u don't want an inheriting class to over-ride such method. Factory classes are mainly used to collect the most basic common methods for a class and to hide some important business methods.

A factory class cannot have a method "that registers a car as sold". That's not what a factory class is used for. A factory class is used to create an appropriate instance of a family of related classes. And that is ALL it does. There's a reason it is in a group referred to as "creational patterns".

http://en.wikipedia.org/wiki/Factory_method_pattern

Chimanet: Service facade pattern, i hide all my business logic and data access code behind a service interface. From my presentation layer or web layer i jst call my service public methods

This is more like a session facade or a controller object in a model-view-controller(MVC) architecture.

harryobas:

This is more like a session facade or a controller object in a model-view-controller(MVC) architecture.

yea very useful in mvc, session facade in enterprise app development. A facade jst cordinate all d activities of different subsystem so as 2 give a clean and simple interface to d clients, clients can b web layer, thick clients etc. Just lyk an event manager 4 a party! Facades r normally injected into controllers in mvc

*facade (when it looks ugly, cover it with a facade)
*singleton (keeping a single game engine instance in a game for example)
*value object (whenever you find yourself shipping related pieces of data back and forth very often, consider this)
*chain of responsibility (when a task involves a complex subtask which in-turn involves another subtask, do not code everything together in a "god object", consider the chain-of-responsibility pattern)
*factory (you need to create multiple similar objects frequently based on some standard rules and you dont want client code messing with the underlying implementation, consider building your own factory)
*mvc (here is one hell of a pattern that will help your life and make iterations easier. a modification in on part of the code would not propagate throughout the entire system).
*event/listener or plug/socket (this is vest done with interfaces, just provide standard callback methods in your interface and client code can call them in their responses to events happening around them)
*god object (I personally use this with care as its not really a recommended practice. I usually have a class called GlobalConstants that serve as a central datastore for the entire app. Sometimes I also have GeneralUtils which provide static final methods to do some frequently occuring simple tasks; however, methods performing heavy duty tasks don't reside here)

Those are some of the ones I really use frquently. I also use some other ones that I dont know their standard names