The document discusses object-oriented design principles and patterns. It covers topics like encapsulation, inheritance, polymorphism, the open-closed principle (OCP), dependency inversion, and architectural patterns like layered architectures and domain-driven design. Examples are provided to illustrate concepts like dependency injection and inversion of control. The conclusion emphasizes applying principles pragmatically based on user needs while aiming for maintainable code.

1. Agnès CREPET @agnes_crepet Cyril LACÔTE @clacote 1st November – Gunadarma University Once upon a -Design- Time Object Oriented Design principles

2. Schedule A bit of history What's a good object-oriented (OO) design? The main principles of the OO design Not an inventory of Design Patterns! Dependency Management Inversion of control Architecture patterns

3. A bit of history Open («file») Read: read (record) if (eof) go to End-File if (code == «INVOICE») go to Invoice if (code == «CREDIT») go to Credit if (code == «PROFORMAT») go to Read In the beginning : the Go To statement Invoice: Process invoice go to Computation Credit: Process credit go to Computation Computation: Read account Compute amount Update account go to Read: End-File: close («file»)

4. Beyond the GOTO « Go To Statement Considered Harmful » Edsger W. Dijkstra, 1968 Any program with a single input can be built only with the following structures: sequence (an ordered execution of statements) iterative statement : loop conditional statement : if – else, switch, case

5. Structured Programming Open («file») read (record) while (eof == false) if (record.code == «INVOICE») ProcessInvoice() else if ( record. code == «CREDIT») ProcessCredit() else continue end-if ReadAccount() ComputeAmount() UpdateAccount() read (record) end-while close («file») ex : C language Reusable functions Control structures Methodology ?

6. Top–down approach Approach by decomposition Break down the problem into subproblems Apply this same principle to each ones -> tree decomposition Divide and conquer

7. Top–down approach File opening File processing File closing Invoice processing Asset processing Amount processing AccountRead AmountCompute AccountUpdate Amount processing... While there are records

8. Top–down approach Warnier's Method (1974) Used in loads of huge COBOL programs Good reliability in the writing of programs But very low evolutivity : Does not highlight the code to reuse Any change requires modification of all programs

9. Modularity Code reusability Function Module Sub-Module Requires a strict separation Data / Processing FORTRAN 58, ALGOL 60, PASCAL 70, C 73

10. Towards Encapsulation Weak coupling between data and processing structures Development no longer driven by processing Unlike COBOL-related methodologies Consecration: object paradigm!

11. Objet Paradigm : kind of old ! 60s : research at MIT lab Modula : 1967 SmallTalk : 1972 C++ : 1981 Java : 1995

12. Objet : motivations A basic idea : Close to the real world Abstraction start( ) accelerate( ) velocity mark Car

13. Why the object paradigm? Maintainable Flexible Extensible Project costs: 15% development 70% maintenance ! Doc Design Test Code Other Maintenance Source: DP Budget, Vol. 7, Dec 1998.

14. Objet Oriented design Design challenges : Build a system capable of evolving By maximizing the reuse To improve both quality and productivity Easy maintenance !

15. A good Objet Oriented design? No absolute solution: Principles rather than rules Methodological practices Acknowledged architectures Tried and tested recipes: Design Patterns

16. Design Patterns Named pair "problem / solution" Typical relationships between classes To Design what Algorithms are to Development 23 historical patterns: Gang of Four (GoF) : Erich Gamma, Richard Helm, Ralph Johson, John Wlissides, "Design Pattern. Elements of Reusable Object-oriented sofware", 1995

17. The idea of Design Patterns Loads of long lists everywhere tedious, boring : not needed here Rather try to understand the challenges!

18. The challenge of the Design Patterns "Not Invented Here" syndrome (NIH) Formalize an expertise Accessible to a non-expert Facilitate communication: a common language Designed for reuse and maintenance Language-agnostic Implement general principles

19. A basic principle : OCP (1/2) Open - Close Principle (OCP) Each software entities (classes, modules, functions, etc.) should be : open to extensions add new behaviors -> Adapt to change ! but closed to modifications Existing code cannot be changed, only additions are allowed. -> Do not break what works!

20. A basic principle : OCP (2/2) Not a foolproof recipe But a philosophy to reach for maintainable software. All other principles are just applications of this basic principle.

21. KISS : Keep It Simple, Stupid ! Simplicity is a key factor Simple code is : Quicker to write Less buggy Easier to understand and maintain Good design principles

22. DRY : Don't Repeat Yourself “ Single source of Truth” Avoid code repetitions Single out abstractions YAGNI : You Ain't Gonna Need It ! Never foresee a future need Single out pragmatic design Good Design Principles

