The document discusses object-oriented programming (OOP) principles including the single responsibility principle (SRP), open/closed principle (OCP), Liskov substitution principle (LSP), interface segregation principle (ISP), and dependency inversion principle (DIP). It provides examples of applying each principle and defines them as: SRP - a class should have one reason to change; OCP - entities should be open for extension but closed for modification; LSP - derived classes must be substitutable for their base classes; ISP - clients shouldn't implement unused interfaces; DIP - high-level modules shouldn't depend on low-level modules but abstract interfaces. The document also reviews OOP concepts in C# code.

1. Learning Session’s
Object Oriented Life
VIVEK.P.S

2. Welcome and Introduction
 The subject of the session.
 The overall goals of the session.

3. Overview
 Overview of the OOP’S.
 Why this is important for you.
 Class design principles
 C# and OOP’s

4. Vocabulary
 SRP: Single Responsibility Principle.
 OCP: Open/Closed Principle.
 LSP: Liskov Substitution Principle.
 ISP: Interface Segregation Principle.
 DIP: Dependency Inversion Principle.

5. Single Responsibility Principle

6. Single Responsibility Principle
 A responsibility is considered to be one
reason to change a class.
 if we have 2 reasons to change for a
class, we have to split the functionality
in two classes.
 A class should have only one reason to
change.

7. Single Responsibility Principle
 bad example-Protocol,Content change
interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(String content);
}
class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(String content) {// set content; }
}

8. Single Responsibility Principle
 good example
interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(IContent content);
}
interface Content {
public String getAsString(); // used for serialization
}
class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(IContent content) {// set content; }
}

9. Single Responsibility Principle
 A new interface and class called
IContent and Content to split the
responsibilities.
 Adding a new protocol causes changes
only in the Email class.
 Adding a new type of content
supported causes changes only in
Content class.

10. Open Close Principle

11. Open Close Principle
 Software entities like classes, modules
and functions should be open for
extension but closed for
modifications.
 that the behavior of the module can be
extended.we can make the module
behave in new and different ways as
the requirements of the application.

12. Open Close Principle
 They are “Closed for Modification”.
 The source code of such a module is
inviolate. No one is allowed to make
source
 Abstraction is the key principle.

13. - 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;
}
}

14. Open Close Principle

15. 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
}
}

16. Open Close Principle

17. Liskov's Substitution Principle

18. Liskov's Substitution Principle
 Derived types must be completely
substitutable for their base types.
 if a program module is using a Base
class, then the reference to the Base
class can be replaced with a Derived
class without affecting the functionality
of the program module.

19. // Violation of Likov's Substitution Principle
class Rectangle {
protected int m_width;
protected int m_height;
public void setWidth(int width)
{ m_width = width; }
public void setHeight(int height)
{ m_height = height; }
public int getArea()
{ return m_width * m_height; }
}
class Square extends Rectangle {
public void setWidth(int width)
{ m_width = width; m_height = width; }
public void setHeight(int height)
{ m_width = height; m_height = height; }
}

20. class LspTest {
private static Rectangle getNewRectangle()
{
// it can be an object returned by some factory ...
return new Square();
}
public static void main (String args[])
{
Rectangle r = LspTest.getNewRectangle();
r.setWidth(5);
r.setHeight(10);
// user knows that r it's a rectangle.
// It assumes that he's able to set the width and height as for the
base class
System.out.println(r.getArea());
// now he's surprised to see that the area is 100 instead of 50.
}
}

21. Liskov's Substitution Principle
 it means that we must make sure that
new derived classes are extending the
base classes without changing their
behavior.

22. Interface Segregation Principle

23. Interface Segregation Principle
 clients should not be forced to
implement interfaces they don't use.

24. // interface segregation principle - bad example
interface IWorker {
public void work();
public void eat();
}
class Worker implements IWorker{
public void work() {}
public void eat() {}
}
class Robot implements IWorker{
public void work() {}
public void eat() {}
}
class Manager {
IWorker worker;
public void setWorker(IWorker w) { }
public void manage() {
worker.work(); } }

25. // interface segregation principle - good example
interface IWorkable {
public void work();
}
interface IFeedable{
public void eat();
}
class Worker implements IWorkable, IFeedable{
public void work() {}
public void eat() {}
}
class Robot implements IWorkable{
public void work() {}
}

26. Dependency Inversion Principle

27. Dependency Inversion Principle
 High-level modules should not depend
on low-level modules. Both should
depend on abstractions Give an
example.
 Abstractions should not depend on
details. Details should depend on
abstractions

28. Dependency Inversion Principle
 3 modules, Copy module call other 2
modules.2 sub modules are re usable

29. Dependency Inversion Principle
void Copy()
{
int c;
while ((c = ReadKeyboard()) != EOF)
WritePrinter(c);
}

30. Dependency Inversion Principle
enum OutputDevice {printer, disk};
void Copy(outputDevice dev)
{
int c;
while ((c = ReadKeyboard()) != EOF)
if (dev == printer)
WritePrinter(c);
else
WriteDisk(c);
}
 New device disk

31. Dependency Inversion Principle
 Make Copy module re usable.

32. class Reader
{
public:
virtual int Read() = 0;
};
class Writer
{
public:
virtual void Write(char) = 0;
};
void Copy(Reader& r, Writer& w)
{
int c;
while((c=r.Read()) != EOF)
w.Write(c);
}

33. Summary
 SRP: One reason to change.
 OCP: Extend function with out editing
code.
 LSP: Derived types can substitute
base.
 ISP: Don’t implement Interface they
don’t use
 DIP: Depend on abstraction instead of
details.

34. C# oop’s
Refreshing of what you know..

35. More information
 http://vivekcek.wordpress.com.