Your SlideShare is downloading. ×
  • Like
MELJUN CORTES Java Lecture OOD
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

MELJUN CORTES Java Lecture OOD

  • 133 views
Published

MELJUN CORTES Java Lecture OOD

MELJUN CORTES Java Lecture OOD

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
133
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
5
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Object-Oriented Design MELJUN CORTES Java Fundamentals and Object Oriented Programming The Complete Java Boot Camp MELJUN CORTES
  • 2. What You Should Learn 1. 2. 3. 4. What is a Good OO Program? What is a Bad OO Program? How Do We Write a Good OO Program? Steps in Designing an OO Program
  • 3. What is a Good OO Program?  Maintainable  80% of the cost of a program is in maintenance  New features  Bug fixes  It should be easy to locate where to add new features or where problems exist.  Changes should only affect a few lines of code.  Changes in one component should not affect others.
  • 4. What is a Good OO Program?  Unit-Testable  Each component should be independent of other components, so can be tested in isolation.
  • 5. What is a Good OO Program?  Understandable It should be easy to read the code and understand what it does.  If you need to fix or change something, it should be intuitive to know where the lines of code you need to change are located. 
  • 6. What is a Bad OO Program?  “Code Smells” – signs that there might be something wrong with your code.
  • 7. What is a Bad OO Program?  Large classes and long methods. Means your code is trying to do too much.  OOP is about creating little programs (objects) that do just one thing, and do it well.  Each object is so simple so as to minimize bugs. 
  • 8. What is a Bad OO Program?  Primitive Obsession  Using primitives / built-in classes instead of creating own classes.  Data Clumps  Data that always appears together.  Long Parameter List  Methods have too many parameters. A sign that you have data clumps.
  • 9. What is a Bad OO Program?  Primitive Obsession, Data Clumps, Long Parameter List  You should group data that are used together into a more meaningful class. Abstract away the details.
  • 10. What is a Bad OO Program?  Too many switch statements Sign that a method or class is trying to exhibit too many behaviors.  Use polymorphism to encapsulate different behaviors into specific subtypes. 
  • 11. What is a Bad OO Program?  Refused Bequest When a subclass does not use members inherited from a superclass  Dangerous because those methods might cause undesirable behavior in the subclass 
  • 12. What is a Bad OO Program?  Alternative Classes with Different Interfaces Closely related classes should share the same interface, so that they can be pluggable to the client code.  Example: “OracleConnectionManager” and “MsSqlServerConnectionManager” should share the same interface. 
  • 13. What is a Bad OO Program?  Shotgun Surgery Several classes changed for every new feature / change.  Maybe some code needs to be consolidated in a single class? 
  • 14. What is a Bad OO Program?  Divergent Change  Same class changed for different reasons.   “Well, I will have to change these three methods every time I get a new database and I have to change these four methods every time there is a new financial instrument.." Maybe the class needs to be split?  Ex. One class is modified for database changes and a different class is modified for new financial instruments.
  • 15. What is a Bad OO Program?  Lazy class  Class that doesn't do much, better just move what it does to other classes then delete it  Duplicate Code  The number one sin!  Dead Code  unused code
  • 16. What is a Bad OO Program?  Feature Envy when a method excessively accesses the data of another class  better to move the method to the other class 
  • 17. What is a Bad OO Program?  Inappropriate Intimacy when two classes are constantly accessing each others members  maybe members of one should be moved to the other or vice-versa  maybe a new class should be created to hold common members 
  • 18. What is a Bad OO Program?  Message Chains  When a client asks for an object to get another object, which it asks to get another object, which it asks to get another object... before finally being able to call the method it needs  Better to create a method in the first object that returns the data that the client needs  it could navigate the chain itself or the other classes in the chain also need to be changed to give more immediate access to the required data
  • 19. What is a Bad OO Program?  Too many comments Comments are important, but maybe you’re writing comments because the code is not readable in the first place?  Code should be readable even without comments. 
  • 20. How Do We Write a Good OO Program?  The Once and Only Once Rule  The One Responsibility Rule  The OO Prime Directive  The Law of Demeter  Well-Defined Interfaces, Hidden Implementations
  • 21. How Do We Write a Good OO Program?  The Once and Only Once Rule − don't copy-paste − keep functionality in one spot − − avoid shotgun-surgery, changes are easier bugs are easier to find and fix
  • 22. How Do We Write a Good OO Program?  The One Responsibility Rule − Each class/method should only do ONE THING − Name of class/method should express that one thing − Long Class, Long Method and Switch Statements are smells indicating this principle is being broken − Also known as “Cohesiveness”
  • 23. How Do We Write a Good OO Program?  The OO Prime Directive “Never ask an object for information that you need to do something; rather, ask the object that has the information to do the work for you.” - Allen Holub
  • 24. How Do We Write a Good OO Program?  The OO Prime Directive “Ask for help, not information.”
  • 25. How Do We Write a Good OO Program?  The OO Prime Directive “The maintainability of a program is inversely proportional to the amount of data that flows between objects.” - James Gosling inventor of Java
  • 26. How Do We Write a Good OO Program?  The OO Prime Directive The more one object has access to the internals of another object, the more the program can break when one object changes.  Limiting the flow of data makes bugs easier to find. 
  • 27. How Do We Write a Good OO Program?  The Law of Demeter “Each unit should have only limited knowledge about other units: only units 'closely' related to the current unit.”
  • 28. How Do We Write a Good OO Program?  The Law of Demeter “Don't talk to strangers.”
  • 29. How Do We Write a Good OO Program?  The Law of Demeter − Minimize the number of collaborators of a class.
  • 30. How Do We Write a Good OO Program?  The Law of Demeter A method "M" of an object "O" should invoke only the methods of the following kinds of objects: 1. itself 2. its parameters 3. any objects it creates/instantiates 4. its direct component objects
  • 31. How Do We Write a Good OO Program?  Well-Defined Interfaces, Hidden Implementations
  • 32. How Do We Write a Good OO Program?  Well-Defined Interfaces, Hidden Implementations   Coordination between programmers in a team is made easier if you decide on the interfaces of each class first. Each programmer is then at liberty to change the implementations of his or her classes without affecting the work of other programers.
  • 33. How Do We Write a Good OO Program?  Well-Defined Interfaces, Hidden Implementations Supports parallel development.  Supports unit testing.  Supports pluggability and reuse. 
  • 34. Steps in Designing an OO Program Understand the business requirements 2. Model the business domain 3. Define the layers of your application 1. • Usually three: Presentation, Business & Integration Define the interfaces of the classes you need to implement each requirement 2. Review and repeat as necessary 1.