23. Fundamental features : Encapsulation Inheritance Polymorphism Elementary frames for good design principles Object's foundations

24. Encapsulation « Black box » objects Interface : What I know What I can do Implementation: None of your business ! Go ! Brake ! To the left !

25. Encapsulation Hides implementation details Encapsulated data : Private attributes Outside world can't manipulate it Public methods : Service provided to outside Defined (and only!) access points

26. Encapsulation Pros : Ensures data integrity Enables to change implementation Reduces side-effects DEMO!

27. Inheritance Sharing common characteristics Both attributes & behaviors Generalization Specialization Person name : String eat() Employee name : String employer : String eat() work() Person name : String eat() Employee employer : String work()

28. Polymorphism A method invocation : Triggers different behavior according to type Implementation is chosen by targeted object Objects have to collaborate : without knowing their actual type using one of same type the same way

29. Interface : a set of public abstract methods implemented by various classes Think “service contract” Polymorphism without inheritance How polymorphism could be a solution for OCP challenge? Polymorphism's way to reach OCP DEMO!

30. Following upper principles Like a vain wish... Code can't be fully closed Choose violation strategically Estimate change probability OCP is an utopian goal to reach a condition for re-usability in an ever-changing context

31. Responsibilities assignment

32. How to assign responsibilities to classes Who do what? What is a responsibility? Knowing (other objects, computation results, ...) Doing (use, collaborate, coordinate, ...) -> General Responsibility Assignment Software Patterns [Graig Larman, "Applying UML and Patterns", 1998] Responsibilities assignment

33. G.R.A.S.P : Information Expert Which class should I give a responsibility to ? -> Give it to the object having enough information to assume it. "Knowing is doing” It's the elementary principle

34. G.R.A.S.P : Creator Which class should instantiate a given class ? -> Give to B the responsibility of creating A if B contains/aggregates instances of A B has initializing information for A B closely uses A If necessary, information required for creating A instances might be given to B.

35. G.R.A.S.P. : Low coupling (1/2) Evaluates interdependency between components

36. High coupling is a disadvantage : Understandability, maintainability, reusability Matters when you use an unstable component. But being strongly coupled to a stable component is not an issue. G.R.A.S.P. : Low coupling (2/2)

37. G.R.A.S.P. : High cohesion Responsibilities of a given component should be strongly related. Cohesion drops when: Class responsibilities are not focused A responsibility is dispatched onto several classes Just do your job !

38. Watch for the fat ! Obesity: If responsibilities are diluted Coupling rises for assuming it A code change will impact other functionalities Low coupling / High cohesion are intimately linked Higher cohesion -> lower coupling

39. So? How to ensure low coupling and high cohesion?

40. Dependency management Inversion of control

41. There will be consequences Dependency A -> B Impossible to deploy A without B reuse A without B A modification on B has side-effect on A needs A to be recompiled A A A uses is linked to inherits of B B B

42. Dependency: a strategic move ! A B A B ? or ? Dependencies have to be sorted out Especially when their number increases More classes -> More dependencies! Aim at low coupling (always!)

43. Dependency Inversion Principle High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. [Robert C. Martin,"Object Oriented Design Quality Metrics", 1995] An application's added value comes from business! Dangerous to impact business layers if technical layers have to be changed.

44. DIP : put into play Business components and interface are high-level objects Construction approach : Specify needs of high-level components example : save in DB Define those needs through interfaces example : interface Persistence Implement this interface in low-level modules coupled with DB drivers

45. Inversion of control : principle Hollywood principle : “ Don't call us, we'll call you” Inversion of control is a generic word. Several usages The most famous : dependency injection Objects won't seek their dependencies They will be provided by a third-party

46. Inversion of control : put into play A bean container can inject those dependencies, at instantiation time though constructor parameters, or through property setters after instantiation That what “light” containers do : Spring, Guice, Weld

47. Dependency injection : example Example : Mario has a suit... Three approaches : 1 - Elementary, without injection 2 - With manual injection 3 - With container injection

48. 1 - Elementary : without injection package com.injection.none; import com.injection.none.BlueSuit; public class JMario { private BlueSuit bluesuit = new BlueSuit(); public void onActionButton() { bluesuit.execute(this); } } Use: JMario j Mario = new JMario (); j Mario .onActionButton();

49. 1 - Without injection : Appraisal Closed modeling Mario can only have a suit High coupling (connection, creation, use) Dependency to the blue suit Inability to change without recompiling Mario

