A class should be open for extension but closed for modification. Classes should be designed so they can be inherited from without having to modify them.
The Open Close Principle states that the design and writing of the code should be done in a way that new functionality should be added with minimum changes in the existing code. The design should be done in a way to allow the adding of new functionality as new classes, keeping as much as possible existing code unchanged.
Intent
Software entities like classes, modules and functions should be open for extension but closed for modifications.
If we follow this principle we get lot’s of small and testable
classes. I want to demonstrate this with a simple spam checker for
mails.
Let’s say our mail class has only a sender, a recipient, a subject and the mail body:
public class EMail
{
public string Sender { get; set; }
public string Recipient { get; set; }
public string Subject { get; set; }
public string Body { get; set; }
public EMail(string sender, string recipient,
string subject, string body)
{
Sender = sender;
Recipient = recipient;
Subject = subject;
Body = body;
}
}
public enum SpamResult
{
Spam,
Ok,
Unknown
}
public class RuleChecker
{
public SpamResult CheckMail(EMail mail)
{
var result = TestRule1(mail);
if(result != SpamResult.Unknown)
return result;
result = TestRule2(mail);
if (result != SpamResult.Unknown)
return result;
// …
return SpamResult.Unknown;
}
private SpamResult TestRule1(EMail mail)
{
// I don’t care about the concrete rules
}
private SpamResult TestRule2(EMail mail)
{
// I don’t care about the concrete rules
}
}
With the help of the Open/Closed Principle our implementation could look like this:
public interface ISpamRule
{
SpamResult CheckMail(EMail mail);
}
public class RuleChecker
{
private readonly IEnumerable<ISpamRule> _rules;
public RuleChecker(IEnumerable<ISpamRule> rules)
{
_rules = rules;
}
public SpamResult CheckMail(EMail mail)
{
foreach (var rule in _rules)
{
var result = rule.CheckMail(mail);
if (result != SpamResult.Unknown)
return result;
}
return SpamResult.Unknown;
}
}
You get the your concrete RuleChecker by calling the constructor with a list of rules:
class MyFirstRule : ISpamRule
{
public SpamResult CheckMail(EMail mail)
{
// I don’t care about this
}
}
class MySecondRule : ISpamRule
{
public SpamResult CheckMail(EMail mail)
{
// I don’t care about this
}
}
// …
var ruleChecker =
new RuleChecker(
new List<ISpamRule>
{
new MyFirstRule(),
new MySecondRule(),
// …
});
C# code for the example is presented below:
Another Example
Bellow is an example which violates the Open Close
Principle. It implements a graphic editor which handles the drawing of
different shapes. It's obviously that it does not follow the Open Close
Principle since the GraphicEditor class has to be modified for every new
shape class that has to be added. There are several disadvantages:
- for each new shape added the unit testing of the GraphicEditor should be redone.
- when a new type of shape is added the time for adding it will be high since the developer who add it should understand the logic of the GraphicEditor.
- adding a new shape might affect the existing functionality in an undesired way, even if the new shape works perfectly
In
order to have more dramatic effect, just imagine that the Graphic
Editor is a big class, with a lot of functionality inside, written and
changed by many developers, while the shape might be a class implemented
only by one developer. In this case it would be great improvement to
allow the adding of a new shape without changing the GraphicEditor
class.
// Open-Close Principle - Bad example
class GraphicEditor {
public void drawShape(Shape s) {
if (s.m_type==1)
drawRectangle(s);
else if (s.m_type==2)
drawCircle(s);
}
public void drawCircle(Circle r) {....}
public void drawRectangle(Rectangle r) {....}
}
class Shape {
int m_type;
}
class Rectangle extends Shape {
Rectangle() {
super.m_type=1;
}
}
class Circle extends Shape {
Circle() {
super.m_type=2;
}
}
|
Bellow
is a example which supports the Open Close Principle. In the new design
we use abstract draw() method in GraphicEditor for drawing objects,
while moving the implementation in the concrete shape objects. Using the
Open Close Principle the problems from the previous design are avoided,
because GraphicEditor is not changed when a new shape class is added:
- no unit testing required.
- no need to understand the sourcecode from GraphicEditor.
- since the drawing code is moved to the concrete shape classes, it's a reduced risk to affect old functionallity when new functionallity is added.
// Open-Close Principle - Good example
class GraphicEditor {
public void drawShape(Shape s) {
s.draw();
}
}
class Shape {
abstract void draw();
}
class Rectangle extends Shape {
public void draw() {
// draw the rectangle
}
}
|
Another Example1
Consider another example of a Call_Manager object. The Call_Manager manages a
Call abstract class. The Call_Manager design is open for extension but closed
for modification. Addition of a new call type requires writing a new class that
inherits from Call. No changes are needed in the Call_Manager.
C# code for the example is presented below:
1 using
System;
2 using
System.Collections.Generic;
3 using
System.Text;
4
5 namespace
Open_Closed_Principle
6 {
7
public class
Call_Manager
8 {
9
protected Call[]
_calls;
10
11
// Creates a call. Returns the assigned call_id.
Returns -1 if the call
12
// could not be created.
13
public int
Create_Call(Call call)
14 {
15
int found_call_id = -1;
16
for (int
call_id = 0; call_id < _calls.Length; call_id++)
17
{
18
if (_calls[call_id] ==
null)
19
{
20
found_call_id = call_id;
21
_calls[call_id] = call;
22
_calls[call_id].Handle_Create();
23
break;
24
}
25
}
26
27
return found_call_id;
28 }
29
30
// Deletes the call specified with the call_id.
31
// Returns true if a call is deleted
32
public bool
Delete_Call(int call_Id)
33 {
34
Call found_call =
null;
35
36
if (_calls[call_Id] !=
null)
37
{
38
found_call = _calls[call_Id];
39
found_call.Handle_Delete();
40
_calls[call_Id] = null;
41
}
42
43
return (found_call !=
null);
44 }
45
46
public void
Dump()
47 {
48
foreach (Call
call in _calls)
49
{
50
if (call !=
null)
51
{
52
call.Dump();
53
}
54
}
55 }
56 }
57
58
abstract public
class Call
59 {
60
public abstract
void Handle_Create();
61
public abstract
void Handle_Delete();
62
public abstract
void Dump();
63 }
64
65
public class
ISUP_Call :
Call
66 {
67
public override
void Handle_Create()
68 {
69
// Create an ISUP call
70 }
71
public override
void Handle_Delete()
72 {
73
// Delete an ISUP Call
74 }
75
public override
void Dump()
76 {
77
// Dump the contents on an ISUP call
78 }
79 }
80
81
public class
ISDN_Call :
Call
82 {
83
public override
void Handle_Create()
84 {
85
// Create an ISDN call
86 }
87
public override
void Handle_Delete()
88 {
89
// Delete an ISDN Call
90 }
91
public override
void Dump()
92 {
93
// Dump the contents on an ISDN call
94 }
95 }
96
97
public class
GSM_Call : Call
98 {
99
public override
void Handle_Create()
100 {
101
// Create an GSM call
102 }
103
public override
void Handle_Delete()
104 {
105
// Delete an GSM Call
106 }
107
public override
void Dump()
108 {
109
// Dump the contents on an GSM call
110 }
111 }
112 }
Conclusion
Like
every principle OCP is only a principle. Making a flexible design
involves additional time and effort spent for it and it introduce new
level of abstraction increasing the complexity of the code. So this
principle should be applied in those area which are most likely to be
changed.
There are many design patterns that help us to extend
code without changing it. For instance the Decorator pattern help us to
follow Open Close principle. Also the Factory Method or the Observer
pattern might be used to design an application easy to change with
minimum changes in the existing code.
No comments:
Post a Comment