Agnès CREPET @agnes_crepet Cyril LACÔTE @clacote 1st November – Gunadarma University Once upon a -Design- Time Object Orie...
Schedule <ul><li>A bit of history </li></ul><ul><li>What's a good object-oriented (OO) design? </li></ul><ul><li>The main ...
A bit of history <ul><li>Open («file») </li></ul><ul><li>Read: </li></ul><ul><li>read (record)  </li></ul><ul><li>if (eof)...
Beyond the GOTO <ul><li>« Go To Statement Considered Harmful » </li></ul><ul><ul><li>Edsger W. Dijkstra, 1968 </li></ul></...
Structured Programming <ul><li>Open («file») </li></ul><ul><li>read (record) </li></ul><ul><li>while  (eof == false) </li>...
Top–down approach <ul><li>Approach by decomposition </li></ul><ul><ul><li>Break down the problem into subproblems </li></u...
Top–down approach File opening File processing File closing Invoice processing Asset processing Amount processing AccountR...
Top–down approach <ul><li>Warnier's Method (1974) </li></ul><ul><ul><li>Used in  loads  of  huge  COBOL programs </li></ul...
Modularity <ul><li>Code reusability </li></ul><ul><ul><li>Function </li></ul></ul><ul><ul><li>Module </li></ul></ul><ul><u...
Towards Encapsulation <ul><li>Weak coupling between data and processing structures </li></ul><ul><li>Development no longer...
Objet Paradigm : kind of old ! <ul><li>60s : research at MIT lab </li></ul><ul><li>Modula : 1967 </li></ul><ul><li>SmallTa...
Objet : motivations <ul><li>A basic idea : </li></ul><ul><ul><li>Close to the real world </li></ul></ul>Abstraction start(...
Why the object paradigm? <ul><li>Maintainable </li></ul><ul><li>Flexible </li></ul><ul><li>Extensible </li></ul><ul><li>Pr...
Objet Oriented design <ul><li>Design challenges : </li></ul><ul><ul><li>Build a system capable of evolving </li></ul></ul>...
A good Objet Oriented design? <ul><li>No absolute solution: </li></ul><ul><ul><li>Principles rather than rules </li></ul><...
Design Patterns <ul><li>Named pair &quot;problem / solution&quot; </li></ul><ul><ul><li>Typical relationships between clas...
The idea of Design Patterns <ul><li>Loads of long lists everywhere </li></ul><ul><ul><li>tedious, boring : not needed here...
The challenge of the Design Patterns <ul><li>&quot;Not Invented Here&quot; syndrome (NIH) </li></ul><ul><li>Formalize an e...
A basic principle : OCP (1/2) <ul><li>Open - Close Principle (OCP) </li></ul><ul><li>Each software entities (classes, modu...
A basic principle : OCP (2/2) <ul><li>Not a foolproof recipe </li></ul><ul><li>But a philosophy to reach for maintainable ...
<ul><li>KISS : Keep It Simple, Stupid ! </li></ul><ul><ul><li>Simplicity is a key factor </li></ul></ul><ul><ul><li>Simple...
<ul><li>DRY : Don't Repeat Yourself </li></ul><ul><ul><li>“ Single source of Truth” </li></ul></ul><ul><ul><li>Avoid code ...
<ul><li>Fundamental features : </li></ul><ul><ul><li>Encapsulation </li></ul></ul><ul><ul><li>Inheritance </li></ul></ul><...
Encapsulation <ul><li>« Black box » objects </li></ul><ul><ul><li>Interface : </li></ul></ul><ul><ul><ul><li>What I know <...
Encapsulation <ul><li>Hides implementation details </li></ul><ul><li>Encapsulated data : </li></ul><ul><ul><li>Private att...
Encapsulation <ul><li>Pros : </li></ul><ul><ul><li>Ensures data integrity </li></ul></ul><ul><ul><li>Enables to change imp...
Inheritance <ul><li>Sharing common characteristics </li></ul><ul><ul><li>Both attributes & behaviors </li></ul></ul>Genera...
Polymorphism <ul><li>A method invocation : </li></ul><ul><ul><li>Triggers different behavior according to type </li></ul><...
<ul><li>Interface : </li></ul><ul><ul><li>a set of public abstract methods </li></ul></ul><ul><ul><li>implemented by vario...
Following upper principles <ul><li>Like a vain wish... </li></ul><ul><ul><li>Code can't be fully closed </li></ul></ul><ul...
Responsibilities assignment
<ul><li>How to assign responsibilities to classes </li></ul><ul><ul><li>Who do what? </li></ul></ul><ul><li>What is a resp...
G.R.A.S.P : Information Expert <ul><li>Which class should I give a responsibility to ? </li></ul><ul><ul><li>->  Give it t...
G.R.A.S.P : Creator <ul><li>Which class should instantiate a given class ? </li></ul><ul><ul><li>->  Give to B the respons...
G.R.A.S.P. : Low coupling (1/2) <ul><li>Evaluates interdependency between components </li></ul>
<ul><li>High coupling is a disadvantage : </li></ul><ul><ul><li>Understandability, maintainability, reusability </li></ul>...
G.R.A.S.P. : High cohesion <ul><li>Responsibilities of a given component should be strongly related. </li></ul><ul><li>Coh...
Watch for the fat ! <ul><li>Obesity: </li></ul><ul><ul><li>If responsibilities are diluted </li></ul></ul><ul><ul><li>Coup...
So? How to ensure low coupling and high cohesion?
Dependency management Inversion of control
There will be consequences <ul><li>Dependency A -> B </li></ul><ul><li>Impossible to </li></ul><ul><ul><li>deploy A withou...
Dependency: a strategic move ! A B A B ? or ? <ul><li>Dependencies have to be sorted out </li></ul><ul><li>Especially when...
Dependency Inversion Principle <ul><li>High-level modules should not depend on low-level modules. Both should depend on ab...
DIP : put into play <ul><li>Business components and interface are high-level objects </li></ul><ul><li>Construction approa...
Inversion of control : principle <ul><li>Hollywood principle : </li></ul><ul><ul><li>“ Don't call us, we'll call you” </li...
Inversion of control : put into play <ul><li>A bean container can inject those dependencies, at instantiation time </li></...
Dependency injection : example <ul><li>Example : </li></ul><ul><ul><li>Mario has a suit... </li></ul></ul><ul><li>Three ap...
1 - Elementary : without injection <ul><li>package com.injection.none; </li></ul><ul><li>import com.injection.none.BlueSui...
1 - Without injection : Appraisal <ul><li>Closed modeling  </li></ul><ul><ul><li>Mario can only have a suit </li></ul></ul...
2 - Manual injection <ul><li>package com.injection.with; </li></ul><ul><li>public class JMario { </li></ul><ul><li>private...
2 - Manual injection : Appraisal <ul><li>Pros: </li></ul><ul><ul><li>Mario exposes its dependency through the setter </li>...
3 - Injection with a container <ul><li>Modeling is the same </li></ul><ul><li>Only the use changes: </li></ul><ul><ul><li>...
3 - Injection with a container <ul><li>XML configuration (example : Spring) : </li></ul><ul><li><beans> </li></ul><ul><li>...
3 - Injection with a container : Appraisal <ul><li>Same benefits as manual injection </li></ul><ul><li>Everything is param...
Inversion of control : conclusion <ul><li>Low coupling </li></ul><ul><ul><li>Easy to replace components </li></ul></ul><ul...
In vogue Design Patterns Convention over Configuration
Convention over configuration <ul><li>By convention, a framework works with a default configuration (suitable for common n...
Architectural Patterns 2 big families
Application Architecture : Example Java web Application Application layers  (presentation, service, business… HTML/ JavaSc...
Architectural Patterns <ul><li>Driven by Service (SOA) </li></ul><ul><ul><li>Service-Oriented Architecture </li></ul></ul>...
Lean Service Oriented Architecture (SOA) <ul><li>Control (Business services / repositories) is the main component </li></u...
Domain Driven Architecture <ul><li>Domain Entities are the corner stone of the application  </li></ul><ul><ul><li>manage t...
Conclusion
Conclusion <ul><li>Answers?  </li></ul><ul><ul><li>No miracle recipes.. </li></ul></ul><ul><li>Familiarize with those prin...
Bibliography
Source Code on GitHub https://github.com/acrepet/JMarioGame
Bibliography  <ul><ul><li>Design Patterns - Catalogue des modèles de conceptions réutilisables [GOF] , Erich Gamma, Richar...
Bibliography <ul><li>Patterns of Enterprise Application Architecture [PEAA] de Martin Fowler – 2002 – Hardcover </li></ul>...
Bibliography <ul><ul><li>&quot;Real World Java EE Night Hacks - Dissecting the Business Tier&quot; </li></ul></ul><ul><ul>...
Bibliography : websites <ul><li>Jon Pearce website about patterns:  </li></ul><ul><ul><li>http://www.cs.sjsu.edu/~pearce/m...
Upcoming SlideShare
Loading in …5
×

Design poo my_jug_en_ppt

580 views

Published on

Talk about Design Patterns for Malaysian JUG (Kuala Lumpur talk) and Jakarta JUG (Gunadarma Univerty talk - Depok)

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
580
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Commentaires
  • Dijkstra : « plus court chemin » dans un graphe, algorithme du banquier, sémaphore.
  • Polymorphisme d&apos;héritage = Polymorphisme d&apos;inclusion  redéfinition/spécialisation de méthodes durant l&apos;héritage (overriding) Polymorphisme paramétrable  Les types génériques, introduits avec Java 5, donnent la possibilité de ne pas devoir contrôler le type d&apos;une valeur lors de l&apos;exécution, ils permettent de définir des comportements communs sur des objets sans devoir les typer Polymorphisme ad hoc = surcharge de méthodes (overloading)  capacité de distinguer des opérations par la signature (avec types et arguments différents) plutôt que par le seul nom
  • une configuration par défaut (convention par règle de nommage) mais permettront aussi la substitution des valeurs par défaut via la configuration (à partir des fichiers ou une autre source de données).
  • Expliquer l’origine historique du concept : issu de l’architecture de bâtiments.
  • Design poo my_jug_en_ppt

    1. 1. Agnès CREPET @agnes_crepet Cyril LACÔTE @clacote 1st November – Gunadarma University Once upon a -Design- Time Object Oriented Design principles
    2. 2. Schedule <ul><li>A bit of history </li></ul><ul><li>What's a good object-oriented (OO) design? </li></ul><ul><li>The main principles of the OO design </li></ul><ul><ul><li>Not an inventory of Design Patterns! </li></ul></ul><ul><li>Dependency Management </li></ul><ul><ul><li>Inversion of control </li></ul></ul><ul><li>Architecture patterns </li></ul>
    3. 3. A bit of history <ul><li>Open («file») </li></ul><ul><li>Read: </li></ul><ul><li>read (record) </li></ul><ul><li>if (eof) </li></ul><ul><li>go to End-File </li></ul><ul><li>if (code == «INVOICE») </li></ul><ul><li>go to Invoice </li></ul><ul><li>if (code == «CREDIT») </li></ul><ul><li>go to Credit </li></ul><ul><li>if (code == «PROFORMAT») </li></ul><ul><li>go to Read </li></ul>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. 4. Beyond the GOTO <ul><li>« Go To Statement Considered Harmful » </li></ul><ul><ul><li>Edsger W. Dijkstra, 1968 </li></ul></ul><ul><li>Any program with a single input can be built only with the following structures: </li></ul><ul><ul><li>sequence (an ordered execution of statements) </li></ul></ul><ul><ul><li>iterative statement : loop </li></ul></ul><ul><ul><li>conditional statement : if – else, switch, case </li></ul></ul>
    5. 5. Structured Programming <ul><li>Open («file») </li></ul><ul><li>read (record) </li></ul><ul><li>while (eof == false) </li></ul><ul><li>if (record.code == «INVOICE») </li></ul><ul><li>ProcessInvoice() </li></ul><ul><li>else if ( record. code == «CREDIT») </li></ul><ul><li>ProcessCredit() </li></ul><ul><li>else </li></ul><ul><li>continue </li></ul><ul><li>end-if </li></ul><ul><li>ReadAccount() </li></ul><ul><li>ComputeAmount() </li></ul><ul><li>UpdateAccount() </li></ul><ul><li>read (record) </li></ul><ul><li>end-while </li></ul><ul><li>close («file») </li></ul>ex : C language Reusable functions Control structures Methodology ?
    6. 6. Top–down approach <ul><li>Approach by decomposition </li></ul><ul><ul><li>Break down the problem into subproblems </li></ul></ul><ul><ul><li>Apply this same principle to each ones </li></ul></ul><ul><ul><li>-> tree decomposition </li></ul></ul>Divide and conquer
    7. 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. 8. Top–down approach <ul><li>Warnier's Method (1974) </li></ul><ul><ul><li>Used in loads of huge COBOL programs </li></ul></ul><ul><li>Good reliability in the writing of programs </li></ul><ul><li>But very low evolutivity : </li></ul><ul><ul><li>Does not highlight the code to reuse </li></ul></ul><ul><ul><li>Any change requires modification of all programs </li></ul></ul>
    9. 9. Modularity <ul><li>Code reusability </li></ul><ul><ul><li>Function </li></ul></ul><ul><ul><li>Module </li></ul></ul><ul><ul><li>Sub-Module </li></ul></ul><ul><li>Requires a strict separation </li></ul><ul><ul><li>Data / Processing </li></ul></ul><ul><li>FORTRAN 58, ALGOL 60, PASCAL 70, C 73 </li></ul>
    10. 10. Towards Encapsulation <ul><li>Weak coupling between data and processing structures </li></ul><ul><li>Development no longer driven by processing </li></ul><ul><li>Unlike COBOL-related methodologies </li></ul><ul><li>Consecration: object paradigm! </li></ul>
    11. 11. Objet Paradigm : kind of old ! <ul><li>60s : research at MIT lab </li></ul><ul><li>Modula : 1967 </li></ul><ul><li>SmallTalk : 1972 </li></ul><ul><li>C++ : 1981 </li></ul><ul><li>Java : 1995 </li></ul>
    12. 12. Objet : motivations <ul><li>A basic idea : </li></ul><ul><ul><li>Close to the real world </li></ul></ul>Abstraction start( ) accelerate( ) velocity mark Car
    13. 13. Why the object paradigm? <ul><li>Maintainable </li></ul><ul><li>Flexible </li></ul><ul><li>Extensible </li></ul><ul><li>Project costs: </li></ul><ul><ul><li>15% development </li></ul></ul><ul><ul><li>70% maintenance ! </li></ul></ul>Doc Design Test Code Other Maintenance Source: DP Budget, Vol. 7, Dec 1998.
    14. 14. Objet Oriented design <ul><li>Design challenges : </li></ul><ul><ul><li>Build a system capable of evolving </li></ul></ul><ul><ul><li>By maximizing the reuse </li></ul></ul><ul><ul><li>To improve both quality and productivity </li></ul></ul><ul><li>Easy maintenance ! </li></ul>
    15. 15. A good Objet Oriented design? <ul><li>No absolute solution: </li></ul><ul><ul><li>Principles rather than rules </li></ul></ul><ul><ul><li>Methodological practices </li></ul></ul><ul><ul><li>Acknowledged architectures </li></ul></ul><ul><ul><li>Tried and tested recipes: Design Patterns </li></ul></ul>
    16. 16. Design Patterns <ul><li>Named pair &quot;problem / solution&quot; </li></ul><ul><ul><li>Typical relationships between classes </li></ul></ul><ul><ul><li>To Design what Algorithms are to Development </li></ul></ul><ul><li>23 historical patterns: </li></ul><ul><ul><li>Gang of Four (GoF) : Erich Gamma, Richard Helm, Ralph Johson, John Wlissides, &quot;Design Pattern. Elements of Reusable Object-oriented sofware&quot;, 1995 </li></ul></ul>
    17. 17. The idea of Design Patterns <ul><li>Loads of long lists everywhere </li></ul><ul><ul><li>tedious, boring : not needed here </li></ul></ul><ul><li>Rather try to understand the challenges! </li></ul>
    18. 18. The challenge of the Design Patterns <ul><li>&quot;Not Invented Here&quot; syndrome (NIH) </li></ul><ul><li>Formalize an expertise </li></ul><ul><li>Accessible to a non-expert </li></ul><ul><li>Facilitate communication: a common language </li></ul><ul><li>Designed for reuse and maintenance </li></ul><ul><li>Language-agnostic </li></ul><ul><li>Implement general principles </li></ul>
    19. 19. A basic principle : OCP (1/2) <ul><li>Open - Close Principle (OCP) </li></ul><ul><li>Each software entities (classes, modules, functions, etc.) should be : </li></ul><ul><ul><li>open to extensions </li></ul></ul><ul><ul><ul><li>add new behaviors </li></ul></ul></ul><ul><ul><ul><li>-> Adapt to change ! </li></ul></ul></ul><ul><ul><li>but closed to modifications </li></ul></ul><ul><ul><ul><li>Existing code cannot be changed, only additions are allowed. </li></ul></ul></ul><ul><ul><ul><li>-> Do not break what works! </li></ul></ul></ul>
    20. 20. A basic principle : OCP (2/2) <ul><li>Not a foolproof recipe </li></ul><ul><li>But a philosophy to reach for maintainable software. </li></ul><ul><li>All other principles are just applications of this basic principle. </li></ul>
    21. 21. <ul><li>KISS : Keep It Simple, Stupid ! </li></ul><ul><ul><li>Simplicity is a key factor </li></ul></ul><ul><ul><li>Simple code is : </li></ul></ul><ul><ul><ul><li>Quicker to write </li></ul></ul></ul><ul><ul><ul><li>Less buggy </li></ul></ul></ul><ul><ul><ul><li>Easier to understand and maintain </li></ul></ul></ul>Good design principles
    22. 22. <ul><li>DRY : Don't Repeat Yourself </li></ul><ul><ul><li>“ Single source of Truth” </li></ul></ul><ul><ul><li>Avoid code repetitions </li></ul></ul><ul><ul><li>Single out abstractions </li></ul></ul><ul><li>YAGNI : You Ain't Gonna Need It ! </li></ul><ul><ul><li>Never foresee a future need </li></ul></ul><ul><ul><li>Single out pragmatic design </li></ul></ul>Good Design Principles
    23. 23. <ul><li>Fundamental features : </li></ul><ul><ul><li>Encapsulation </li></ul></ul><ul><ul><li>Inheritance </li></ul></ul><ul><ul><li>Polymorphism </li></ul></ul><ul><li>Elementary frames for good design principles </li></ul>Object's foundations
    24. 24. Encapsulation <ul><li>« Black box » objects </li></ul><ul><ul><li>Interface : </li></ul></ul><ul><ul><ul><li>What I know </li></ul></ul></ul><ul><ul><ul><li>What I can do </li></ul></ul></ul><ul><ul><li>Implementation: </li></ul></ul><ul><ul><ul><li>None of your business ! </li></ul></ul></ul>Go ! Brake ! To the left !
    25. 25. Encapsulation <ul><li>Hides implementation details </li></ul><ul><li>Encapsulated data : </li></ul><ul><ul><li>Private attributes </li></ul></ul><ul><ul><li>Outside world can't manipulate it </li></ul></ul><ul><li>Public methods : </li></ul><ul><ul><li>Service provided to outside </li></ul></ul><ul><ul><li>Defined (and only!) access points </li></ul></ul>
    26. 26. Encapsulation <ul><li>Pros : </li></ul><ul><ul><li>Ensures data integrity </li></ul></ul><ul><ul><li>Enables to change implementation </li></ul></ul><ul><ul><li>Reduces side-effects </li></ul></ul>DEMO!
    27. 27. Inheritance <ul><li>Sharing common characteristics </li></ul><ul><ul><li>Both attributes & behaviors </li></ul></ul>Generalization Specialization Person name : String eat() Employee name : String employer : String eat() work() Person name : String eat() Employee employer : String work()
    28. 28. Polymorphism <ul><li>A method invocation : </li></ul><ul><ul><li>Triggers different behavior according to type </li></ul></ul><ul><ul><li>Implementation is chosen by targeted object </li></ul></ul><ul><li>Objects have to collaborate : </li></ul><ul><ul><li>without knowing their actual type </li></ul></ul><ul><ul><li>using one of same type the same way </li></ul></ul>
    29. 29. <ul><li>Interface : </li></ul><ul><ul><li>a set of public abstract methods </li></ul></ul><ul><ul><li>implemented by various classes </li></ul></ul><ul><li>Think “service contract” </li></ul><ul><li>Polymorphism without inheritance </li></ul><ul><li>How polymorphism could be a solution for OCP challenge? </li></ul>Polymorphism's way to reach OCP DEMO!
    30. 30. Following upper principles <ul><li>Like a vain wish... </li></ul><ul><ul><li>Code can't be fully closed </li></ul></ul><ul><ul><li>Choose violation strategically </li></ul></ul><ul><li>Estimate change probability </li></ul><ul><li>OCP is an utopian goal to reach </li></ul><ul><ul><li>a condition for re-usability in an ever-changing context </li></ul></ul>
    31. 31. Responsibilities assignment
    32. 32. <ul><li>How to assign responsibilities to classes </li></ul><ul><ul><li>Who do what? </li></ul></ul><ul><li>What is a responsibility? </li></ul><ul><ul><li>Knowing (other objects, computation results, ...) </li></ul></ul><ul><ul><li>Doing (use, collaborate, coordinate, ...) </li></ul></ul><ul><li>-> General Responsibility Assignment Software Patterns </li></ul><ul><ul><li>[Graig Larman, &quot;Applying UML and Patterns&quot;, 1998] </li></ul></ul>Responsibilities assignment
    33. 33. G.R.A.S.P : Information Expert <ul><li>Which class should I give a responsibility to ? </li></ul><ul><ul><li>-> Give it to the object having enough information to assume it. </li></ul></ul><ul><li>&quot;Knowing is doing” </li></ul><ul><ul><li>It's the elementary principle </li></ul></ul>
    34. 34. G.R.A.S.P : Creator <ul><li>Which class should instantiate a given class ? </li></ul><ul><ul><li>-> Give to B the responsibility of creating A if </li></ul></ul><ul><ul><ul><li>B contains/aggregates instances of A </li></ul></ul></ul><ul><ul><ul><li>B has initializing information for A </li></ul></ul></ul><ul><ul><ul><li>B closely uses A </li></ul></ul></ul><ul><ul><li>If necessary, information required for creating A instances might be given to B. </li></ul></ul>
    35. 35. G.R.A.S.P. : Low coupling (1/2) <ul><li>Evaluates interdependency between components </li></ul>
    36. 36. <ul><li>High coupling is a disadvantage : </li></ul><ul><ul><li>Understandability, maintainability, reusability </li></ul></ul><ul><li>Matters when you use an unstable component. </li></ul><ul><ul><li>But being strongly coupled to a stable component is not an issue. </li></ul></ul>G.R.A.S.P. : Low coupling (2/2)
    37. 37. G.R.A.S.P. : High cohesion <ul><li>Responsibilities of a given component should be strongly related. </li></ul><ul><li>Cohesion drops when: </li></ul><ul><ul><li>Class responsibilities are not focused </li></ul></ul><ul><ul><li>A responsibility is dispatched onto several classes </li></ul></ul>Just do your job !
    38. 38. Watch for the fat ! <ul><li>Obesity: </li></ul><ul><ul><li>If responsibilities are diluted </li></ul></ul><ul><ul><li>Coupling rises for assuming it </li></ul></ul><ul><ul><li>A code change will impact other functionalities </li></ul></ul><ul><li>Low coupling / High cohesion are intimately linked </li></ul><ul><ul><li>Higher cohesion -> lower coupling </li></ul></ul>
    39. 39. So? How to ensure low coupling and high cohesion?
    40. 40. Dependency management Inversion of control
    41. 41. There will be consequences <ul><li>Dependency A -> B </li></ul><ul><li>Impossible to </li></ul><ul><ul><li>deploy A without B </li></ul></ul><ul><ul><li>reuse A without B </li></ul></ul><ul><li>A modification on B </li></ul><ul><ul><li>has side-effect on A </li></ul></ul><ul><ul><li>needs A to be recompiled </li></ul></ul>A A A uses is linked to inherits of B B B
    42. 42. Dependency: a strategic move ! A B A B ? or ? <ul><li>Dependencies have to be sorted out </li></ul><ul><li>Especially when their number increases </li></ul><ul><ul><li>More classes -> More dependencies! </li></ul></ul><ul><ul><li>Aim at low coupling (always!) </li></ul></ul>
    43. 43. Dependency Inversion Principle <ul><li>High-level modules should not depend on low-level modules. Both should depend on abstractions. </li></ul><ul><li>Abstractions should not depend upon details. Details should depend upon abstractions. </li></ul><ul><ul><li>[Robert C. Martin,&quot;Object Oriented Design Quality Metrics&quot;, 1995] </li></ul></ul><ul><li>An application's added value comes from business! </li></ul><ul><ul><li>Dangerous to impact business layers if technical layers have to be changed. </li></ul></ul>
    44. 44. DIP : put into play <ul><li>Business components and interface are high-level objects </li></ul><ul><li>Construction approach : </li></ul><ul><ul><li>Specify needs of high-level components </li></ul></ul><ul><ul><ul><li>example : save in DB </li></ul></ul></ul><ul><ul><li>Define those needs through interfaces </li></ul></ul><ul><ul><ul><li>example : interface Persistence </li></ul></ul></ul><ul><ul><li>Implement this interface in low-level modules </li></ul></ul><ul><ul><ul><li>coupled with DB drivers </li></ul></ul></ul>
    45. 45. Inversion of control : principle <ul><li>Hollywood principle : </li></ul><ul><ul><li>“ Don't call us, we'll call you” </li></ul></ul><ul><li>Inversion of control is a generic word. </li></ul><ul><ul><li>Several usages </li></ul></ul><ul><ul><li>The most famous : dependency injection </li></ul></ul><ul><li>Objects won't seek their dependencies </li></ul><ul><ul><li>They will be provided by a third-party </li></ul></ul>
    46. 46. Inversion of control : put into play <ul><li>A bean container can inject those dependencies, at instantiation time </li></ul><ul><ul><li>though constructor parameters, </li></ul></ul><ul><ul><li>or through property setters after instantiation </li></ul></ul><ul><li>That what “light” containers do : </li></ul><ul><ul><li>Spring, Guice, Weld </li></ul></ul>
    47. 47. Dependency injection : example <ul><li>Example : </li></ul><ul><ul><li>Mario has a suit... </li></ul></ul><ul><li>Three approaches : </li></ul><ul><ul><li>1 - Elementary, without injection </li></ul></ul><ul><ul><li>2 - With manual injection </li></ul></ul><ul><ul><li>3 - With container injection </li></ul></ul>
    48. 48. 1 - Elementary : without injection <ul><li>package com.injection.none; </li></ul><ul><li>import com.injection.none.BlueSuit; </li></ul><ul><li>public class JMario { </li></ul><ul><li>private BlueSuit bluesuit = new BlueSuit(); </li></ul><ul><li>public void onActionButton() { </li></ul><ul><li>bluesuit.execute(this); </li></ul><ul><li>} </li></ul><ul><li>} </li></ul>Use: JMario j Mario = new JMario (); j Mario .onActionButton();
    49. 49. 1 - Without injection : Appraisal <ul><li>Closed modeling </li></ul><ul><ul><li>Mario can only have a suit </li></ul></ul><ul><li>High coupling (connection, creation, use) </li></ul><ul><ul><li>Dependency to the blue suit </li></ul></ul><ul><ul><li>Inability to change without recompiling Mario </li></ul></ul>
    50. 50. 2 - Manual injection <ul><li>package com.injection.with; </li></ul><ul><li>public class JMario { </li></ul><ul><li>private Suit suit; </li></ul><ul><li>public void onActionButton (){ </li></ul><ul><li>suit.execute(this); </li></ul><ul><li>} </li></ul><ul><li>public void setSuit(Suit suit) { </li></ul><ul><li>t his.suit = suit; </li></ul><ul><li>} </li></ul><ul><li>} </li></ul><ul><li>Use : </li></ul><ul><li>JMario jMario = new JMario(); </li></ul><ul><li>Suit blueSuit = new BlueSuit(); </li></ul><ul><li>jMario.setSuit(blueSuit); </li></ul><ul><li>jMario. onActionButton (); </li></ul>
    51. 51. 2 - Manual injection : Appraisal <ul><li>Pros: </li></ul><ul><ul><li>Mario exposes its dependency through the setter </li></ul></ul><ul><ul><li>No dependency to implementations </li></ul></ul><ul><ul><li>It could wear any suit </li></ul></ul><ul><li>Cons: </li></ul><ul><ul><li>The use is frozen (recompilation required to change the suit) </li></ul></ul>
    52. 52. 3 - Injection with a container <ul><li>Modeling is the same </li></ul><ul><li>Only the use changes: </li></ul><ul><ul><li>XML configuration or through annotations </li></ul></ul><ul><ul><li>Context loading </li></ul></ul><ul><ul><li>Suit retrieving </li></ul></ul>
    53. 53. 3 - Injection with a container <ul><li>XML configuration (example : Spring) : </li></ul><ul><li><beans> </li></ul><ul><li><bean id=&quot;theBlueSuit&quot; class=&quot;com.injection.with.suit.BlueSuit&quot; /> </li></ul><ul><li><bean id=&quot;mario&quot; class=&quot;com.injection.with.JMario&quot;> </li></ul><ul><li>< property name=&quot;suit&quot; ref=&quot; theBlueSuit &quot; /> </li></ul><ul><li></bean> </li></ul><ul><li></beans> </li></ul>Configuration by annotations (JEE6): public class JMario { @Inject private Suit suit; }
    54. 54. 3 - Injection with a container : Appraisal <ul><li>Same benefits as manual injection </li></ul><ul><li>Everything is parameterized </li></ul><ul><ul><li>you still have to configure the injection! </li></ul></ul><ul><ul><li>Centralized in XML </li></ul></ul><ul><ul><li>Type-safe with annotations </li></ul></ul><ul><li>It is not even necessary to recompile with XML configuration </li></ul>
    55. 55. Inversion of control : conclusion <ul><li>Low coupling </li></ul><ul><ul><li>Easy to replace components </li></ul></ul><ul><ul><li>Simplified maintenance </li></ul></ul><ul><li>Implementations are independent of use context </li></ul><ul><ul><li>Reusable components </li></ul></ul><ul><li>Modular and incremental development </li></ul><ul><li>Simplified tests: </li></ul><ul><ul><li>Dependencies already isolated </li></ul></ul><ul><ul><li>Mock-objects </li></ul></ul>
    56. 56. In vogue Design Patterns Convention over Configuration
    57. 57. Convention over configuration <ul><li>By convention, a framework works with a default configuration (suitable for common needs) </li></ul><ul><ul><li>Less configuration files </li></ul></ul><ul><ul><li>Simplification </li></ul></ul><ul><li>Use of annotations </li></ul><ul><li>Java EE 6 trends </li></ul><ul><ul><li>EJB 3.1 as simple as possible : </li></ul></ul><ul><li>@Stateless </li></ul><ul><li>public class SimpleSample { </li></ul><ul><li>public void doSomething() { /*business logic*/ } </li></ul><ul><li>} </li></ul>
    58. 58. Architectural Patterns 2 big families
    59. 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. 60. Architectural Patterns <ul><li>Driven by Service (SOA) </li></ul><ul><ul><li>Service-Oriented Architecture </li></ul></ul><ul><ul><li>Information System is a group of services </li></ul></ul><ul><li>Driven by Domain (DDD) </li></ul><ul><ul><li>Domain-Driven Design </li></ul></ul><ul><li>Both based on the same pattern ECB </li></ul><ul><ul><li>Entity Control Boundary </li></ul></ul><ul><ul><li>Similar to MCV (Model View Controller) Pattern </li></ul></ul><ul><ul><ul><li>But not dedicated to presentation layer </li></ul></ul></ul>
    61. 61. Lean Service Oriented Architecture (SOA) <ul><li>Control (Business services / repositories) is the main component </li></ul><ul><li>Anemic Object Model </li></ul><ul><ul><li>No Business logic </li></ul></ul><ul><ul><li>Strict image of DB (POJO) </li></ul></ul><ul><li>Mainly procedural programming </li></ul><ul><ul><li>J2EE leaded to forget about OO programming! </li></ul></ul>Facades Business Services Repository RDBMS Domain Objects
    62. 62. Domain Driven Architecture <ul><li>Domain Entities are the corner stone of the application </li></ul><ul><ul><li>manage their state </li></ul></ul><ul><ul><li>and their state's persistence </li></ul></ul><ul><ul><li>and implement business logic </li></ul></ul><ul><ul><li>-> PDO (Persistent Domain Object) </li></ul></ul><ul><li>Services (Control) lose application logic </li></ul><ul><ul><li>Perhaps not needed anymore! </li></ul></ul>Repository SGBDR Domain Object
    63. 63. Conclusion
    64. 64. Conclusion <ul><li>Answers? </li></ul><ul><ul><li>No miracle recipes.. </li></ul></ul><ul><li>Familiarize with those principles to raise the good questions </li></ul><ul><li>Design patterns are not mandatory </li></ul><ul><ul><li>Tackle to user needs first </li></ul></ul><ul><ul><li>then with an added value (maintainability always !) </li></ul></ul><ul><li>Lead to a design-driven approach </li></ul><ul><ul><li>New development cycles </li></ul></ul><ul><ul><li>Agile methodologies </li></ul></ul>Stay humble, But think big !
    65. 65. Bibliography
    66. 66. Source Code on GitHub https://github.com/acrepet/JMarioGame
    67. 67. Bibliography <ul><ul><li>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 </li></ul></ul><ul><ul><li>Design Patterns CD - Elements of Reusable Object-Oriented Software De Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides - Addison Wesley </li></ul></ul><ul><ul><li>Mai 1998 - </li></ul></ul><ul><ul><li>Refactoring to patterns , J. Kerievsky ; Addison Wesley; Septembre 2004 ; ISBN: 2-7117-8644-7 </li></ul></ul>
    68. 68. Bibliography <ul><li>Patterns of Enterprise Application Architecture [PEAA] de Martin Fowler – 2002 – Hardcover </li></ul><ul><li>Refactoring : Improving the Design of Existing Code de Martin. Fowler - 1999 [PEAA] - Addison-Wesley </li></ul>
    69. 69. Bibliography <ul><ul><li>&quot;Real World Java EE Night Hacks - Dissecting the Business Tier&quot; </li></ul></ul><ul><ul><li>Adam Bien – 2009 - Press Adam Biem </li></ul></ul><ul><ul><li>&quot;Real World Java EE Patterns - Rethinking Best Practices &quot; </li></ul></ul><ul><ul><li>Adam Bien – 2011- Press Adam Bien </li></ul></ul>
    70. 70. Bibliography : websites <ul><li>Jon Pearce website about patterns: </li></ul><ul><ul><li>http://www.cs.sjsu.edu/~pearce/modules/patterns/index.htm </li></ul></ul><ul><li>Martin Fowler website: </li></ul><ul><ul><li>http://martinfowler.com </li></ul></ul><ul><li>Adam Bien website: </li></ul><ul><ul><li>http://www.adam-bien.com </li></ul></ul><ul><li>About &quot;Domain-Driven Design&quot; approach : </li></ul><ul><ul><li>http://domaindrivendesign.org </li></ul></ul>

    ×