design patterns

14
Object Oriented Design How to start?

Upload: alok-pandey

Post on 08-May-2015

787 views

Category:

Technology


0 download

DESCRIPTION

Design patterns

TRANSCRIPT

Page 1: Design patterns

Object Oriented Design

How to start?

Page 2: Design patterns

Object Oriented Design

Who is to Blame

Page 3: Design patterns

Solution - Principles, Design Patterns and Software architecture

1.Software architecture2.Design pattern3.Principles

Page 4: Design patterns

Solution - Principles, Design Patterns and Software architecture

Mr. Robert Martin (commonly known as Uncle Bob) categorized them as1. Class Design principles – Also called SOLID2. Package Cohesion Principles3. Package Coupling principle

Page 5: Design patterns

SOLID

1.Single responsibility, 2.Open-closed, 3.Liskov substitution, 4.Interface segregation and 5.Dependency inversion

Page 6: Design patterns

I) S - SRP - Single responsibility Principle

1. What is the issue?

2. What is SRP?

3. Solutions which will not Violate SRP

public class Employee {

public string EmployeeName { get; set; } public int EmployeeNo { get; set; }

} public class EmployeeDB {

public void Insert(Employee e) {

//Database Logic written here } public Employee Select() {

//Database Logic written here }

} public class EmployeeReport {

public void GenerateReport(Employee e) {

//Set report formatting }

}

This principle also applies to methods. Every method should have a single responsibility.

Page 7: Design patterns

II) O - OCP – Open Close Principle

1. What is OCP?"Software modules should be closed for modifications but open for extensions.“2. Solution which will not violate OCPa) Use of inheritanceb) Extension method (from .NET 3.5)

Page 8: Design patterns

III) L – LSP – Liskov substitution principle

1.What is LSP?"Subclasses should be substitutable for base classes.“

Page 9: Design patterns

IV) I – ISP– Interface Segregation principle

"Clients should not be forced to implement interfaces they don’t use."

Page 10: Design patterns

V) D – DIP– Dependency Inversion principle

"High level modules should not depend upon low level modules. Rather, both should depend upon abstractions."

Page 11: Design patterns

Is it end?

1. Program to Interface Not Implementation.

2. Don't Repeat Yourself.

3. Encapsulate What Varies.

4. Depend on Abstractions, Not Concrete classes.

5. Least Knowledge Principle.

6. Favor Composition over Inheritance.

7. Hollywood Principle.

8. Apply Design Pattern wherever possible.

9. Strive for Loosely Coupled System.

10.Keep it Simple and Sweet / Stupid.

Page 12: Design patterns

Design Patterns

Types

1. Creational Patterns

2. Structural Patterns

3. Behavioral Patterns

Different type

4. Anti patterns

5. Other patterns

Page 13: Design patterns

Anti patterns

Antipatterns are misapplied design patterns. Common Antipatterns include:

1. The Blob/God Object - When one class contains all of the methods, operations and logic of your application

2. Re-coupling - building an unnecessary dependency between objects

3. Poltergeists - object whose main purpose in life is to pass messages to another object

4. Sequential Coupling - a class that imposes a particular order on its method calls.

Page 14: Design patterns

Conclusions

Design patterns make it easier to reuse successful designs and architectures. It’s important for every developer to be aware of design patterns but it’s also essential to know how and when to use them. Implementing the right patterns intelligently can be worth the effort but the opposite is also true. A badly implementing pattern can’t yield little benefit to a project.

Also bear in mind that it’s not the number of patterns you implement that’s important but how you choose to implement them. For example, don’t choose a pattern just for the sake of using ‘one’ but rather try understanding the pros and cons of what particular patterns have to offer and make a judgment based on it’s fitness for your application.