Practical OOP In Java

7,630 views

Published on

Presentation in JaMU Jogja (JUG Joglosemar) in Akakom, Yogyakarta.

Published in: Technology

Practical OOP In Java

  1. 1. JaMU April 2009 STMIK AKAKOM Yogyakarta Practical OOP in Java A Case Study Approach Thomas Wiradikusuma wiradikusuma@gmail.com
  2. 2. Objective To demonstrate practical Object Oriented Programming in Java using a case study. Focus on OOP, Design Pattern, the UML and Java EE (Web).
  3. 3. Agenda Quick tour on software engineering Introduction to OOP Introduction to Design Pattern Introduction to the UML Case study
  4. 4. A Journey to the Source Everything begins from the source (code), based on requirements. Source code gets compiled, resulting in executable (actual deliverable). Requirements getting more complex, at the same time development must be faster, cheaper and better. Some order is required.
  5. 5. Hope for Silver Bullets High-level language advancements Object-oriented programming Graphical programming (diagramming) Incremental and iterative development Rapid prototyping Great designers …
  6. 6. Object-oriented Programming Essence: Abstraction Principals: Encapsulation Inheritance Polymorphism
  7. 7. Abstraction Humans manage complexity through abstraction. For example, people do not think a car as a set of tens of thousands of individual parts. They think of it as a well-defined object with its own unique behavior. A powerful way to manage abstraction is through the use of hierarchical classifications (layers).
  8. 8. Abstraction Humans manage complexity through abstraction. For example, people do not think a car as a set of tens of thousands of individual parts. They think of it as a well-defined object with its own unique behavior. A powerful way to manage abstraction is through the use of hierarchical classifications (layers).
  9. 9. Encapsulation The mechanism that binds together code and the data it manipulates. Protective wrapper that prevents the code and data from being misused outside the wrapper. Controlled through a well-defined interface. Allows migration of implementation without breaking contract with users of that class. In Java, the basis of encapsulation is the class.
  10. 10. Encapsulation The mechanism that binds together code and the data it manipulates. Protective wrapper that prevents the code and data from being misused outside the wrapper. Controlled through a well-defined interface. Allows migration of implementation without breaking contract with users of that class. In Java, the basis of encapsulation is the class.
  11. 11. Inheritance The process by which one object acquires the properties of another object. Supports the concept of hierarchical classification. Using inheritance, object needs only define qualities that make it unique. General attributes are inherited from its parent. The concept of super class and sub class.
  12. 12. Inheritance The process by which one object acquires the properties of another object. Supports the concept of hierarchical classification. Using inheritance, object needs only define qualities that make it unique. General attributes are inherited from its parent. The concept of super class and sub class.
  13. 13. Polymorphism Feature that allows one interface to be used for a general class of actions. The specific action is determined by the exact nature of the situation. One interface, multiple methods. Allows creation of clean, sensible, readable and resilient code.
  14. 14. Polymorphism Feature that allows one interface to be used for a general class of actions. The specific action is determined by the exact nature of the situation. One interface, multiple methods. Allows creation of clean, sensible, readable and resilient code.
  15. 15. Benefits of OO Approach Objects are more “real-world” Objects provide the flexibility and control necessary to deal with evolving requirements Object use facilitates collaboration Objects help manage complexity Reusability, maintainability and extensibility
  16. 16. Design Pattern General repeatable solution to a commonly- occurring problem in software design. Old idea, made popular by Gamma et al (Design Patterns -- Elements of Reusable Software, 1995). Must be Useful, Useable, and Used.
  17. 17. Patterns vs Algorithms Algorithms and data structures generally solve more fine-grained computational problems like sorting and searching. Patterns are typically concerned with broader architectural issues that have larger-scale effects.
  18. 18. Patterns vs Frameworks A software framework is a reusable mini-architecture that provides the generic structure and behavior for a family of software abstractions, along with a context of memes/metaphors which specifies their collaboration and use within a given domain. A framework is usually not a complete application: it often lacks the necessary application-specific functionality. Frameworks employ an inverted flow of control between itself and its clients.
  19. 19. Patterns vs Frameworks, cont’d Design patterns may be employed both in the design and the documentation of a framework. A single framework typically encompasses several design patterns. A framework can be viewed as the implementation of a system of design patterns. Frameworks and design patterns are distinct: a framework is executable software, design patterns represent knowledge and experience about software. Frameworks are of a physical nature, patterns are of a logical nature: frameworks are the physical realization of one or more software pattern solutions; patterns are the instructions for how to implement those solutions. Major differences: Design patterns are more abstract than frameworks. Design patterns are smaller architectural elements than frameworks. Design patterns are less specialized than frameworks.
  20. 20. Classification Creational patterns, object creation mechanisms, example: Factory method Prototype Singleton Structural patterns, identify a simple way to realize relationships between entities, example: Adapter Decorator Proxy Behavioral patterns, identify common communication patterns between objects, example: Chain of responsibility Observer Strategy
  21. 21. Unified Modeling Language Standardized general-purpose modeling language in the field of software engineering. Combines the best practice from data modeling concepts such as entity relationship diagrams (ERD), business modeling (work flow), object modeling and component modeling.
  22. 22. Connecting People Allows developers to communicate clearly. Natural language is cumbersome for complex concepts. Code is too detailed. Need to see from “high above.” UML is the lingua franca of analysis and design.
  23. 23. Classification
  24. 24. Worth a thousand words, but... The most important part is the executable (source code). Diagrams are for communication and documentation. Be flexible, use the simplest that works. Don’t be trapped with 100% roundtrip engineering.
  25. 25. Java Three in one: Programming language Virtual Machine Platform A product of Sun Microsystems Open sourced in November 2006 under the GNU General Public License Used in a wide variety of computing platforms
  26. 26. Java Programming Language C-like dialect ! public class Hello { ! ! public static void main(String args[]) { ! ! ! System.out.println(“Hello!”); ! ! } ! } Object oriented Interpreted and compiled Widely used to teach Programming 101 in many courses
  27. 27. Java Virtual Machine (JVM) Makes Java application portable Code compiled into bytecode JIT (Just In Time) native compiler Available in a wide range of computer architecture
  28. 28. Java Platform Java Card, applet embedded in smart card Java ME (Micro Edition), for cellphone Java SE (Standard Edition), desktop application and everything else Java EE (Enterprise Edition), Java SE with additional enterprise packages JavaFX, emerging rich client platform, Flash-like Android, from Google, not the “standard” one
  29. 29. Java EE Widely used platform for server programming in the Java programming language. Differs from Java SE in that it adds libraries which provide functionality to deploy fault-tolerant, distributed, multi-tier Java software, based largely on modular components running on an application server. There are “non standard” (alternative) tools/ frameworks to complement Java SE to be “enterprise- ready” (e.g. Spring Framework, EhCache, Mule ESB, etc).
  30. 30. Frameworks A system has many aspects: DB access, interoperability, security, logging, caching, validation, theme, testing, scalability, etc. Very hard and time consuming to build everything from scratch. Don’t reinvent the wheel (the NIH syndrome) Framework vs home-grown, framework is: Proven Abundant resource Community/commercial support Focus on “business problem”
  31. 31. Case study: Dewantara Open source student information system. Aims to be flexible, allowing it to be used in varying educational institutions. Java Web application (JPA, Spring, JSF). JUG CodeCamp 2008 project. Familiar domain for most of us (you go to school, don’t you?).
  32. 32. Lecturer Student
  33. 33. Lecturer Student Subject
  34. 34. Lecturer Student Room Subject
  35. 35. Lecturer Student Session Room Subject
  36. 36. Klass Lecturer Student Session Room Subject
  37. 37. Klass Lecturer Student Parent Session Room Subject
  38. 38. Klass Staff Lecturer Student Parent Session Room Subject
  39. 39. Stakeholder Klass Staff Lecturer Student Parent Session Room Subject
  40. 40. Institution Stakeholder Klass Staff Lecturer Student Parent Session Room Subject
  41. 41. Institution Stakeholder Klass Staff User Lecturer Student Parent Session Room Subject
  42. 42. Institution Stakeholder Klass Staff User Lecturer Student Parent Role Session Room Subject
  43. 43. Questions? JUG Joglosemar jug-joglosemar.org JUG Indonesia jug.or.id Thomas Wiradikusuma Blog jroller.com/wiradikusuma Twitter twitter.com/wiradikusuma

×