Interface is one of the mechanism to implement design by contract
Interface illustrate the power of abstraction
1. Decoupled systems i.e clients from server
2. Separate design from implementation
3. No performance penalty
Use
1. PITL (Programming in the large)
Interface between the layers.
2. Polymorphism
You should know about
1. IClonable
2. IComparer defines objects that overrides default sorting process.
3. IComparable defines contract for sorting.
4. IDisposable
Saturday, October 18, 2008
Friday, October 17, 2008
Design Rules for Classes
1. Always
Rule # 1
Classes should always override the ToString() method. Objects should have a way to be represented as strings.
.NET calls the method whenever it needs to display object as string.
Rule # 2
Use constructors to guarantee initialization.
Bad Design
Customer cust = new Customer();
Cust.FirstName = "Sachin";
Cust.LastName = "Surana";
People who want to use Customer object need to be worried about how many fields are there, do I fill them all ? Very error prone way to do things.
Good Design
Force to supply values.
Customer cust = new Customer("Sachin", "Surana");
Rule # 3
In case of overloading, have one central contructor or central method. The other methods call the central method.
Rule # 4
If a class has static fields, guarantee initialization using static constructors.
Rule # 5
Declare constants as read-only fields.
i. It helps to define constant without embedding it within clients.
ii. You can initialise it using run-time constructor.
public class Globals {
public static readonly string AppHomeDir
Rule # 6
Use enum to define a set of related constants.
2. Consider
Rule # 7
All fileds should be private. Consider hiding data from unwarranted access. If access is needed, provide using properties.
Rule # 8
Consider overriding Equals(object obj)
.NET calls this method when searching.
Rule # 9
If override Equals, also override GetHashCode
1. Used internally by hashing algorithms.
2. If two objects are Equal, GHS they must return same value.
3. Define GHC in terms of same fields as Equals.
Rule # 10
Define Dispose() if your objects need cleanup.
Rule # 11
If class needs Dispose(), you should also need finalizer.
Rule # 12
Consider supplying a method for cloning objects. Use IClonable interface.
Since it is confusing if Clone uses shallow or deep copy, IClonable is deprecated.
3. Best Practices
Rule # 13
Throw exceptions. Do not return integer error code or bool.
Rule # 1
Classes should always override the ToString() method. Objects should have a way to be represented as strings.
.NET calls the method whenever it needs to display object as string.
Rule # 2
Use constructors to guarantee initialization.
Bad Design
Customer cust = new Customer();
Cust.FirstName = "Sachin";
Cust.LastName = "Surana";
People who want to use Customer object need to be worried about how many fields are there, do I fill them all ? Very error prone way to do things.
Good Design
Force to supply values.
Customer cust = new Customer("Sachin", "Surana");
Rule # 3
In case of overloading, have one central contructor or central method. The other methods call the central method.
Rule # 4
If a class has static fields, guarantee initialization using static constructors.
Rule # 5
Declare constants as read-only fields.
i. It helps to define constant without embedding it within clients.
ii. You can initialise it using run-time constructor.
public class Globals {
public static readonly string AppHomeDir
Rule # 6
Use enum to define a set of related constants.
2. Consider
Rule # 7
All fileds should be private. Consider hiding data from unwarranted access. If access is needed, provide using properties.
Rule # 8
Consider overriding Equals(object obj)
.NET calls this method when searching.
Rule # 9
If override Equals, also override GetHashCode
1. Used internally by hashing algorithms.
2. If two objects are Equal, GHS they must return same value.
3. Define GHC in terms of same fields as Equals.
Rule # 10
Define Dispose() if your objects need cleanup.
Rule # 11
If class needs Dispose(), you should also need finalizer.
Rule # 12
Consider supplying a method for cloning objects. Use IClonable interface.
public class Customer : IClonable{
public object Clone(){
return new Customer("Sachin", "Surana");
}
}
Which is equivalent to
public class Customer : IClonable{
public object Clone(){
return this.MemberwiseClone(); // Creates a shallow copy
}
}
Since it is confusing if Clone uses shallow or deep copy, IClonable is deprecated.
public class Customer {
public Customer ShallowCopy()..
public Customer DeepCopy()...
}
3. Best Practices
Rule # 13
Throw exceptions. Do not return integer error code or bool.
Command Pattern - Encapsulate method invocation
The command pattern allows you to decouple the requester of an action (i.e. the object which wants to invoke the method) from the object that actually performs the action. A command object encapsulates a request to do something on a specific object.
Or in other words, objects are used to represent actions. A command object encapsulates an action and its parameters.
There are two objects involved : Invoker and Receiver
In the example above, the invoker and receiver are not decoupled. The invoker knows about the receiver.
Invoker -> Receiver
Now if we want to decouple the invoker and receiver, an option is to let invoker know only about command objects.
Invoker -> Command -> Receiver
So command pattern gives us a way tp package a piece of computation (receiver and a set of actions) and pass it as a first class objects.
But an important question is still unanswered. Who creates object of concrete command and calls the SetCommand of Invoker object ? Well... it is the client which does that.
Uses of command pattern
1. Implementing thread pools and job schedulers.
2. Macro commands
3. Logging requests
Or in other words, objects are used to represent actions. A command object encapsulates an action and its parameters.
There are two objects involved : Invoker and Receiver
class Invoker{
Receiver receiver = null;
void Invoker(Receiver receiver){
this.receiver = receiver;
}
void Method(){
receiver.M1();
}
}
class Receiver{
void M1()
}
In the example above, the invoker and receiver are not decoupled. The invoker knows about the receiver.
Invoker -> Receiver
Now if we want to decouple the invoker and receiver, an option is to let invoker know only about command objects.
Invoker -> Command -> Receiver
public interface Command{
void Execute()
}
public interface ConcreteCommand : Command{
Receiver receiver = null;
public ConcreteCommand(Receiver rcv){
receiver = rcv
}
public void Execute(){
rcv.M1()
}
}
class Invoker{
void Method(){
cmd.Execute();
}
void SetCommand(Command cmd){
}
}
So command pattern gives us a way tp package a piece of computation (receiver and a set of actions) and pass it as a first class objects.
But an important question is still unanswered. Who creates object of concrete command and calls the SetCommand of Invoker object ? Well... it is the client which does that.
Uses of command pattern
1. Implementing thread pools and job schedulers.
2. Macro commands
3. Logging requests
Saturday, September 20, 2008
Coupling and cohesion
1. Keep things that have to change together as close together in the code as possible.
2. Allow unrelated things in the code to change independently (also known as orthogonality).
3. Minimize duplication in the code.
One should always aim at increasing cohesion and decreasing coupling.
Decreasing coupling
Coupling among classes or subsystems is a measure of how interconnected those classes or subsystems are. Tight coupling means that related classes have to know internal details of each other, changes ripple through the system, and the system is potentially harder to understand.
The goals behind achieving loose coupling between classes and modules are to:
1. Make the code easier to read.
2. Make our classes easier to consume by other developers by hiding the ugly inner workings of our classes behind well-designed APIs.
3. Isolate potential changes to a small area of code.
4. Reuse classes in completely new contexts.
Ways to achieve loose coupling
1. Eliminate Inappropriate Intimacy.
Inappropriate intimacy refers to a method in a class that has too much intimate knowledge of another class. Inappropriate intimacy is a sign of harmful, tight coupling between classes.
2. Law of Demeter
Only talk to your immediate friends. An easy way to detect violation of this law is to see if you are calling a method on property of another object i.e. obj.Property.Method1()
The Law of Demeter is a powerful tool to help you spot potential coupling problems, but don't follow the Law of Demeter blindly. Violating the Law of Demeter does add tighter coupling to your system, but in some cases you may judge that the potential cost of coupling to a stable element of your code is less expensive than writing a lot of delegation code to eliminate the Law of Demeter violations.
Increasing cohesion
It is a measure of how closely related all the responsibilities, data, and methods of a class are to each other.
1. Implementing SRP would help achieve cohesion.
2. Tell, Don't ask
The Tell, Don't Ask design principle urges you to tell objects what to do. What you don't want to do is ask an object about its internal state, make some decisions about that state, then tell that object what to do. Following the Tell, Don't Ask style of object interaction is a good way to ensure that responsibilities are put in the right places.
3. Information Expert Pattern
If you have a new responsibility for your system, in what class should the new responsibility go? The Information Expert pattern asks, who knows the information necessary to fulfill this responsibility? In other words, your first candidate for any new responsibility is the class that already has the data fields affected by that responsibility.
4. Say it Once and Only Once
One of the best ways to improve cohesion in your system is to eliminate duplication wherever you spot it. It's probably best if you assume that you don't know exactly how your system is going to change in the future, but you can improve your code's ability to accept change by maintaining good cohesion and coupling in class structures. One of the best ways to improve the cohesion quality of your codebase is to simply pull out duplication into separate classes that can be shared across the codebase.
2. Allow unrelated things in the code to change independently (also known as orthogonality).
3. Minimize duplication in the code.
One should always aim at increasing cohesion and decreasing coupling.
Decreasing coupling
Coupling among classes or subsystems is a measure of how interconnected those classes or subsystems are. Tight coupling means that related classes have to know internal details of each other, changes ripple through the system, and the system is potentially harder to understand.
The goals behind achieving loose coupling between classes and modules are to:
1. Make the code easier to read.
2. Make our classes easier to consume by other developers by hiding the ugly inner workings of our classes behind well-designed APIs.
3. Isolate potential changes to a small area of code.
4. Reuse classes in completely new contexts.
Ways to achieve loose coupling
1. Eliminate Inappropriate Intimacy.
Inappropriate intimacy refers to a method in a class that has too much intimate knowledge of another class. Inappropriate intimacy is a sign of harmful, tight coupling between classes.
2. Law of Demeter
Only talk to your immediate friends. An easy way to detect violation of this law is to see if you are calling a method on property of another object i.e. obj.Property.Method1()
The Law of Demeter is a powerful tool to help you spot potential coupling problems, but don't follow the Law of Demeter blindly. Violating the Law of Demeter does add tighter coupling to your system, but in some cases you may judge that the potential cost of coupling to a stable element of your code is less expensive than writing a lot of delegation code to eliminate the Law of Demeter violations.
Increasing cohesion
It is a measure of how closely related all the responsibilities, data, and methods of a class are to each other.
1. Implementing SRP would help achieve cohesion.
2. Tell, Don't ask
The Tell, Don't Ask design principle urges you to tell objects what to do. What you don't want to do is ask an object about its internal state, make some decisions about that state, then tell that object what to do. Following the Tell, Don't Ask style of object interaction is a good way to ensure that responsibilities are put in the right places.
3. Information Expert Pattern
If you have a new responsibility for your system, in what class should the new responsibility go? The Information Expert pattern asks, who knows the information necessary to fulfill this responsibility? In other words, your first candidate for any new responsibility is the class that already has the data fields affected by that responsibility.
4. Say it Once and Only Once
One of the best ways to improve cohesion in your system is to eliminate duplication wherever you spot it. It's probably best if you assume that you don't know exactly how your system is going to change in the future, but you can improve your code's ability to accept change by maintaining good cohesion and coupling in class structures. One of the best ways to improve the cohesion quality of your codebase is to simply pull out duplication into separate classes that can be shared across the codebase.
Saturday, July 5, 2008
Why is Inheritance evil ?
"Favor composition over inheritance"...this is one of the principles suggested in one of the very popular books on design patterns. I have been thinking a lot about it and lets see with an example what are the problems that arise because of 'incorrect or overuse' of inheritance.
Rather than just taking the principle blindly, I would try to analyze why does the book say so
Rather than just taking the principle blindly, I would try to analyze why does the book say so
Friday, June 27, 2008
Design Principle : Dependency Inversion Principle
Depend upon abstractions. Do not depend upon concrete classes.
Before delving deeper into the principle we should understand
a. What is a dependency ?
b. What is it trying to invert ? And to understand this we should understand what happens in the normal case which the principle says should be inverted ?
What is dependency ?
When a class refers another class, it is said to be dependent on the other class. Consider the following example,
The class B has a member variable of class A and so it is dependent on A. The dependency can be set either using constructor or setter methods.
What is the 'un-inverted' way ?
An application has high level classes and low level classes. The low level classes would implement the basic functionality and the high level classes would implement complex logic and in turn use the low level classes. A natural way of implementing such structures would be to write low level classes and once we have them to write the complex high level classes. Since the high level classes are defined in terms of others this seems the logical way to do it.
High Level Module --> Low Level Module
Besides, as mentioned by Martin Folwer in his article he has used the word inversion because...
more traditional software development methods, such as Structured Analysis and Design, tend to create software structures in which high level modules depend upon low level modules, and in which abstractions depend upon details. Indeed one of the goals of these methods is to define the subprogram hierarchy that describes how the high level modules make calls to the low level modules. Thus, the dependency structure of a well designed object oriented program is “inverted” with respect to the dependency structure that normally results from traditional procedural methods.
What is DIP ?
2. Its the high level modules which have business logic. Yet,when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change. But it should be high level modules that ought to be forcing the low level modules to change.
Advantages of DIP
According to Booch, “...all well structured object-oriented architectures have clearly-defined layers, with each layer providing some coherent set of services though a well-defined and controlled interface.”
Before delving deeper into the principle we should understand
a. What is a dependency ?
b. What is it trying to invert ? And to understand this we should understand what happens in the normal case which the principle says should be inverted ?
What is dependency ?
When a class refers another class, it is said to be dependent on the other class. Consider the following example,
Class A{
}
class B{
A obj;
}
The class B has a member variable of class A and so it is dependent on A. The dependency can be set either using constructor or setter methods.
What is the 'un-inverted' way ?
An application has high level classes and low level classes. The low level classes would implement the basic functionality and the high level classes would implement complex logic and in turn use the low level classes. A natural way of implementing such structures would be to write low level classes and once we have them to write the complex high level classes. Since the high level classes are defined in terms of others this seems the logical way to do it.
High Level Module --> Low Level Module
Besides, as mentioned by Martin Folwer in his article he has used the word inversion because...
more traditional software development methods, such as Structured Analysis and Design, tend to create software structures in which high level modules depend upon low level modules, and in which abstractions depend upon details. Indeed one of the goals of these methods is to define the subprogram hierarchy that describes how the high level modules make calls to the low level modules. Thus, the dependency structure of a well designed object oriented program is “inverted” with respect to the dependency structure that normally results from traditional procedural methods.
What is DIP ?
- High-level modules should not depend on low-level modules. Both should depend on abstractions.
- Abstractions should not depend on details. Details should depend on abstractions.
According to this principle the way of designing a class structure is to start from high level modules to the low level modules:
High Level Classes --> Abstraction Layer --> Low Level
But why ?
2. Its the high level modules which have business logic. Yet,when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change. But it should be high level modules that ought to be forcing the low level modules to change.
Advantages of DIP
1. The use of DIP makes the high level modules reusable as they are not directly dependent on low level details/modules. It helps in creation of reusable frameworks.
2. It helps in creation of code that is resilient to change. And, since the abstractions and details are all isolated from each other, the code is much easier to maintain.
Layering and DIPAccording to Booch, “...all well structured object-oriented architectures have clearly-defined layers, with each layer providing some coherent set of services though a well-defined and controlled interface.”
For example, lets consider the three layers A->B->C. In this case the layer A is sensitive to all the changes down in layer C. Dependency is transitive.
Using DIP, A->IB->BImpl->IC->CImpl
Here, each of the lower layers are represented by an abstract class. Each of the higher level classes uses the next lowest layer through the abstract interface. Thus, none of the layers
depends upon any of the other layers. Instead, the layers depend upon abstract classes. Not only is the transitive dependency of A Layer upon C Layer broken, but even the direct dependency of A Layer upon B Layer broken.
The point is to exploit polymorphism by programming to a supertype so that the actual runtime object is not locked into the code. And the supertype can be an interface or an abstract class.
Guidelines (Not rules !!!)
1. No variable should hold a reference to a concrete class. (If you use new, you would hold reference to a concrete class. Use factory to get that around.)
2. No class should derive from a concrete class.
3. No method should override an implementation method of any of its base classes.
Saturday, June 14, 2008
Encapsulation - a big chunk of the PIE
Most of the programmers would respond saying...Encapsulation is about making variables private and exposing them using public properties or methods i.e. you have put the variables in a capsule !!!
This is indeed true but there is something more to encapsulation. If we go by this definition we have capsuled the properties.
The things that can be encapsulated are
1. Private Data
2. Public properties !!!
3. Behavior !!!
2 and 3 would be something new to people familiar with the classic definition of encapsulation. So encapsulation is not just about keeping data in your classes separate from rest of your application it is also about grouping your application into logical parts i.e. protect information in one part of your application from other parts. It is also known as information hiding (and now you know this information is not just data) or separation of concerns.
Why to encapsulate ?
When you break the behavior or properties out from a class, you can change the behavior without changing the class. So by breaking up the different parts of your application, you can change one part without having to change all the other parts. So encapsulation makes your code easier to change and leads to a flexible software.
When to encapsulate ?
1. Anytime you see duplicate code, look for a place to encapsulate.
2. Encapsulate what varies.
How to encapsulate ?
Take the portions that you want to move out from a class and move them into a new class and you have achieved encapsulation. So one way of encapsulating is by creating classes.
Now lets talk about encapsulating properties and behavior.
Encapsulating properties (group of properties)
Lets assume you have the following two classes
1. Book
-Name
-Author
-SerialNumber
-Price
2. BookStore
-Book[] Search(Book)
-AddBook(Book)
The Search method takes Book parameter for searching the books. The Book parameter is used to hold the search specification by user i.e Name and Author. The user can't specify SerialNumber and Price and hence they would be null when passed to Search.
Something is wrong !!! The Book object does not seem to represent a single concept, it is representing both the Book entity and search specification. So time to create a new a new class BookSpec which has Name and Author as properties.
1. Book
-Name
-Author
-SerialNumber
-Price
2. BookStore
-Book[] Search(BookSpec)
-AddBook(Book)
3. BookSpec
-Name
-Author
Still something that can be impoved...duplicate code. The Name and Author are same in both BookSpec and Book. So lets move Name and Author out of Book and instead let it refer BookSpec.
1. Book
-BookSpec
-SerialNumber
-Price
2. BookStore
-Book[] Search(BookSpec)
-AddBook(Book)
3. BookSpec
-Name
-Author
So you have encapsulated a group of properties from Book class into BookSpec class. So would you still say encapsulation is just about private properties :)
Infact, we have also touched upon an interesting pattern called the Specification pattern which we would be discussing in a separate post. You can refer to Martin Fowler's article but it would need a lot of patience ;)
Encapsulating behavior
Say we have a Car class..
Car
-Start()
-Stop()
-Drive()
Anything wrong !!! Do you think that car drives itself ? Isn't it the driver who would driver the Car ?
So lets create two classes
Car
-Start()
-Stop()
Driver
-Drive(Car)
Though not a very good example, still I think we have seen how behavior can be encapsulated in a new class.
Let me know if the post was helpful !!!
Why did the title say that encapsulation is the big chunk of the PIE (Polymorphism, Inheritence and Encapsulation). Don't you think that Inheritence and Polymorphism are specialised forms of encapsulation ? Ah....forget it if it confused you.
This is indeed true but there is something more to encapsulation. If we go by this definition we have capsuled the properties.
The things that can be encapsulated are
1. Private Data
2. Public properties !!!
3. Behavior !!!
2 and 3 would be something new to people familiar with the classic definition of encapsulation. So encapsulation is not just about keeping data in your classes separate from rest of your application it is also about grouping your application into logical parts i.e. protect information in one part of your application from other parts. It is also known as information hiding (and now you know this information is not just data) or separation of concerns.
Why to encapsulate ?
When you break the behavior or properties out from a class, you can change the behavior without changing the class. So by breaking up the different parts of your application, you can change one part without having to change all the other parts. So encapsulation makes your code easier to change and leads to a flexible software.
When to encapsulate ?
1. Anytime you see duplicate code, look for a place to encapsulate.
2. Encapsulate what varies.
How to encapsulate ?
Take the portions that you want to move out from a class and move them into a new class and you have achieved encapsulation. So one way of encapsulating is by creating classes.
Now lets talk about encapsulating properties and behavior.
Encapsulating properties (group of properties)
Lets assume you have the following two classes
1. Book
-Name
-Author
-SerialNumber
-Price
2. BookStore
-Book[] Search(Book)
-AddBook(Book)
The Search method takes Book parameter for searching the books. The Book parameter is used to hold the search specification by user i.e Name and Author. The user can't specify SerialNumber and Price and hence they would be null when passed to Search.
Something is wrong !!! The Book object does not seem to represent a single concept, it is representing both the Book entity and search specification. So time to create a new a new class BookSpec which has Name and Author as properties.
1. Book
-Name
-Author
-SerialNumber
-Price
2. BookStore
-Book[] Search(BookSpec)
-AddBook(Book)
3. BookSpec
-Name
-Author
Still something that can be impoved...duplicate code. The Name and Author are same in both BookSpec and Book. So lets move Name and Author out of Book and instead let it refer BookSpec.
1. Book
-BookSpec
-SerialNumber
-Price
2. BookStore
-Book[] Search(BookSpec)
-AddBook(Book)
3. BookSpec
-Name
-Author
So you have encapsulated a group of properties from Book class into BookSpec class. So would you still say encapsulation is just about private properties :)
Infact, we have also touched upon an interesting pattern called the Specification pattern which we would be discussing in a separate post. You can refer to Martin Fowler's article but it would need a lot of patience ;)
Encapsulating behavior
Say we have a Car class..
Car
-Start()
-Stop()
-Drive()
Anything wrong !!! Do you think that car drives itself ? Isn't it the driver who would driver the Car ?
So lets create two classes
Car
-Start()
-Stop()
Driver
-Drive(Car)
Though not a very good example, still I think we have seen how behavior can be encapsulated in a new class.
Let me know if the post was helpful !!!
Why did the title say that encapsulation is the big chunk of the PIE (Polymorphism, Inheritence and Encapsulation). Don't you think that Inheritence and Polymorphism are specialised forms of encapsulation ? Ah....forget it if it confused you.
Single Responsibility Principle, Don't repeat yourself
A pretty straight forward principle but at the same time difficult to detect its violations.
A few definitions...
1. Each object is interested in doing its job, and only its job.
2. Every object in your system should have a single responsibility and all the object's services should be focussed on carrying out that responsibility.
3. A class should have only one reason to change.
4. Cohesion is another name for SRP. If you are writing highly cohesive software, then that means you are correctly applying SRP.
How to detect SRP violations ?
1. Objects should do what their names indicate.
2. Each object should represent a single concept.
3. Unused properties are a dead giveaway. If you have an object that is being used with null prperties most often, then you probably have an object doing more than one job. Why is the property there in the first place ?
Would suggest reading through the article at objectmentor.com
A some what related principle is DRY (Don't repeat yourself). It says 'Avoid duplicate code by abstracting out things that are common and placing those things in a single location.' Duplicate code would always lead to maintenance nightmares !!!
DRY is about having each piece of information and behavior in your system in a single place. It is also called as Say it once and Only once.
Q. How does removing code duplication help in improving cohesion ?
One of the best ways to improve cohesion in your system is to eliminate duplication wherever you spot it. It's probably best if you assume that you don't know exactly how your system is going to change in the future, but you can improve your code's ability to accept change by maintaining good cohesion and coupling in class structures. One of the best ways to improve the cohesion quality of your codebase is to simply pull out duplication into separate classes that can be shared across the codebase.
A few definitions...
1. Each object is interested in doing its job, and only its job.
2. Every object in your system should have a single responsibility and all the object's services should be focussed on carrying out that responsibility.
3. A class should have only one reason to change.
4. Cohesion is another name for SRP. If you are writing highly cohesive software, then that means you are correctly applying SRP.
How to detect SRP violations ?
1. Objects should do what their names indicate.
2. Each object should represent a single concept.
3. Unused properties are a dead giveaway. If you have an object that is being used with null prperties most often, then you probably have an object doing more than one job. Why is the property there in the first place ?
Would suggest reading through the article at objectmentor.com
A some what related principle is DRY (Don't repeat yourself). It says 'Avoid duplicate code by abstracting out things that are common and placing those things in a single location.' Duplicate code would always lead to maintenance nightmares !!!
DRY is about having each piece of information and behavior in your system in a single place. It is also called as Say it once and Only once.
Q. How does removing code duplication help in improving cohesion ?
One of the best ways to improve cohesion in your system is to eliminate duplication wherever you spot it. It's probably best if you assume that you don't know exactly how your system is going to change in the future, but you can improve your code's ability to accept change by maintaining good cohesion and coupling in class structures. One of the best ways to improve the cohesion quality of your codebase is to simply pull out duplication into separate classes that can be shared across the codebase.
Sunday, June 1, 2008
Delegation - Simple yet powerful concept
What is delegation and why is it powerful ?
Delegation is very simple to understand. Thats what all the team leads and track leads do every time, isn't it ? Don't work on your own but delegate it to the team members :)
In object oriented programming, delegation is used to describe a situation where one object defers task to another object, known as delegate.
Any object of class B will delegate execution of function Foo to object of class A.
But is that a big deal ? There would be many classes in my system and they would use each other.
1. So is every call made by an object to another object is delegation ?
2. And why is so powerful ?
For 1, I would say Yes. If an object calls a method of another object it is delegation.
For 2, lets rewrite the above example as
Now, one can change the behavior of objects of class B without having to change the code of class B itself, by deriving new delegates from A and that makes it powerful. (Obviously it makes of dynamic binding in that case.)
One of the task that an object should always delegate is checking for equality of other objects.
Lets assume that two instance of A would be considered equal if they have the same name, then one of the ways to check for equality is as below
But this is not a good idea as any change in class A might lead to a change in the class where this piece of code is written. The other better option is to delegate it to class A as
All said and done, delegation helps
1. Your application stay loosely coupled. That means your objects are independent of each other i.e. changes in one object don't require you to make changes to other objects. Delegation shields your objects from implementation changes to other objects in your software.
2. It makes your code reusable. It lets each object worry about its own task. This means your objects are more independent of each other i.e. loosely coupled. And looslely coupled objects can be taken from one application and easily be reused in other as they are not tightly tied to the other object's code.
Another question that comes to my mind...is delegation always achieved through composition ?
Also, when you would compile class A above, you would get a warning
'ConsoleApplication1.A' overrides Object.Equals(object o) but does not override Object.GetHashCode(). Leaving that for self study :)
Delegation is very simple to understand. Thats what all the team leads and track leads do every time, isn't it ? Don't work on your own but delegate it to the team members :)
In object oriented programming, delegation is used to describe a situation where one object defers task to another object, known as delegate.
class A {
public virtual void Foo() {
Console.Write("Object A doing the job.");
}
}
class B {
A obj = new A();
public virtual void Foo(){
obj.Foo();
}
}
Any object of class B will delegate execution of function Foo to object of class A.
But is that a big deal ? There would be many classes in my system and they would use each other.
1. So is every call made by an object to another object is delegation ?
2. And why is so powerful ?
For 1, I would say Yes. If an object calls a method of another object it is delegation.
For 2, lets rewrite the above example as
class A {
public virtual void Foo() {
Console.Write("Object A doing the job.");
}
}
class B{
A obj = null;
public B(A a){
obj = a;
}
public virtual void Foo(){
obj.Foo();
}
}
A obj = new A();
B obj2 = new B(obj);
obj.Foo();
Now, one can change the behavior of objects of class B without having to change the code of class B itself, by deriving new delegates from A and that makes it powerful. (Obviously it makes of dynamic binding in that case.)
One of the task that an object should always delegate is checking for equality of other objects.
class A {
private String name;
public A(String name){
this.name = name;
}
public String Name{
get{
return this.name;
}
}
public override bool Equals(object obj){
A obj1 = obj as A;
if (obj1 == null){
return false;
}
return String.Equals(obj1.name, this.name);
}
}
Lets assume that two instance of A would be considered equal if they have the same name, then one of the ways to check for equality is as below
A obj1 = new A("test");
A obj2 = new A("test1");
if (obj1.Name == obj2.Name){
}
But this is not a good idea as any change in class A might lead to a change in the class where this piece of code is written. The other better option is to delegate it to class A as
if (obj2.Equals(obj1)){
}
All said and done, delegation helps
1. Your application stay loosely coupled. That means your objects are independent of each other i.e. changes in one object don't require you to make changes to other objects. Delegation shields your objects from implementation changes to other objects in your software.
2. It makes your code reusable. It lets each object worry about its own task. This means your objects are more independent of each other i.e. loosely coupled. And looslely coupled objects can be taken from one application and easily be reused in other as they are not tightly tied to the other object's code.
Another question that comes to my mind...is delegation always achieved through composition ?
Also, when you would compile class A above, you would get a warning
'ConsoleApplication1.A' overrides Object.Equals(object o) but does not override Object.GetHashCode(). Leaving that for self study :)
Saturday, May 24, 2008
Dispatch - Single, Multiple and Dynamic
Well, starting with a simple topic about dispatch. Though a simple one, if you search on the net about single dispatch or dynamic dispatch, it can confusing.
Lets start with understanding what is "dispatch". To put it simply, dispatch is about deciding which method to call.
1. Static Dispatch
If it can be decided at compile time which method is to be called, it is referred to as static dispath. The advantage of static dispatch is that the code gets generated at compile time, and the "wiring" of the function calls and value invocations are determined at compile time -- or even before the program is run.
2. Dynamic Dispatch
If the decision about which method to invoke can be made only at runtime it is called as dynamic dispatch. Dynamic dispatch is needed when multiple classes contain different implementations of the same method foo(). If the class of an object x is not known at compile-time, then when x.foo() is called, the program must decide at runtime which implementation of foo() to invoke, based on the runtime type of object x. Overriding in C# is example of dynamic dispatch.
2.1 Single Dispatch
C# or C++ are single dispatch languages since the decision about which method to call is made on the basis of only one parameter or argument of the function i.e. the implicit this parameter. So, which method gets called is decided by the type of the "object".
2.2 Multiple Dispatch
There are a few languages where functions can also be dynamically dispatched based on the type of arguments. This is known as multiple dispatch.
2.2.1 Why is multiple dispatch needed ?
Virtual functions allow polymorphism on a single argument but at times there is a need for multi-argument polymorphism. One of the solution is double dispatch but it does not lend easily extensible code. The other possible solutions can be found at http://www.eptacom.net/pubblicazioni/pub_eng/mdisp.html
2.2.1.1 Example 1
The problem here is that Intersect() method cannot be implemented for a generic shape object.
It maybe tempting to use an if/else sequence based on the dynamic type of the argument
But this in unsatisfactory as you have to update the Intersect method of each class
derived from Shape every time a new class is derived. The need for multiple
polymorphism the need for multiple polymorphism arises naturally in several real-world problems. In general, the selection of the most efficient algorithm may depend on the type of more than one parameter.
Basically, double dispatch uses two calls to resolve on the type of both arguments.
but in C# it does not come without problems. The base class Shape must know about
all the derived classes, resulting in circular dependencies. If you derive a new class from Shape (say Triangle), you must update the interface of Shape and the interface/implementation of all the other derived classes.
2.2.1.2 Example 2
What gets printed ? ..."Asteroid hit a SpaceShip", which is incorrect.
Now, if both SpaceShip and GiantSpaceShip had a method CollideWith, the previous lines would still not work but the following would work.
Lets start with understanding what is "dispatch". To put it simply, dispatch is about deciding which method to call.
1. Static Dispatch
If it can be decided at compile time which method is to be called, it is referred to as static dispath. The advantage of static dispatch is that the code gets generated at compile time, and the "wiring" of the function calls and value invocations are determined at compile time -- or even before the program is run.
2. Dynamic Dispatch
If the decision about which method to invoke can be made only at runtime it is called as dynamic dispatch. Dynamic dispatch is needed when multiple classes contain different implementations of the same method foo(). If the class of an object x is not known at compile-time, then when x.foo() is called, the program must decide at runtime which implementation of foo() to invoke, based on the runtime type of object x. Overriding in C# is example of dynamic dispatch.
2.1 Single Dispatch
C# or C++ are single dispatch languages since the decision about which method to call is made on the basis of only one parameter or argument of the function i.e. the implicit this parameter. So, which method gets called is decided by the type of the "object".
2.2 Multiple Dispatch
There are a few languages where functions can also be dynamically dispatched based on the type of arguments. This is known as multiple dispatch.
2.2.1 Why is multiple dispatch needed ?
Virtual functions allow polymorphism on a single argument but at times there is a need for multi-argument polymorphism. One of the solution is double dispatch but it does not lend easily extensible code. The other possible solutions can be found at http://www.eptacom.net/pubblicazioni/pub_eng/mdisp.html
2.2.1.1 Example 1
abstract class Shape{
public abstract double Intersect (Shape s);
}
class Circle : Shape{
public override double Intersect (Shape s){
}
}
class Rectangle : Shape{
public override double Intersect (Shape s){
}
}
The problem here is that Intersect() method cannot be implemented for a generic shape object.
It maybe tempting to use an if/else sequence based on the dynamic type of the argument
class Circle : Shape{
public override double Intersect (Shape s){
if(s is Circle){
}
else if (s is Rectangle){
}
}
}
But this in unsatisfactory as you have to update the Intersect method of each class
derived from Shape every time a new class is derived. The need for multiple
polymorphism the need for multiple polymorphism arises naturally in several real-world problems. In general, the selection of the most efficient algorithm may depend on the type of more than one parameter.
abstract class Shape{
public abstract double Intersect(Shape s);
public abstract double Intersect(Circle s);
public abstract double Intersect(Rectangle s);
}
class Circle : Shape{
public override double Intersect(Shape s){
return s.Intersect(this);
}
public override double Intersect(Circle s){
return 1.0;
}
public override double Intersect(Rectangle s){
return 1.0;
}
}
class Rectangle : Shape{
public override double Intersect(Shape s){
return s.Intersect(this);
}
public override double Intersect(Circle s){
return 1.0;
}
public override double Intersect(Rectangle s){
return 1.0;
}
}
Basically, double dispatch uses two calls to resolve on the type of both arguments.
but in C# it does not come without problems. The base class Shape must know about
all the derived classes, resulting in circular dependencies. If you derive a new class from Shape (say Triangle), you must update the interface of Shape and the interface/implementation of all the other derived classes.
2.2.1.2 Example 2
class SpaceShip{
}
class GiantSpaceShip : SpaceShip{
}
class Asteroid{
public virtual void CollideWith(SpaceShip s){
Console.WriteLine("Asteroid hit a SpaceShip");
}
public virtual void CollideWith(GiantSpaceShip s){
Console.WriteLine("Asteroid hit a GiantSpaceShip");
}
}
class ExplodingAsteroid : Asteroid{
public override void CollideWith(SpaceShip s){
Console.WriteLine("ExplodingAsteroid hit a SpaceShip");
}
public override void CollideWith(GiantSpaceShip s){
Console.WriteLine("ExplodingAsteroid hit a GiantSpaceShip");
}
}
Asteroid theAsteroid = new Asteroid();
SpaceShip theSpaceShip = new SpaceShip();
GiantSpaceShip theGiantSpaceShip = new GiantSpaceShip();
ExplodingAsteroid theExplodingAsteroid = new ExplodingAsteroid();
SpaceShip temp = theGiantSpaceShip;
theAsteroid.CollideWith(temp);
What gets printed ? ..."Asteroid hit a SpaceShip", which is incorrect.
Now, if both SpaceShip and GiantSpaceShip had a method CollideWith, the previous lines would still not work but the following would work.
temp.CollideWith(theAsteroid);
temp.CollideWith(theExplodingAsteroid);
temp.CollideWith(theExplodingAsteroid);
class SpaceShip{
public virtual void CollideWith(Asteroid asteroid){
asteroid.CollideWith(this);
}
}
class GiantSpaceShip : SpaceShip{
public override void CollideWith(Asteroid asteroid){
asteroid.CollideWith(this);
}
}
Subscribe to:
Posts (Atom)