This talk goes through many of the Object-Oriented Programming principles and characteristics. Things that all developers should have in mind while writing code.

1. Software Craftsmanship by Sandro Mancuso Twitter: @sandromancuso http://www.londonswcraft.com How much do we know about OOP/OOD?

2. Inheritance >> Before we start What can we expect from this session?

3. Class Invariant >> Inheritance

4. public class Rectangle { private int height; private int width; public Rectangle( int height, int width) { this. height = height; this. width = width; } public int getHeight() { return this .height; } public void setHeight( int height) { this .height = height; } public int getWidth() { return this .width; } public void setWidth( int width) { this. width = width; } } public class Square extends Rectangle { public Square( int size) { super(size, size); } public int setHeight( int height) { return super. setHeight(height); } public int setWidth( int width) { return super. setWidth(width); } } What will happen when we call the setters? Class Invariant Invariant fix >>

6. “ Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. “ LSP violation public void drawShape(Shape s) { if (s instanceof Square) { drawSquare((Square) s); } else if (s instanceof Circle){ drawCircle((Circle) s); } } Liskov Substitution Principle - LSP Behavioral subtyping LSP violations >>

7. A more subtle violation of LSP Rectangle r = new Square(); r.setHeight(5); r.setWidth(6); Violations - Without the fix, Square would be in an invalid state when used as a Rectangle; - With the fix, the Square setter methods weaken (violate) Rectangle’s post conditions, which state that dimensions can be modified independently Liskov Substitution Principle - LSP Fixing the design >>

9. - Term was coined by Bertrand Meyer in 1986 Based on the mutual obligations and benefits principle. - Pre-condition : obligation for the client, benefit for the supplier - Post-condition : obligation for the supplier, benefit for the client - Invariant : Assumed on entry, guaranteed on exit Design by Contract DbC implications >>

11. - DbC : It’s the client’s responsibility (obligation) to respect supplier’s pre-condition. Code should “fail-hard” - Defensive Programming : Supplier takes the responsibility to validate pre-condition In both cases, client needs to take an action. DbC vs Defensive Programming - Whatever you do, don’t hide bugs. If a pre-condition is not met, let the system blow or let the client handle it. - Don’t code default behaviour unless this is part of the requirement. Side effect >>

15. Violation of POLA / POLS public class EventProcessor { public void processEvent(Event event) throws EventProcessorException { try { doSomethingWith(event); event.setState( PROCESSED ); // violation } catch (Exception e) { event.setState( FAILED ); // violation throw new EventProcessorException(e); } } } Possible undesired side effect. SRP >>

17. Single Responsibility Principle - SRP Where do things go wrong? - SRP violations are most seen in systems developed without TDD and refactoring. - Classes closer to the system interface have a more generic and broader responsibility - Failure do identify responsibility / delegation ratio Cohesion >>

18. Cohesion The cornerstone of Object-Oriented Programming Class level >> Cambridge Dictionary Cohesion (noun) : when the members of a group or society are united. Cohesive (adjective) : united and working together effectively. Wikipedia In computer programming, cohesion is a measure of how strongly-related and focused the various responsibilities of a software module are. LCOM4: Lack of Cohesion Methods (metrics used by Sonar)

21. God Object Coupling >>

22. Coupling Types >> Coupling or dependency is the degree to which each program module relies on each one of the other modules - Low coupling often correlates with high cohesion, and vice versa. - Sign of good design and well maintainable code.

25. Coupling – The ripple effect ISP >>

26. Interface Segregation Principle - ISP ISP >>

27. Interface Segregation Principle - ISP Role interface >>

30. Dependency Inversion Principle - DIP IoC & DI >> High and low-level modules now depend on an abstraction

33. Information Hiding & Protected Variation OCP >> Information Hiding : Hide information about the design from other modules, at the points of difficult or likely to change. David Parnas Information hiding is Protected Variation, not data encapsulation To minimise change impacts, we aim for low coupling. To design for low coupling, we design for protected variations. Craig Larman Protected Variation : Identify points of predicted variation and create a stable interface around them. Alistair Cockburn

36. Feature Envy Other topics >> public void doSomething() { BigDecimal baseMonthlySalary = employee.getBaseMontlySalary(); int overtimeInHours = employee.getOverTimeInHours(); BigDecimal overtimeHourRate = employee.getOvertimeHourRate(); BigDecimal salaryToBePaid = baseMonthlySalary + (overtimeInHours * overtimeHourRate); // Do more stuff with the salary } public void doSomething() { BigDecimal salaryToBePaid = employee.getMonthlySalaryToBePaid(); // Do more stuff with the salary } A better implementation

38. Wrap up There is always a good reason to break a rule or law, but it really needs to be a good one. The critical design tool for software development is a mind well educated in design principles. It is not the UML or any other technology Craig Larman Most software engineers don’t set out to create “bad designs”. Yet most software eventually degrades to the point where someone will declare the design to be unsound. Why does this happen? Was the design poor to begin with, or did the design actually degrade like a piece of rotten meat? At the heart of this issue is our lack of a good working definition of “bad” design . Uncle Bob Martin Questions >>

39. Questions London Software Craftsmanship Community – LSCC – http://www.londonswcraft.com Twitter: @sandromancuso