Code Craftsmanship        Presented by: Nadeem Mohammad        Date: 10/7/2012Make your problem open new doors for innovat...
ABOUT ME (Nadeem Mohammad) •   Senior Technical Lead •   Web 3.0 COE lead •   ≃ 5 Years with Prokarma •   Two Sons     • I...
Note• I would be talking mostly about the following people  works.                                      Michael Feathers  ...
AGENDA•   Clean Code, Why?•   Common Terms•   Code Smells•   Design Smells (High Level)•   SOLID Principles (High Level)• ...
The Rule • Apply Common Sense • Don’t get too dogmatic / religious • Every decision is a tradeoff • All other principles a...
Clean Code, Why?           July 12, 2012      © 2012 ProKarma | All Rights Reserved                           Confidential...
Clean Code, Why? • There may not be same set of people   maintaining the code after the code is   written • Write Code for...
Clean Code, Why? • Good Software == saved more money            July 12, 2012      © 2012 ProKarma | All Rights Reserved  ...
Clean Code, Why? • Design rot when not carefully maintained              July 12, 2012      © 2012 ProKarma | All Rights R...
Clean Code, Why? • Say yes to Change             July 12, 2012      © 2012 ProKarma | All Rights Reserved                 ...
Common Terms • Code Smells • Refactoring • Test Driven Development (TDD)             July 12, 2012      © 2012 ProKarma | ...
Common Terms : Code Smells • A Code Smell is a hint that   something has gone wrong   some where in your code,   Use the s...
Common Terms : Refactoring • A process of changing a software system   in such a way that it does not alter the   external...
Common Terms : TDD • Does this happen to you                                                                    This chang...
Common Terms : TDD • A new way of programming. • A new way of thinking • The Rule  • Only write code to satisfy a failing ...
Three laws of TDD  • Write no production code unless you have    a failing unit test • Do not write more of a unit test th...
TDD Cycle            July 12, 2012      © 2012 ProKarma | All Rights Reserved                            Confidential & Pr...
Clean Code Guidelines• Identify Code Smells• Many things make a design hard to   maintain• Develop a nose for bad structur...
Code Smells                                                Bloaters                                                • Long ...
Code Smells : Bloaters • Bloater smells represent something   that has grown so large that it can not   be effectively han...
Bloaters: Long method The Problem                                          The Solution Readability : Longer code takes lo...
Long method : ExampleImagine what could have happened if struts guys would have written all the code in the same methodins...
Bloaters: Long Class• A Class has taken too much  responsibilities, and is modeling more  than one concept.The Problem    ...
Bloaters: Long Class             Delegated the             responsibilities to             different classes             J...
Bloaters: Long Parameter ListMethods that take too many parameters produce client code that is awkward and difficult to wo...
Bloaters: Long Parameter List            6 parameters to just 1 parameter              July 12, 2012           © 2012 ProK...
Bloaters: Primitive Obsession •    Code is using primitive data types and method calls to generate desired      outcomes, ...
Bloaters: Data Clumps • If you always see the same data hanging around   together, maybe it belongs together. Consider rol...
Data Clumps: Example           July 12, 2012      © 2012 ProKarma | All Rights Reserved                           Confiden...
Bloaters: Comments  • Fowler says “comments often are used as    a deodorant” • Refactor code so that the comment    becom...
Comments : Example          Turn comments into          code          July 12, 2012           © 2012 ProKarma | All Rights...
Comments : Example           July 12, 2012      © 2012 ProKarma | All Rights Reserved                           Confidenti...
Dispensables • They all represent something   unnecessary that should be removed   from the source code               July...
Dispensables : Lazy Class • A class isnt doing much—its parents,   children, or callers seem to be doing all   the associa...
Lazy Class : Example    • Pull Up the calculatePostage() method.    • Make the Address class non abstract    • Remove the ...
Dispensables : Data Class • A key goal of OO design is to minimize depedencies   between classes and components by packagi...
Data Class : Example            This Class simply displays Student Summary            Move this method out to Student Clas...
Dispensables : Duplicate Code • Code that is the same, or performs the   same function are showing up in multiple   places...
Duplicate Code: Example            July 12, 2012      © 2012 ProKarma | All Rights Reserved                            Con...
Dispensables : Dead Code • Code that is no longer usedThe Problem                              The SolutionHarder to compr...
Dead Code: Example           July 12, 2012      © 2012 ProKarma | All Rights Reserved                           Confidenti...
Dispensables : Speculative Generality  • Creating today what we speculate will be    needed in the future (where there is ...
Code Smells : OO Abusers • Solution does not fully exploit the   possibilities of Object Oriented Design • For example a s...
OO Abusers: Switch Statements • Switch statements are bad from an OO design   standpoint. Not only because theyre basicall...
Switch Statements : Example            July 12, 2012      © 2012 ProKarma | All Rights Reserved                           ...
OO Abusers: Temporary fields • This smell occurs when a class has a field that is   only used some of the time. A class li...
Temporary fields : Example             July 12, 2012      © 2012 ProKarma | All Rights Reserved                           ...
OO Abusers: Refused Bequest • If you inherit from a class, but never use   any of the inherited functionality, should   yo...
Refused Bequest : Symptoms • The subclass undefines an inherited method,    makes an inherited method private, or makes it...
Refused Bequest : What can be done? • If its not confusing, you might decide to leave it   as is • If theres no reason to ...
OO Abusers: Alternate Classes with different Interfaces • Lacks a common interface for closely   related classes, so it ca...
Code Smells : Change Preventers • Smells that hinder changing or further   developing the software             July 12, 20...
Change Preventers : Divergent Change • Divergent change occurs when one class   is commonly changed in different ways for ...
Divergent Change : Example            July 12, 2012      © 2012 ProKarma | All Rights Reserved                            ...
Change Preventers : Shortgun surgery • If a change in one class requires   cascading changes in several related   classes,...
Change Preventers : Parallel Inheritance Hierarchies • A special case of shotgun surgery • Every time you make a subclass ...
Code Smells : Couplers • Coupling among classes or subsystems is   a measure of how interconnected those   classes or subs...
Couplers : Feature Envy • A method in ClassA seems way too   interested in the workings and data fields   of ClassB. The f...
Feature Envy : Example            July 12, 2012      © 2012 ProKarma | All Rights Reserved                            Conf...
Couplers : Inappropriate Intimacy • When two classes exhibit an unhealthy   fascination with each others bits, we call   t...
Couplers : Message Chains • Message Chains is a smell where class A needs data   from class D. To access this data, class ...
Couplers : Middle Man • Represent a problem that might be   created when trying to avoid high coupling   with constant del...
Design Smell                                 Immobility              Opacity                               Rigidity       ...
SOLID STUFF • Single Responsibility Principle (SRP) • Open-Closed Principle (OCP) • Liskov Substitution Principle (LSP) • ...
Cohesion and Coupling • Cohesion – How closely related are the   different responsibilities of a module • Coupling – How m...
Single Responsibility Principle (SRP)  • A Class should have only one reason to    change.  Just because you can doesnt me...
Responsibiltiy?  • What a class does  • The more a class does, the more likely it    will change  • The more a class chang...
Open-Closed Principle (OCP)    Brain surgery is not needed when putting on a hat.                July 12, 2012      © 2012...
Liskov Substitution Principle (LSP)  If it looks like a duck, quacks like a duck but  needs batteries - You probably have ...
Interface Segregation Principle (ISP)   You want me to plug this in, Where?                 July 12, 2012      © 2012 ProK...
Dependency Inversion Principle (DIP)   Would you solder a lamp directly to the   electrical wiring in a wall?             ...
Architecture Smell  • Smell in subsystems    – No subsystems, too little subsystems, too large subsystems    – Too many su...
Remember Rather than construction, software is more like gardening – it is more organic than concrete.                    ...
Software Craftsmanship Manifesto            July 12, 2012      © 2012 ProKarma | All Rights Reserved                      ...
Reach Me @    mnadeem@prokarmasoftech.com    996-663-9709ProKarma Recognized by Inc. Magazine as the"Fastest-Growing IT Se...
Upcoming SlideShare
Loading in...5
×

Code Craftsmanship

348

Published on

Code Craftsmanship Presentation

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
348
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Code Craftsmanship

  1. 1. Code Craftsmanship Presented by: Nadeem Mohammad Date: 10/7/2012Make your problem open new doors for innovation and proudly say “processing by innovation” ProKarma Recognized by Inc. Magazine as the "Fastest-Growing IT Services Company in July 12, 2012 © 2012 ProKarma | All Rights Reserved America” Confidential & Proprietary | www.prokarma.com
  2. 2. ABOUT ME (Nadeem Mohammad) • Senior Technical Lead • Web 3.0 COE lead • ≃ 5 Years with Prokarma • Two Sons • Ibraheem • Imran July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  3. 3. Note• I would be talking mostly about the following people works. Michael Feathers Martin fowler Dave Thomas Grady booch Ron Jefferies Ward Cunningham July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  4. 4. AGENDA• Clean Code, Why?• Common Terms• Code Smells• Design Smells (High Level)• SOLID Principles (High Level)• Architecture Smells (High Level) July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  5. 5. The Rule • Apply Common Sense • Don’t get too dogmatic / religious • Every decision is a tradeoff • All other principles are just that • Guidelines • “best practices” • Consider carefully if you should violate them - but, know you can. July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  6. 6. Clean Code, Why? July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  7. 7. Clean Code, Why? • There may not be same set of people maintaining the code after the code is written • Write Code for who comes after you, not for the computer July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  8. 8. Clean Code, Why? • Good Software == saved more money July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  9. 9. Clean Code, Why? • Design rot when not carefully maintained July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  10. 10. Clean Code, Why? • Say yes to Change July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  11. 11. Common Terms • Code Smells • Refactoring • Test Driven Development (TDD) July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  12. 12. Common Terms : Code Smells • A Code Smell is a hint that something has gone wrong some where in your code, Use the smell to track down the problem • We would be discussing more on this soon What is that smell??? Did you write that Code? July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  13. 13. Common Terms : Refactoring • A process of changing a software system in such a way that it does not alter the external behavior of your code yet improves its internal structure • Refactoring brings patterns into your code • The goal of refactoring is NOT to add new functionality July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  14. 14. Common Terms : TDD • Does this happen to you This change should work just fine. July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  15. 15. Common Terms : TDD • A new way of programming. • A new way of thinking • The Rule • Only write code to satisfy a failing test case. July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  16. 16. Three laws of TDD • Write no production code unless you have a failing unit test • Do not write more of a unit test than is sufficient to fail (And not compiling is failing) • Do not write more production code than is sufficient to make the failure pass. • Rinse and repeat every minute July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  17. 17. TDD Cycle July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  18. 18. Clean Code Guidelines• Identify Code Smells• Many things make a design hard to maintain• Develop a nose for bad structures • Long method • Long class • Feature Envy • Duplicate code • …… July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  19. 19. Code Smells Bloaters • Long method • Long class • Primitive Obsession • Long Parameter List • Data Clumps Couplers OO Abusers • Feature Envy • Switch Statements • Inappropriate Intimacy • Temp fields • Message Chains • Refused Bequest • Middle Man Code Smells • Alt classes with diff. Interfaces Dispensables Change Preventers • Lazy class • Divergent Change • Data Class • Shotgun surgery • Duplicate Code • Parallel inheritance hierarchies • Dead Code • Speculative Generality July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  20. 20. Code Smells : Bloaters • Bloater smells represent something that has grown so large that it can not be effectively handled • This smells grow little bit at a time July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  21. 21. Bloaters: Long method The Problem The Solution Readability : Longer code takes longer to read Break the method up into greater number of and comprehend. methods or into other classes. Have one method represent a single function and a class single Reusability : A longer method may be to be able concept. to split into methods and classes that can be reused Testability : a long method is likely to need more testing. July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  22. 22. Long method : ExampleImagine what could have happened if struts guys would have written all the code in the same methodinstead of dividing into different methods July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  23. 23. Bloaters: Long Class• A Class has taken too much responsibilities, and is modeling more than one concept.The Problem The SolutionComplexity : if your class represents more than a Ensure that the class represents a single concept,single concept, it will be harder to understand. and break it into several classes if it represents more than a single concept.Bloat : a greater number of fields and methodswill mean the class will take longer to understand. You may find that functionality or state could belong to a different class, in which case functionality or state could be moved to the other class. July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  24. 24. Bloaters: Long Class Delegated the responsibilities to different classes July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  25. 25. Bloaters: Long Parameter ListMethods that take too many parameters produce client code that is awkward and difficult to work with.The Problem The SolutionUnderstandability : lots of parameters will make Put the data into their own classes, and possiblycode harder to understand. break the method up into several methods. Ensure that each method is performing a single function,The method is doing too much - why does it need and each class modelling a single concept.all of that information? Limit the number of parameters you need in a given method, or use an object to combine the parameters. July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  26. 26. Bloaters: Long Parameter List 6 parameters to just 1 parameter July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  27. 27. Bloaters: Primitive Obsession • Code is using primitive data types and method calls to generate desired outcomes, and could be written in a more descriptive and sustainable way. • Arises when we use primitive types (such strings or integers) to represent what should be explicit types in our domain • For example, using a string to store my name (“Nadeem Mohammad”) would likely be a loss of an abstraction. This probably needs to be modeled as a something more explicit such as a User or a Person, having a FirstName and a LastName. • Come up with Small classes like Money, Currency, PhoneNumber etc. The Problem The Solution Reusability: Code written is not reusable. Dont use a gaggle of primitive data type variables as a poor mans substitute for a class. If your data It may be less clear to someone reading the code type is sufficiently complex, write a class to what is going on. represent it. Encapsulate data concepts in classes, and create and call methods on objects of a class to attain desired results. July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  28. 28. Bloaters: Data Clumps • If you always see the same data hanging around together, maybe it belongs together. Consider rolling the related data up into a larger class. • An Example would be Address, FaxNumber ClassesThe Problem The SolutionReusability: Code written Is not reusable. If the items are fields in a class, Encapsulate fields in a separate new class. If the values are together in method signatures, Introduce Parameter Object to extract the new object. Look at calls that pass around the items from the new object to see if they can Preserve Whole Object instead. July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  29. 29. Data Clumps: Example July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  30. 30. Bloaters: Comments • Fowler says “comments often are used as a deodorant” • Refactor code so that the comment becomes extraneous, replace it with more expressive code July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  31. 31. Comments : Example Turn comments into code July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  32. 32. Comments : Example July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  33. 33. Dispensables • They all represent something unnecessary that should be removed from the source code July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  34. 34. Dispensables : Lazy Class • A class isnt doing much—its parents, children, or callers seem to be doing all the associated work, and there isnt enough behavior left in the class to justify its continued existence July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  35. 35. Lazy Class : Example • Pull Up the calculatePostage() method. • Make the Address class non abstract • Remove the ShippingAddress Class. July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  36. 36. Dispensables : Data Class • A key goal of OO design is to minimize depedencies between classes and components by packaging data and behavior as close together as we can. In practice, a good rule of thumb for class design is to put fields and methods that use those fields in the same classes. Data classes are classes which just have fields and no behavior (besides simple getters and setters), and they break this rule of thumb, creating serious dependency issues in your code July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  37. 37. Data Class : Example This Class simply displays Student Summary Move this method out to Student Class instead, And create a method getAddressSummay() in Address Class July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  38. 38. Dispensables : Duplicate Code • Code that is the same, or performs the same function are showing up in multiple places within a program. The Problem The Solution Bloat : more code will increase the size of Refactor the code, combine duplicate code into a method, classes, making them more time or into separate classes. consuming to read and understand. Maintenance : changes to one of the blocks of code will most likely cause other blocks of code to also be changed. This can also lead to greater defects if the duplicate code isnt updated. July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  39. 39. Duplicate Code: Example July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  40. 40. Dispensables : Dead Code • Code that is no longer usedThe Problem The SolutionHarder to comprehend the code base. Remove dead code. The following factors will help in doing so:Wasted time - reading through, or even Domain knowledge : to ensure that the code is in fact dead.changing dead code. Tools : is the code called from anywhere? Testing coverage : can tests be run after deletion to ensure functionality still works? Version control will also help ensure that code can be restored if accidentally deleted. July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  41. 41. Dead Code: Example July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  42. 42. Dispensables : Speculative Generality • Creating today what we speculate will be needed in the future (where there is no current need for a particular feature / design) The Problem The Solution Wasted time creating code that isnt Design code to a specification. If a feature is needed in the actually going to be used (it is dead). future, you can always refactor code if need be. Until that time, remember YAGNI (You aint gonna need it!). Greater complexity : now there is more code to sort through Just delete that darn code. July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  43. 43. Code Smells : OO Abusers • Solution does not fully exploit the possibilities of Object Oriented Design • For example a switch statement might be considered acceptable or even good design in procedural programming but is something that should be avoided OO programming July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  44. 44. OO Abusers: Switch Statements • Switch statements are bad from an OO design standpoint. Not only because theyre basically big nested IF statements, but because they have a tendency to grow. A refactored switch statement would exploit polymorphism, which is the OO way to make decisions about how to do specific "stuff" at run time • The situation where switch statements or type codes are needed should be handled by creating subclasses • Move each leg of the conditional to an overriding method in a subclass. Make the original method abstract July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  45. 45. Switch Statements : Example July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  46. 46. OO Abusers: Temporary fields • This smell occurs when a class has a field that is only used some of the time. A class like this can be hard to understand because you would normally expect it to use all its instance variables and it can be difficult to see what the temporary variable is used for • A variable is in the class scope, when it should be in method scope • A field is set only at certain times, and it is null (or unused) at other times July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  47. 47. Temporary fields : Example July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  48. 48. OO Abusers: Refused Bequest • If you inherit from a class, but never use any of the inherited functionality, should you really be using inheritance? • Refused Bequest smells lack proper inheritance design July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  49. 49. Refused Bequest : Symptoms • The subclass undefines an inherited method, makes an inherited method private, or makes it throw an exception when it is called ( Explicit refusal) • A class inherits from a parent, but an inherited method just doesnt work when called on the class (implicit refusal) • An inheritance relationship between two classes doesn’t make sense; the subclass just isn’t an example of the parent July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  50. 50. Refused Bequest : What can be done? • If its not confusing, you might decide to leave it as is • If theres no reason to share a class relationship, then Replace Inheritance with Delegation. • If the parent-child relationship does make sense you can re arrange the class hierarchy July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  51. 51. OO Abusers: Alternate Classes with different Interfaces • Lacks a common interface for closely related classes, so it can also be considered a certain type of inheritance misuse • If you can find the similarities between the two classes, you can often refactor the classes to make them share a common interface July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  52. 52. Code Smells : Change Preventers • Smells that hinder changing or further developing the software July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  53. 53. Change Preventers : Divergent Change • Divergent change occurs when one class is commonly changed in different ways for different reasons There by Violating SRP • You might refactor this class to extract distinct responsibilities into new classes July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  54. 54. Divergent Change : Example July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  55. 55. Change Preventers : Shortgun surgery • If a change in one class requires cascading changes in several related classes, consider refactoring so that the changes are limited to a single class • change several classes when changing database from one vendor to another • Try to fix this by pulling all the parts of the code that have to change together into a single cohesive class July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  56. 56. Change Preventers : Parallel Inheritance Hierarchies • A special case of shotgun surgery • Every time you make a subclass of one class, you also have to make a subclass of another July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  57. 57. Code Smells : Couplers • Coupling among classes or subsystems is a measure of how interconnected those classes or subsystems are • Tight coupling means that related classes have to know internal details of each other, changes ripple through the system, and the system is potentially harder to understand July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  58. 58. Couplers : Feature Envy • A method in ClassA seems way too interested in the workings and data fields of ClassB. The feature envy from ClassA to ClassB is an indication of tight coupling from ClassA to ClassB • The usual fix is to try moving the functionality of the interested method in ClassA to ClassB, which is already closer to most of the data involved in the task July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  59. 59. Feature Envy : Example July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  60. 60. Couplers : Inappropriate Intimacy • When two classes exhibit an unhealthy fascination with each others bits, we call the Inappropriate Intimacy. Its essentially bi-directional feature envy • Two classes are coupled tightly to each other July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  61. 61. Couplers : Message Chains • Message Chains is a smell where class A needs data from class D. To access this data, class A needs to retrieve object C from object B (A and B have a direct reference). When class A gets object C it then asks C to get object D. When class A finally has a reference to class D, A asks D for the data it needs. • The problem here is that A becomes unnecessarily coupled to classes B, C, and D, when it only needs some piece of data from class D. • The following example illustrates the message chain smell: A.getB().getC().getD().getTheNeededData() July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  62. 62. Couplers : Middle Man • Represent a problem that might be created when trying to avoid high coupling with constant delegation. • Middle Man is a class that is doing too much simple delegation instead of really contributing to the application. July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  63. 63. Design Smell Immobility Opacity Rigidity Design Needless repetition Smell Fragility Needless Viscosity complexity July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  64. 64. SOLID STUFF • Single Responsibility Principle (SRP) • Open-Closed Principle (OCP) • Liskov Substitution Principle (LSP) • Interface Segregation Principle (ISP) • Dependency Inversion Principle (DIP) July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  65. 65. Cohesion and Coupling • Cohesion – How closely related are the different responsibilities of a module • Coupling – How much one module relies on another • Goal is low coupling and high cohesion July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  66. 66. Single Responsibility Principle (SRP) • A Class should have only one reason to change. Just because you can doesnt mean you should July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  67. 67. Responsibiltiy? • What a class does • The more a class does, the more likely it will change • The more a class changes, the more likely we will introduce bugs • Single Responsibility = increased cohesion July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  68. 68. Open-Closed Principle (OCP) Brain surgery is not needed when putting on a hat. July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  69. 69. Liskov Substitution Principle (LSP) If it looks like a duck, quacks like a duck but needs batteries - You probably have the wrong abstraction. July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  70. 70. Interface Segregation Principle (ISP) You want me to plug this in, Where? July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  71. 71. Dependency Inversion Principle (DIP) Would you solder a lamp directly to the electrical wiring in a wall? July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  72. 72. Architecture Smell • Smell in subsystems – No subsystems, too little subsystems, too large subsystems – Too many subsystems – Cycles in subsystems • Smells in layers – No layering – Upward references (cycles between the layers) – Breach of layers – Too many layers – References between vertical separated layers July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  73. 73. Remember Rather than construction, software is more like gardening – it is more organic than concrete. - Pragmatic Programmer July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  74. 74. Software Craftsmanship Manifesto July 12, 2012 © 2012 ProKarma | All Rights Reserved Confidential & Proprietary | www.prokarma.com
  75. 75. Reach Me @ mnadeem@prokarmasoftech.com 996-663-9709ProKarma Recognized by Inc. Magazine as the"Fastest-Growing IT Services Company in July 12, 2012 © 2012 ProKarma | All Rights ReservedAmerica” Confidential & Proprietary | www.prokarma.com

×