1. Башкирцев (Старовер) Станислав ctapobep@javatalks.ru JavaTalks OOD Principles

2. 2 План презентации Intro Don’t Repeat Yourself Open Closed Single Responsibility Interface Segregation Inversion of Control Liskov’s Substitution Q/A

3. 3 OOD Principles. What’s that? Recipes, best practices how to write Clean, easy to understand code Maintainable (flexible, extendable) code

4. DRY Don’t Repeat Yourself Don’t duplicate code

5. 5 Without DRY

6. If something changes?

7. With DRY

8. If something changes?

9. DRY Don’t Repeat Yourself Don’t duplicate code Names should be clear

10. Not clear names 1. No one would guess to look sorting method in this class. 2. Newbie always would write his own implementation.

11. Correct DRY clear, well-defined class names

12. DRY Don’t Repeat Yourself Don’t duplicate code Names should be clear Location should be clear

13. Not clear location No one would look for array utilities in such package

14. DRY. Pros & Cons Pros: Changes impact local area Once written is not repeated No ”new” error prone solutions Cons: Amount of classes grows

15. OCP Open Closed Principle - code should be closed for modification, but open for extension.

16. OCP. Example I want my clients to be able to see results of past games. Let’s keep up with NHL & NBA games.. 1. American customer 2. His thoughts 3. His ill imagination

17. OCP. Example Base class Creates specific objects according to...

18. OCP. Example Great! A lot of new clients, a lot of money from ads. But.. Would be great if my cliends would be able to get info about MLB games too!

19. OCP. Example New league was added We are changing already working class!

20. OCP. Example Why my clients see errors on every page?!! I pay you for work, not for errors! I loose my clients, make the program work right!

21. OCP. Example Element of array is compared with league name – NPE is possible!

22. OCP. Moral This example shows that changing code that already works is always bad idea. Follow OCP to escape this!

23. OCP. Example MlbSportInfoBuilder NbaSportInfoBuilder NhlSportInfoBuilder

24. OCP. Example Great! You job satisfies me! But now I want WNBA to be added

25. OCP. Example MlbSportInfoBuilder NbaSportInfoBuilder NhlSportInfoBuilder WnbaSportInfoBuilder New league was added without changing single line of code!

26. OCP. How it works OCP uses: Delegation Inheritance

27. OCP. Pros & Cons Pros: Adding new functionality without legacy code being changed Cons: May complicate system because of amount of classes being grown

28. SRP Single Responsibility Principle: Single class should have a single responsibility Class should have only one reason to change

29. SRP. Random thoughts Hm.. Strange that inflation is counted in CurrencyConverter.. Hm.. What if format of currency service changes? What if the format of inflation service changes? We’ll have to change this class in both cases! It’s not intuitive! It’s overloaded! We have to do something!

30. SRP. Separate Responsibilities Hm.. What if format of currency service changes? We change CurrencyConverter! Hm.. What if format of inflation service changes? We change InflationIndexCounter!

31. SRP & DRY Again two responsibilities: Authentication & getting user from database DRY violation!

32. SRP. Delegating responsibilities Now we don’t work directly with database! If we would want to use ORM, UserAuthenticator won’t change!

33. SRP. Pros & Cons Pros: Helps to follow DRY Lowers chances to change single class Class names correspond to what they do Cons: May complecate system by adding too much new classes

34. ISP Interface Segregation Principle – client code shouldn’t be obligated to depend on interfaces it doesn’t use.

35. ISP. Example Base interface of the person. All these methods are useful for current implementation of person.

36. ISP. Extra methods But we’re writting new module that considers a person only as a human being. So we need only one method eat() So our new implementation has two extra methods.

37. ISP. What these methods do?!

38. ISP. Fat/Polluted Interfaces It’s fat It’s POLLUTED

39. ISP. Interface Separating We separated Person into Person & Worker. Two conceptually different interfaces.

40. ISP. No extra methods Now we have only needed methods.

41. ISP. Legacy code What if we have ready implementation, but we don’t want to use fat interface?

42. ISP. Use Adapters Thin interface Fat interface

43. ISP. Pros & Cons Pros: No need to implement unnecessary methods Client code sees only what it should see Cons: Adding additional interfaces

44. IoCP Invertion of Control Principle says: Code to abstraction, not to implementation Objects that use other objects, shouldn’t create latter ones

45. IoCP. Coding to implementation

46. IoCP. How to test Crawler? It’s impossible to write unit test for Crawler, because you cannot mock parser.

47. IoCP. Let’s inject Now you can specify parser through constructor. You can inject dummy object while testing.

48. IoCP. Again doesn’t work Your parser doesn’t work with HTML that isn’t a valid XML!

49. IoCP. New Implementation HtmlParser DomBasedHtmlParser EnhancedHtmlParser

50. IoCP. But how do we replace? We cannot specify another implementaion!

51. IoCP. Let’s code to interface Now we use interface, so we can specify enhanced implementation of parser.

52. IoCP. Another look How do we inject objects if we work on framework/library? We cannot use IoC Containers, our clients don’t allow us extra dependencies, they don’t want to depend on Spring or Guice. We need leightweight decision.

53. IoCP. Let’s use Factories Let’s use Factories! Hm.. But we cannot write unit tests again!

54. IoCP. Let’s mix We have both: setter and factory in the same class. Now we have default implementation and possibility to change default behavior.

55. IoCP. Pros & Cons Pros: Classes don’t depend on concrete implementation Allows easily change implementation Allows write good unit tests Cons: Creating additional interfaces Creating Factories/depending on IoC containers

56. LSP Liskov’s Substitution Principle – derived types must be completely substitutable for their base types. LSP declares how to use inheritance correctly.

57. LSP. java.util.List Would be strange if these implementation would do different things here

58. LSP. Emu doesn’t fly! But emu doesn’t fly!

59. LSP. Emu indeed doesn’t fly Simply birds. Flying birds. Emu is simply a bird. It doesn’t have extra methods.

60. LSP. Array example Default implementation. It’s a temporal class that uses unefficient approach. But it does it’s work correctly.

61. LSP. Array example At last we wrote enhanced implementation that’s really efficient.

62. LSP. Again bugs! Your system always throws errors! It’s a chaos!!

63. LSP. Array example It sorts the original array! We have problems with synchronization. Implementation does its work, but it has side effects. It doesn’t satisfy interface contract! We cannot simply replace one implementation with another one, because they differ! We should correct its behaviour to copy original array and work with its copy.

64. LSP & equals() Colored point extends simple point and adds new field – color. But it works only with ColoredPoint!

65. LSP & equals This will print: true false This violates equals() contract! There is no correct dicision in this situation!

66. LSP & equals() The only correct way here is to use delegation instead of inheritance.

67. LSP & exceptions What if this method in our implementation threw IOException? How would we know about that? We work with interface List, not with implementation! That’s why Java doesn’t allow us to throw any checked exception that are not declared in base class.

68. LSP. Pros & Cons Pros: Allows not to think about concrete implementation, but code to abstraction Unambiguously defines contract all implementers should follow Allows to interchange implementation correctly, without side effects

69. The End Q/A