What are design patterns exactly??
-->reusable solutions to our problem
-->it's just a hint,though not a complete solution.
-->You can make changes to the template to suit your needs.
-->When over engineered with design patterns your project will explode onto your head.
Your code may still work fine when considering modular pieces of code,but if u dont follow design patterns in its very modular form,i caution you once you integrate it will all come together and BANG your head!!
Actually patterns is not any new concept or architecture or stuff.Its all just what you already use in your real life but you still dont recognise.For instance you can group the options which are related and put it in to a menu format floating at the top of a page--->It forms a pattern
Or..
You can put it in the form of a list on your side bar it is also a pattern usage,It all depends on which environment and circumstance you use it with.
The Five basic principles of Design patterns in OOPS are S.O.L.I.D
S-single responsibility principle
--->It says that the every class should have only 1 responsibility.
--->A single class's responsibility should be encapsulated within that particular class
In general terms it means that related functions shouls be binded..
For instance consider a user classs,...A user can login or buy items or get gift etc,but for that matter you cant put everything together into USER class.This will violate the single responsibility principle.
The solution to this is
class login{
};
class gift{
};
class cart{
};
class user{
login l;
gift.g;
cart c;
};
now
USER u1=new USER();
access the login,cart or gift as
u1.l , u1.c etc
O-Open Closed Principle
-->This states that the functionality of a particular method shouldnt be changed while trying to specialize your function.
-->open for extension and closed for modification..
Consider a fn returning total
gettotal()---->returns 100.0 a float data type
suppose you need it in the format "$100"(string)
don change the gettotal() method instead create another method decgettotal() which returns the string.
L-Liskov's substitution principle
-->This means that always the derived class object must be substituted for the base class object.
-->Always the derived class methods and the base class method perform the same function.Even overriding is against LSP.
Eg)class point{
int x,y;
func equal(point p)
{
if(p.x==x&&p.y==y)
{
equal
}
else
not equal;
}
};
class cpoint:public point
{
int color;
func equal(point p)
{
if(x==p.x&&y==p.y&&color==p.color)
{equal
}
else
not equal
}
};
main clas/..............
point p=new point(8,9);
point p1=new cpoint(8,9,blue);
p.equals(p1) returns true
but
p1.equals(p) returns false
This violates LSP
SOLUTION:
class point{
int x,y,color=0;
fn equals(point p)
{
if(p.color==0 && color==0)
{
//equal if x and y is equal
}
else
equal ly if color,x,y r eql
}
}
point p=new point(8,9);
I-Interface segregation principle
-->Avoid fat interfaces in a program,-->Dont let a class implement any unwanted interface.
Like if der is a class FEE which has cal_col_fee() and cal_hos_fee() methods.If both day scholars and hostelites r other diffr classes.Dayscholar should implement FEE cos cal_coll_fee() is applicable and shouldnt implement it cos cal_hos_fee() is not applicable.
so split the interface as............
interface cfee
{
cal_col_fee()
{
}
};
interface hfee
{
cal_hos_fee()
{}
};
Now implement both for hostelites and only cfee for Dayscholar class.
D-Dependency Inversion Principle:
This is to make more abstractions than the concretions.
Yeah i know it that line speaks nothing wen u js listen it.Il explain it with an example.
Consider
interface Iworker
{
};
class worker:implements Iworker{
};
class superworker:implements Iworker{
};
class Manager{
worker w;
assign(worker v)
{
w=v
}
};
Manager m1;
now create a worker
worker w1=new worker();
m1.assign(w1) will work fine,but .............
create a superworker
superworker s1=new superworker();
m1.assign(s1) wont work cos inside the manager class we create a worker object.again we have to create a supreworker object inside manager which is nt an efficient coding,violates DIP.
Instead in Manager create Iworker w instead of worker W .
We cannot create an object of interface but we can assign a object to an interface object..
fr instance Iworker iw=new worker(); is correct and Iworker iw=new Iworker() ly s wrong..
Now we have used Iworker which is abstract and is not concrete abt if t s worker or superworker...
NOW DONE WITH THE FEATURES OF design patters..
AUDIO BLOG FOR THE FEATURES: http://soundcloud.com/ronamaria/design-pattterns-i
----------------------------------------------------------------------------------
Dependency Injection:
Il explain this to you in a very simple language.If a child wants some milk he/she will go ask his mother to get it for him rather than taking the strain of fetching the milk from the shop,putting the stove on,boiling it and then having it.Thus the object of "child" invokes the object of class "mother" to call its function.This is an example of dependency injection principle.There may be cases when an object itself shouldnt set its own attribute or invoke its function.
For example if class1's attribute is set by class2 's object.It should be done as follows.
-->create c1 and c2 as instances for class1 and class2 respectively.
-->Inject c1 into c2.
-->Now access c1's attribute using c2.Done
ANTI-PATTERNS!
-->hardcode--
We should NEVER hardcode any value like (if admin=="ros@gmail.com")--->wrong approach
It should always be fetched from the db storage or other sources.
-->Asuumptions:
We should never code assuming that some particular part may not go wrong.For instance consider f=u/getres(6)
What if the fn getres() return 0,-->leads to an error,never do that!
GOD OBJECTS:
In most of the systems a user will be doing most of the actions like loging-in,paying_cash,add_item,get_discount etc,but for that ,matter we shouldnt put it all together into the USER class.It will overload it completely,and will violate the SRP.So the various responsibility of user,cart,rendering must be put in differnt classes and such GOD objects can be avoided.
- Sourcebits University
Cloud Computing
www.sourcebits.com
-->reusable solutions to our problem
-->it's just a hint,though not a complete solution.
-->You can make changes to the template to suit your needs.
-->When over engineered with design patterns your project will explode onto your head.
Your code may still work fine when considering modular pieces of code,but if u dont follow design patterns in its very modular form,i caution you once you integrate it will all come together and BANG your head!!
Actually patterns is not any new concept or architecture or stuff.Its all just what you already use in your real life but you still dont recognise.For instance you can group the options which are related and put it in to a menu format floating at the top of a page--->It forms a pattern
Or..
You can put it in the form of a list on your side bar it is also a pattern usage,It all depends on which environment and circumstance you use it with.
The Five basic principles of Design patterns in OOPS are S.O.L.I.D
S-single responsibility principle
--->It says that the every class should have only 1 responsibility.
--->A single class's responsibility should be encapsulated within that particular class
In general terms it means that related functions shouls be binded..
For instance consider a user classs,...A user can login or buy items or get gift etc,but for that matter you cant put everything together into USER class.This will violate the single responsibility principle.
The solution to this is
class login{
};
class gift{
};
class cart{
};
class user{
login l;
gift.g;
cart c;
};
now
USER u1=new USER();
access the login,cart or gift as
u1.l , u1.c etc
O-Open Closed Principle
-->This states that the functionality of a particular method shouldnt be changed while trying to specialize your function.
-->open for extension and closed for modification..
Consider a fn returning total
gettotal()---->returns 100.0 a float data type
suppose you need it in the format "$100"(string)
don change the gettotal() method instead create another method decgettotal() which returns the string.
L-Liskov's substitution principle
-->This means that always the derived class object must be substituted for the base class object.
-->Always the derived class methods and the base class method perform the same function.Even overriding is against LSP.
Eg)class point{
int x,y;
func equal(point p)
{
if(p.x==x&&p.y==y)
{
equal
}
else
not equal;
}
};
class cpoint:public point
{
int color;
func equal(point p)
{
if(x==p.x&&y==p.y&&color==p.color)
{equal
}
else
not equal
}
};
main clas/..............
point p=new point(8,9);
point p1=new cpoint(8,9,blue);
p.equals(p1) returns true
but
p1.equals(p) returns false
This violates LSP
SOLUTION:
class point{
int x,y,color=0;
fn equals(point p)
{
if(p.color==0 && color==0)
{
//equal if x and y is equal
}
else
equal ly if color,x,y r eql
}
}
point p=new point(8,9);
I-Interface segregation principle
-->Avoid fat interfaces in a program,-->Dont let a class implement any unwanted interface.
Like if der is a class FEE which has cal_col_fee() and cal_hos_fee() methods.If both day scholars and hostelites r other diffr classes.Dayscholar should implement FEE cos cal_coll_fee() is applicable and shouldnt implement it cos cal_hos_fee() is not applicable.
so split the interface as............
interface cfee
{
cal_col_fee()
{
}
};
interface hfee
{
cal_hos_fee()
{}
};
Now implement both for hostelites and only cfee for Dayscholar class.
D-Dependency Inversion Principle:
This is to make more abstractions than the concretions.
Yeah i know it that line speaks nothing wen u js listen it.Il explain it with an example.
Consider
interface Iworker
{
};
class worker:implements Iworker{
};
class superworker:implements Iworker{
};
class Manager{
worker w;
assign(worker v)
{
w=v
}
};
Manager m1;
now create a worker
worker w1=new worker();
m1.assign(w1) will work fine,but .............
create a superworker
superworker s1=new superworker();
m1.assign(s1) wont work cos inside the manager class we create a worker object.again we have to create a supreworker object inside manager which is nt an efficient coding,violates DIP.
Instead in Manager create Iworker w instead of worker W .
We cannot create an object of interface but we can assign a object to an interface object..
fr instance Iworker iw=new worker(); is correct and Iworker iw=new Iworker() ly s wrong..
Now we have used Iworker which is abstract and is not concrete abt if t s worker or superworker...
NOW DONE WITH THE FEATURES OF design patters..
AUDIO BLOG FOR THE FEATURES: http://soundcloud.com/ronamaria/design-pattterns-i
----------------------------------------------------------------------------------
Dependency Injection:
Il explain this to you in a very simple language.If a child wants some milk he/she will go ask his mother to get it for him rather than taking the strain of fetching the milk from the shop,putting the stove on,boiling it and then having it.Thus the object of "child" invokes the object of class "mother" to call its function.This is an example of dependency injection principle.There may be cases when an object itself shouldnt set its own attribute or invoke its function.
For example if class1's attribute is set by class2 's object.It should be done as follows.
-->create c1 and c2 as instances for class1 and class2 respectively.
-->Inject c1 into c2.
-->Now access c1's attribute using c2.Done
ANTI-PATTERNS!
-->hardcode--
We should NEVER hardcode any value like (if admin=="ros@gmail.com")--->wrong approach
It should always be fetched from the db storage or other sources.
-->Asuumptions:
We should never code assuming that some particular part may not go wrong.For instance consider f=u/getres(6)
What if the fn getres() return 0,-->leads to an error,never do that!
GOD OBJECTS:
In most of the systems a user will be doing most of the actions like loging-in,paying_cash,add_item,get_discount etc,but for that ,matter we shouldnt put it all together into the USER class.It will overload it completely,and will violate the SRP.So the various responsibility of user,cart,rendering must be put in differnt classes and such GOD objects can be avoided.
- Sourcebits University
Cloud Computing
www.sourcebits.com
No comments:
Post a Comment