CODE LIKE A NINJATHE SINGLE RESPONSIBILITY PRINCIPLE

SESSION RESOURCES

• Presentation session notes including link to this session, will be available on http://learningaboutfudge.blogspot.com

• All the source for this session is publically available at: https://github.com/SheepWorx/Training

• RSS Feed: http://learningaboutfudge.blogspot.com/feeds/posts/default?alt=rss

• Local Network: \\dmeyer-m\share\training\Code Like a Ninja

• Source was compiled using Visual Studio 2012

Single Responsibility PrincipleOpen/Close PrincipleLiskov’s Substitution PrincipleInterface Segregation PrincipleDependency Inversion Principle

DEFINITION

The Single Responsibility Principle

A class should only have a single responsibility – one reason to change

WHY?

• Makes the class more robust

• Keeping responsibilities decoupled so that change in the one, does not affect the other

• When you make changes to a class that has multiple responsibilities, you run the risk of introducing change that might break something else

• Classes with more than one responsibility, tend to be more brittle

EXAMPLE 1 – BASIC SRP

• The Airtime class is fine SRP wise

• The abstract Product class violates SRP

• If a new property needs to get added, it has to change

• If the description needs to change, it needs to change

• If a new description needs to be added, it needs to change

What will happen when multiple products inherit product and the GetProductDescription method can no longer be sufficient for all the child classes?

• Product now only has one reason to change

• Different types of description implementationscan now be used

Drawback: Code cohesion has been lost

EXAMPLE 1 – BASIC SRP [SOLVED]

SRP DISCUSSION POINTS

• Opinion today is that the SRP as stated by Robert C Martinis too strict.

• When you refactor something too far, you lose code cohesion (ie what the developer’s intentions were, code becomes difficult toread, etc)

This example shows that code cohesion is maintained while allowingseparate implementation for each product type. Although the SRP here isviolated from a technical point of view, the functionality adheres from a contextual point of view.

SRP AND ANTI-PATTERNS

Anti-Pattern: a Pattern that is ineffective and/or counterproductive.

Examples

• The “Utils” class

• Singleton

Why?

EXAMPLE 2 – UTILS CLASS ANTI-PATTERN

• ProductFunctions is our utls class

• It accepts instances of Product and does stuff

• Like calculate vat

• Return a formatted product description

What happens when we want to

• Change current vat implementation

• Add a new vat implementation

• Add multiple different ways to format product description

EXAMPLE 2 – UTILS CLASS ANTI-PATTERN

CallingApp now creates the desired instance and uses it directly. Code cohesion can still be maintained by proper namespace management:For ex: ProductUtls.CalculateVat.SAVat or ProductUtils.DescriptionFormat.HtmlFormat

HOMEWORK

Have a look at the Homework folder in the solution

• Refactor classes as you see fit and motivate your reasons for refactoring the way you did.

• Mention any risks that might exist after refactoring

THINGS TO CONSIDER WHEN YOU’RE REFACTORING

Functional motivators for refactoring

• Are properties going to get reused

• Is the email functionality going to get reused

• Is the receipt functionality going to get reused

• Will only receipts get printed? will we need to extend to other types of printing

• Send mail is only for sending mail. Will need want to send other forms of msgs? whatsapp, ussd notification?

• Will this live in a multithreaded environment

• etc

Non-functional motivators

• How much time do I have for this

• How much money is business willing to spend

• Where is this work going to go? who/what is the target audience or system

• Who's going to be maintaining this? will they understand what was done

• Will all my changes still make contextual sense (have a high level of cohesion) afterwards?

• etc

• !!!!!!!!how much time do i have to spend on this!!!!!!!

FINAL THOUGHT

When refactoring in accordance to the SRP, you always have to ask yourself: “What do I need to keep open for change vs keep closed for modification”

Next Session: S.O.L.I.D – The Open/ Close Principle

Where: 10-11am @ Aandrag Meeting Room 21

SESSION RESOURCES

• Presentation session notes including link to this session, will be available on http://learningaboutfudge.blogspot.com

• All the source for this session is publically available at: https://github.com/SheepWorx/Training

• RSS Feed: http://learningaboutfudge.blogspot.com/feeds/posts/default?alt=rss

• Local Network: \\dmeyer-m\share\training\Code Like a Ninja

• Source was compiled using Visual Studio 2012