50. 2 - Manual injection package com.injection.with; public class JMario { private Suit suit; public void onActionButton (){ suit.execute(this); } public void setSuit(Suit suit) { t his.suit = suit; } } Use : JMario jMario = new JMario(); Suit blueSuit = new BlueSuit(); jMario.setSuit(blueSuit); jMario. onActionButton ();

51. 2 - Manual injection : Appraisal Pros: Mario exposes its dependency through the setter No dependency to implementations It could wear any suit Cons: The use is frozen (recompilation required to change the suit)

52. 3 - Injection with a container Modeling is the same Only the use changes: XML configuration or through annotations Context loading Suit retrieving

53. 3 - Injection with a container XML configuration (example : Spring) : <beans> <bean id=&quot;theBlueSuit&quot; class=&quot;com.injection.with.suit.BlueSuit&quot; /> <bean id=&quot;mario&quot; class=&quot;com.injection.with.JMario&quot;> < property name=&quot;suit&quot; ref=&quot; theBlueSuit &quot; /> </bean> </beans> Configuration by annotations (JEE6): public class JMario { @Inject private Suit suit; }

54. 3 - Injection with a container : Appraisal Same benefits as manual injection Everything is parameterized you still have to configure the injection! Centralized in XML Type-safe with annotations It is not even necessary to recompile with XML configuration

55. Inversion of control : conclusion Low coupling Easy to replace components Simplified maintenance Implementations are independent of use context Reusable components Modular and incremental development Simplified tests: Dependencies already isolated Mock-objects

56. In vogue Design Patterns Convention over Configuration

57. Convention over configuration By convention, a framework works with a default configuration (suitable for common needs) Less configuration files Simplification Use of annotations Java EE 6 trends EJB 3.1 as simple as possible : @Stateless public class SimpleSample { public void doSomething() { /*business logic*/ } }

58. Architectural Patterns 2 big families

59. Application Architecture : Example Java web Application Application layers (presentation, service, business… HTML/ JavaScript HTTP … and persistence) JDBC Browser Application Server (ex : JBoss) DataBase Server (Ex: Oracle) Application Outside (Company Information system) ? RDBMS

60. Architectural Patterns Driven by Service (SOA) Service-Oriented Architecture Information System is a group of services Driven by Domain (DDD) Domain-Driven Design Both based on the same pattern ECB Entity Control Boundary Similar to MCV (Model View Controller) Pattern But not dedicated to presentation layer

61. Lean Service Oriented Architecture (SOA) Control (Business services / repositories) is the main component Anemic Object Model No Business logic Strict image of DB (POJO) Mainly procedural programming J2EE leaded to forget about OO programming! Facades Business Services Repository RDBMS Domain Objects

62. Domain Driven Architecture Domain Entities are the corner stone of the application manage their state and their state's persistence and implement business logic -> PDO (Persistent Domain Object) Services (Control) lose application logic Perhaps not needed anymore! Repository SGBDR Domain Object

63. Conclusion

64. Conclusion Answers? No miracle recipes.. Familiarize with those principles to raise the good questions Design patterns are not mandatory Tackle to user needs first then with an added value (maintainability always !) Lead to a design-driven approach New development cycles Agile methodologies Stay humble, But think big !

65. Bibliography

66. Source Code on GitHub https://github.com/acrepet/JMarioGame

67. Bibliography Design Patterns - Catalogue des modèles de conceptions réutilisables [GOF] , Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides ; Vuibert; Juillet 1997 ; ISBN: 2-7117-8644-7 Design Patterns CD - Elements of Reusable Object-Oriented Software De Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides - Addison Wesley Mai 1998 - Refactoring to patterns , J. Kerievsky ; Addison Wesley; Septembre 2004 ; ISBN: 2-7117-8644-7

68. Bibliography Patterns of Enterprise Application Architecture [PEAA] de Martin Fowler – 2002 – Hardcover Refactoring : Improving the Design of Existing Code de Martin. Fowler - 1999 [PEAA] - Addison-Wesley

69. Bibliography &quot;Real World Java EE Night Hacks - Dissecting the Business Tier&quot; Adam Bien – 2009 - Press Adam Biem &quot;Real World Java EE Patterns - Rethinking Best Practices &quot; Adam Bien – 2011- Press Adam Bien

70. Bibliography : websites Jon Pearce website about patterns: http://www.cs.sjsu.edu/~pearce/modules/patterns/index.htm Martin Fowler website: http://martinfowler.com Adam Bien website: http://www.adam-bien.com About &quot;Domain-Driven Design&quot; approach : http://domaindrivendesign.org