Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Clean Code Developer Yellow Grade

Clean Code Developer Yellow Grade

Learn the principles and practices of Clean Code Development. This is the second session in the Clean Code Development track. Go on with the next level and dig into Clean Code.

C5f6e8dffbb19acf405198c8fb917337?s=128

Mark Paluch

August 27, 2013
Tweet

More Decks by Mark Paluch

Other Decks in Programming

Transcript

  1. Clean Code Developer A way to better code Session 03

    https://github.com/mp911de/CCD Dienstag, 27. August 13
  2. Agenda • The Yellow Grade Dienstag, 27. August 13

  3. Yellow Grade Dienstag, 27. August 13

  4. Yellow Grade • Principles • Interface Segregation Principle (ISP) •

    Dependency Inversion Principle • Liskov Substitution Principle • Principle of Least Astonishment • Information Hiding Principle • Practices • Automated Unit Tests • Use Mocks • Code Coverage Analysis • Visit Conferences/Events • Complex Refactorings Dienstag, 27. August 13
  5. Interface Segregation Principle (ISP) • Interfaces hide implementations • Use

    Interfaces for decoupling • Use more small Interfaces, not one large • Coupling only between the really necessary parts • Less dependencies = easier to switch backend implementations • Every public class/method is an API Dienstag, 27. August 13
  6. Interface Segregation Principle, Bad Code public interface Animal { void

    fly(); void run(); void bark(); } public class Bird implements Animal { public void bark() { /* do nothing */ } public void run() { // write code about running of the bird } public void fly() { // write code about flying of the bird } } public class Cat implements Animal { public void fly() { throw new Exception("Undefined cat property"); } public void bark() { throw new Exception("Undefined cat property"); } public void run() { // write code about running of the cat } } public class Dog implements Animal { public void fly() { } public void bark() { // write code about barking of the dog } public void run() { // write code about running of the dog } } Dienstag, 27. August 13
  7. Interface Segregation Principle, Good Code public interface Flyable { void

    fly(); } public interface Runnable { void run(); } public interface Barkable { void bark(); } public class Bird implements Flyable, Runnable { public void run() { // write code about running of the bird } public void fly() { // write code about flying of the bird } } public class Cat implements Runnable{ public void run() { // write code about running of the cat } } Dienstag, 27. August 13
  8. Dependency Inversion Principle • Interfaces contain only the Interface-Details, not

    Impl-Details • Improved Testability • Mocking • Usage • Manually (constructors, setter) • IoC Containers (Dependency Injection) • Dependency Lookup Dienstag, 27. August 13
  9. Dependency Inversion Principle Rules • High-Level classes depend on Interfaces

    • High-Level classes should not depend on Low-Level classes • Low-Level classes depend on Interfaces Dienstag, 27. August 13
  10. Liskov Substitution Principle • Subtypes have to behave as their

    parent-type • Functions that use references to base classes must be able to use objects of derived classes without knowing it • Contravariance of method arguments in the subtype • Covariance of return types in the subtype • Think twice before deriving classes, how they will behave Dienstag, 27. August 13
  11. Liskov Substitution Principle Examples • Parent-Type does not define exceptions,

    subtype must not throw exceptions • Parent-Type allows a value range, subtype can extend the range but not limit it • Parent-Typ returns defines a return type, subtype can return a smaller data type but not a larger one Dienstag, 27. August 13
  12. Liskov Substitution Principle, Bad Code public interface Animal { void

    fly(); void run(); void bark(); } public class Bird implements Animal { public void run() { // write code about running of the bird } public void fly() { // write code about flying of the bird } public void bark() { /* do nothing */ } } public class Cat implements Animal { public void fly() { throw new Exception("Undefined cat method"); } public void run() { // write code about running of the cat } public void bark() { throw new Exception("Undefined cat method"); } } Dienstag, 27. August 13
  13. Principle of Least Astonishment • Don‘t let your code produce

    surprises • You expect Control-C to „Copy“, not to „Delete all files“ • „GetValue“ has to return a value, not changing something • Does your Method-Names/Class-Names tell the truth? • Ever met strange Code? Dienstag, 27. August 13
  14. Information Hiding Principle • Define a stable interface • Expose

    as little as possible • Expose as much as needed • Exposing too much (methods, data) leads to a tight coupling • Tight coupling prevents flexibility Dienstag, 27. August 13
  15. Automated Unit Tests • Unit Tests test a Unit •

    One Class/File/Module • Tests support QA, find Bugs before QA does • Tests create trust and confidence • Do you rule the code or does the code rule you? Dienstag, 27. August 13
  16. Test-Driven Development Rules • You are not allowed to write

    any production code unless it is to make a failing unit test pass • You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures • You are not allowed to write any more production code than is sufficient to pass the one failing unit test. Dienstag, 27. August 13
  17. Use Mocks • Mocks are dummies • Behave as you

    need it • Simulate Components/Remote Systems/Databases • No dependencies to external resources Dienstag, 27. August 13
  18. Mock Code Example FileService fileService = mock(FileService.class); when(fileService.fileExists(anyString())).thenReturn(true); verify(fileService).delete("file.txt"); Dienstag,

    27. August 13
  19. Code Coverage Analysis • How much Code is covered by

    Tests? • Do Tests fail, when you add Bugs? • Coverage Target: 100% • All Branches • All Exception Cases • 90% sufficient – other 10% would take 90% more time Dienstag, 27. August 13
  20. Visit Conferences/Events • Look what others do • Learn about

    new Trends – learn what not to do • Discuss different solution approaches • Broaden your horizon Dienstag, 27. August 13
  21. Complex Refactorings • Rename and Move are basic • Extract

    Method/Interface/Class • Replace Data with Object • Pull up/Push down Method/Field • Move Field/Method Dienstag, 27. August 13
  22. Image Credits Table of Contents: © by Michael Kappel http://michaelkappel.com

    Bands: © by Alexander Herzog Dienstag, 27. August 13