solid and ioc principles

28
eleks.com eleks.com SOLID AND IOC PRINCIPLES The first five principles of OOP design… And the additional one Mykhailo Romaniuk

Upload: eleksdev

Post on 13-Apr-2017

1.181 views

Category:

Technology


0 download

TRANSCRIPT

Page 1: Solid and ioc principles

eleks.com eleks.com

SOLID AND IOC PRINCIPLES The first five principles of OOP design… And the additional one

Mykhailo Romaniuk

Page 2: Solid and ioc principles

Single Responsibility Principle

Page 3: Solid and ioc principles

SRP

A class should have only one reason to change

Robert C. Martin

Page 4: Solid and ioc principles

SRPStates that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class

Page 5: Solid and ioc principles

Open/Closed Principle

Page 6: Solid and ioc principles

OCP

Objects or entities should be open for extension, but closed for modification

Bertrand Meyer

Page 7: Solid and ioc principles

OCPStates that software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification, that is, such an entity can allow its behavior to be extended without modifying its source code

Page 8: Solid and ioc principles

Liskov Substitution Principle

Can a toy-dog woof without batteries?

Page 9: Solid and ioc principles

LSP

Let f(x) be a property of objects X of type T. Then f(y) should be true for objects Y of type S where S is a subtype of T

Barbara Liskov

Page 10: Solid and ioc principles

LSP

States that if S is a subtype of T, then objects of type T may be replaced with objects of type S without altering any of the desirable properties of that program (correctness, task performed)

Page 11: Solid and ioc principles

Interface Segregation Principle

Page 12: Solid and ioc principles

ISP

Many client-specific interfaces are better than one general-purpose interface

Robert C. Martin

Page 13: Solid and ioc principles

ISP

States that no client should be forced to depend on methods it does not use. Thus having multiple grained interfaces is better that one.

Page 14: Solid and ioc principles

Dependency Inversion Principle

Page 15: Solid and ioc principles

DIP

One should depend upon abstractions, not on concretions

Robert C. Martin

Page 16: Solid and ioc principles

DIPA. High-level modules should not depend

on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend on details. Details should depend on abstractions.

Page 17: Solid and ioc principles

Inversion of Control Principle

Page 18: Solid and ioc principles

What Is IoC?

In software engineering, IoC describes a design in which custom-written portions of a computer program receive the flow of control from a generic, reusable library.

Wikipedia

Page 19: Solid and ioc principles

“How To IoC”?

• Events• Delegates• Dependency

Injection

Page 20: Solid and ioc principles

Dependency Injection

Dependency injection means giving an object it’s instance variables. Really. That's it.

James Shore

Page 22: Solid and ioc principles

Injection Types• Constructor

Injection• Using Property• Thru Initialization

Method

Page 23: Solid and ioc principles

Software Testability

If your code isn't testable, then you have a design problem

Common Sense

Page 24: Solid and ioc principles

What Makes Your Software Testable?• SRP. Since type is doing only one job, you

can clearly understand what should be tested.

• LSP. Since types used can be replaced with subtypes, mocks and stubs can be used instead of real types.

• ISP. Since there are more granular client-specific interfaces, you know exactly what to mock.

Page 25: Solid and ioc principles

Let’s Review Some Concepts• Reusable. Higher-level

components can be reused if lower-lever components change with time to meet the requirements.

• Extensible. Software is easily extended with new components and features because design is based on abstractions.

• Replaceable. Lower-level components can be replaced to meet new requirements without modifying existing code.

• Loosely Coupled. Allows components to perform on their own with as little knowledge as possible about other components.

• Cohesive. Build you software easily with different components as building blocks.

• Testable. It is easy to understand what and how to test in each component because components are loosely-coupled.

Page 26: Solid and ioc principles

Thanks! Any Questions?

Page 27: Solid and ioc principles

What can you read at home?• Wikipedia about SOLID

https://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29• Nice article about SOLID with examples

https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design

• Dive deeper into SOLIDhttp://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

• SOLID explanation with examples:http://www.codemag.com/article/1001061

• Simple explanation of DI for beginnershttp://www.jamesshore.com/Blog/Dependency-Injection-Demystified.html

• IoC and DIhttp://martinfowler.com/articles/injection.html

Page 28: Solid and ioc principles

eleks.com

Inspired by Technology.Driven by Value.