C:\Fakepath\Combating Software Entropy 2

  • Published on
    08-May-2015

  • View
    1.667

  • Download
    0

Embed Size (px)

DESCRIPTION

Hammad Rajjoub's presentation of Software Design and Architecture during Microsoft Tech Ed Middle East.

Transcript

  • 1.

2. ARC202 - Combating Software Entropy with Design Patterns and Principles
Hammad Rajjoub
Solutions Architect @ Infusion
Microsoft MVP
3. Cogito, Ergo , Sum
Microsoft MVP Connected Systems (5+ yrs)
Solutions Architect at Infusion
The coolest company in town
Develop. Design. Venture. Join us!
Speaker, Author & Community Leader
I do: Blog + Twitter + PodCast
Bing me http://www.bing.com/search?q=hammadrajjoub
4. Agenda
Why is Software Complex?
What is bad design?
How to Fix it?
Summary
References
QnA
5. Why is Software Complex
Writing new software
Mandated to develop new systems
Generally from scratch
But still mostly relying on existing libraries and frameworks
Real-world problems are sometimes complex
Modifying Existing Software
Find that bug and fix it
Add a new exciting feature
Review and refactor to a better design
6. What is bad design?
7. Bad design is...
Hard to change!
A single change break lots of other code
Rigid
Fragile
Cant be extended
Immobile
8. How to fix it?
Using design principles and practices
The Single Responsibility Principle
The Open Closed Principle
Liskov Substitution Principle
Dependency Inversion Principle
Using Software Design Metrics
And yes a whole lot of refactoring
9. Single Responsibility Principle
None but Buddha himself must take the responsibility of giving out occult secrets...
E. Cobham Brewer 18101897.
Dictionary of Phrase and Fable. 1898.
SRP
10. The Single responsibility principal
"A responsibility is a reason to change, a class or module should have one, and only one, reason to change."
11. The Single Responsibility Principal
Responsibility is a Reason for change
Each responsibility is an axis of change
There should never be more than one reason for a class to change
Dijkstras SoC: Separation of Concerns
This helps us evaluate a class s
exposure to change
12. BusinessPartnerValidtor Module
Example:
13. BusinessPartnerValidator
BusinessPartner
Validator
DB
Trade
What is wrong here: Changes if DB changes or Business Logic Changes
14. Counterparty Validator Iter 1
internal class BusinessPartnerValidator
{
public void AssertValid(Trade t)
{
varsql = "SELECT COUNT(*) FROM BusinessPartner WHERE name=@Name";
using (varconn = CreateOpenConnection())
{
varcmd = new SqlCommand(sql, conn);
cmd.Parameters.Add("@Name", SqlDbType.VarChar);
cmd.Parameters["@name"].Value = t.BusinessPartnerName;
var count = (Int32) cmd.ExecuteScalar();
if (count != 1) throw new InvalidBusinessPartyException(t.BusinessPartyName);
}
}
...
Where is the business logic?
Hidden by database code.
15. BusinessPartyValidator Iter 2
internal class BusinessPartnerValidator
{
private readonlyBusinessPartnerValidatorbusinessPartnersource;
public BusinessPartyValidator(BusinessPartnerSourceBusinessPartySource)
{
this.businessPartnerSource = BusinessPartnerSource;
}
public void AssertValid(Trade t)
{
if (BusinessPartnerSource.FindByName(t.BusinessPartnerSource) == null)
throw new InvalidBusinessPartnerException(t.BusinessPartnerName);
}
}
BusinessPartyValidator now has a single responsibility
16. RefactoredBusinessPartnerValidator
BusinessPartner
Validator
BusinessPartner
Source
Trade
DB
What's its job?
Classes must have an identifiable single responsibility.
17. Open Closed Principle
..this is the heart of Object Oriented Programming...
OCP
18. The Open Closed Principle
Realise that generally systems outlive their expected timelines
All software entities should be closed for change and opened for extension
Your design modules should never change
You should just extend the behaviour
19. Liskov Substitution Principle
There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened.
Douglas Adams (1952 - 2001)
20. The Liskov substitution principal
Functions that reference a base class must be able to use objects of derived classes without knowing it."
21. Using Inheritance for OCP?
RateCalculator
Trade
Option
Fee
22. Trade Rate Calculation
public decimal CalulateRate(Trade t)
{
if (t is Fee)
{
return 1.0m;
}
return t.BaseAmount/t.QuotedAmount;
}

  • Use of convention rather than design

23. Fragile: sensitive to any change in Trade Fee Hierarchy