Improving Software Quality Using Object Oriented Design Principles
-
Upload
dr-syed-hassan-amin -
Category
Software
-
view
45 -
download
0
Transcript of Improving Software Quality Using Object Oriented Design Principles
Improving Software Quality Using Object Oriented Design PrinciplesByDr. Syed Hassan AminNote : Thanks to all those who contributed to creating and improving these slides.
High Level Overview• Software Quality• OOP Design Principles• OO Best Practices• Bad Smells of Code• Details of various principles with examples
• Note : We will not be able to cover everything in this lecture !
Introduction• In software engineering we normally start with requirement
gathering, analysis, writing features list and design• At some point you actually are going to write some code. • And that’s where design principles come into play
Software Quality• Software quality refers to two related but distinct notions that exist
wherever quality is defined in a business context:-• Software functional quality reflects how well it complies with or
conforms to a given design, based on functional requirements or specifications.
• Software structural quality refers to how it meets non-functional requirements that support the delivery of the functional requirements, such as robustness or maintainability, the degree to which the software was produced correctly.
• Properties/Characteristics of software that constitute software quality are :-• Flexibility• Maintainability• Extendibility• Reusability• Testability
What is OO Design Principle?
• A design principle is a basic tool or technique that can be applied to writing code to make resultant software maintainable, flexible, extendible and reusable.• Today we are going to look into some design principles
that people came up with over the years and how they can make you a better engineer. • Put aside your thoughts of “doing it your way”; this
presentation is about doing it the smarter and faster way.
OOP Design Principles• Encapsulation or Information Hiding• Open-Closed principle(OCP)• Single responsibility principle(SRP)• Liskov substitution principle(LSP)• Don’t repeat yourself(DRY)• Law of Demeter(LoD)• Dependency Injection or Inversion of Control(IoC)
OO Best Practices• Encapsulate what varies• Code to an interface rather than to an implementation• Dependency Injection • Composition better than Inheritance• Prefer ‘Has a’ over Ís a’• Use Inheritance Sparingly
• Reduce Coupling, Increase Cohesion• Classes are about Behavior i.e. No Dumb Data Holders
Bad Smells of Code• Repeated Code• Long Method• Long Class• Long Parameter List• Data Class – Dumb Data Holder• Violation of encapsulation • Global variable(s)
Open-Close Principle
“Classes should be open for extension, and closed for modification”
• New functionality should be added with minimum changes in the existing code.
• The design should be done in a way to allow the adding of new functionality as new classes, keeping existing code unchanged.
OCP – Good Example
Like every principle OCP is only a principle. Making a flexible design involves additional time and effort ,and it introduce new level of abstraction increasing the complexity of the code.
So this principle should be applied in those areas which are most likely to be changed.
Single Responsibility Principle(SRP)“A class should have only one reason to change”
• This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes.
• Each class will handle only one responsibility and in the future if we need to make one change we are going to make it in the class which handle it.
• When we need to make a change in a class having more responsibilities the change might effect the other functionality of the classes.
Liskov Substitution Principle(LSP)“Sub Type must be substitutable for their base type”
• We must make sure that the new derived classes just extend without replacing the functionality of base classes.
• Liskov’s substitution principle states that 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.
LSP – Bad Example• Extend Board to produce 3D
board• Analyze the design to find out
design problems• This Principle is just an extension
of Open-Close Principle • The focus of this principle is to
make sure that new derived classes are extending the base class without changing their behavior
LSP – Bad Example • But this means that an instance of Board3D looks like this:• Each attribute and method in bold is meaningless in this object • Board3D is getting nothing useful from Board except for width
and height• We certainly could NOT create a Board3D object and hand it to
code expecting a Board object!• As a result, this design violates the LSP principle
LSP – Delegation comes to rescue• Board3D example violated LSP because of inappropriate use of
inheritance.• Thus, if you need to use functionality in another class, but you
don’t want to change that functionality, consider using delegation instead of inheritance
• Inheritance was simply the wrong way to gain access to the Board’s functionality
• Delegation is when you hand over the responsibility for a particular task to some other class or method
LSP – Delegation comes to rescue (Cont’d)
• Board3D now maintains a list of Board objects for each legal value of “zpos”• It then delegates to the
Board object to handle the requested service
public Tile getTile(int x, int y, int z) {Board b = boards.get(z);return b.getTile(x,y);}
Don’t Repeat Yourself (DRY)
“Avoid duplicate code by abstracting out things that are common and putting these in a single location”
DRY is about having each piece of information and behavior in your system in a single sensible place.
Encapsulate What Varies• Anytime you have behavior in an application that you think is likely
to change, you want to move that behavior away from parts of your application that probably won’t change very frequently.
• In other words you should always try to encapsulate what varies.
Code To An Interface Principle
“Code to an interface rather than to an implementation”
• Coding to an interface, rather than to an implementation makes your software easier to extend and reuse
• Objective is to hide implementation details thus reducing coupling and increasing cohesion
• Any time you are writing code that interact with other classes, you have two choices.• You can write code that interact directly with sub class, Like
BaseballPlayer, or you can write code that interact with Athlete. • When you run into the choice like this, you should always favor
coding to the interface, not to the implementation.
Use Inheritance Sparingly• Rule of thumb : (almost)• Inherit only when clear ‘is a’ relation exists AND• All the members in base Class will be used/implemented in sub
classes• If you use inheritance other than these rules, highly probably
you are mistaken
Inappropriate use
• Board3D is not a Board2D• Board3D will have useless members eventually,
like tiles : int[][] • All the methods of Board2D will become useless
in Board3D• Inheritance is surely not the option
Solution• Board3D is composed of Board2D• We have “depth” times Board2Ds in our Board3D class• All the operations are delegated to Board2D methods• Board3D methods will use respective Board2D methods for “depth” times• Composition and delegation is better choice
Summary
We have covered some basic object oriented design principles that help us to write the code which is more maintainable and extensible.
Following are some more principles which you can see by yourself
• Dependency Injection Principle• Favor Composition Over Inheritance
References
• http://www.oodesign.com/design-principles.html• http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)• Head First Object Oriented Analysis and Design (O’Reilly)