• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
MELJUN CORTES Java Lecture OOP
 

MELJUN CORTES Java Lecture OOP

on

  • 366 views

MELJUN CORTES Java Lecture OOP

MELJUN CORTES Java Lecture OOP

Statistics

Views

Total Views
366
Views on SlideShare
366
Embed Views
0

Actions

Likes
0
Downloads
11
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Example: Inheritance in java.awt package <br />

MELJUN CORTES Java Lecture OOP MELJUN CORTES Java Lecture OOP Presentation Transcript

  • Object-Oriented Programming MELJUN CORTES Java Fundamentals and Object Oriented Programming The Complete Java Boot Camp MELJUN CORTES
  • What You Should Learn What is OOP? I. A. B. C. History Definition Goals What is an Object? II. A. B. C. Definition “Interface” “Class” vs. “Instance” Three Core Principles of OOP III. A. B. C. Encapsulation Inheritance Polymorphism
  • Why OOP? A little history…  The “Software Crisis” (1960’s – 1980’s)  Computers became more powerful, and so programs became larger and more complex.  Software quality became terrible!  Too many bugs.  Schedules were not being met.  Difficult to add features or make changes to software.  Existing code could not be made the building blocks for new code – easier to write from scratch!  The field of “software engineering” was born!
  • Software Engineering  “creating high-quality software systems in an efficient and predictable manner”  Abstraction was one of the prime concepts used to simplify programming problems
  • Abstraction  Wikipedia: “abstraction is a mechanism and practice to reduce and factor out details so that one can focus on a few concepts at a time”
  • Abstraction – evolutions  Procedural Programming  routines were grouped into “functions”  one function can call another function  you didn't have to understand each line, just what each function did  you could hide data to be accessible to only within a function (“encapsulation”)
  • Abstraction – evolutions  Structured Programming  further refinement of procedural programming  formal methods of planning data-flow and functional decomposition  “goto” banned
  • Abstraction – evolutions  Object-Oriented Programming  Takes encapsulation even further by localizing data and associated operations into a mini-program called an “object”.  An OO program is an “ecosystem” of objects that interact with each other.
  • What is Object Oriented Programming?  “Think of an OO system as a bunch of intelligent animals (the objects) inside your machine, talking to each other by sending messages to one another.” – Allan Holub
  • What is Object Oriented Programming?  OOP takes abstraction furthest by allowing you to group related data and operations into different types of objects.  You no longer have to keep track of each variable or each function, just the different types of objects.
  • What is Object Oriented Programming?  You create your own data types, which are types of objects. Each of these data types are called “classes”.
  • What is Object Oriented Programming?  Creating your own classes allows you to design a program so that it is intuitive to remember how it is organized. For example, you can create classes that represent real-world business entities.  You can create classes to have specific responsibilities, so that when you need to update a piece of code, you know exactly where to look for it. 
  • Goals of OOP  Comprehensibility - make it easier for humans to understand the code  Maintainability - make code easy to modify  Reusability - old code should be building blocks for new code  Pluggability - you can create interchangeable components that can substitute for one another, just like machine parts
  • What is an Object?  Has attributes  properties or components  Has methods  behaviors or routines
  • What is an Object? Ex: Car  Attributes:      steering wheel engine color radio airconditioner  Methods:  go forward  go backward  cool the interior  play music
  • What is an Object? Ex: Purchase Order  Attributes:     PO Number Buyer Seller List of items being purchased  Methods:  get PO number  get buyer  get seller  get number of items  get item number __
  • What is an Object? Ex: DB Connection  Attributes:       URL of DB user password transaction isolation level is read-only? (boolean) is auto-commit? (boolean)  Methods:  create SQL statement  return whether readonly  set transaction isolation level  close connection  set save point  rollback
  • What is an Interface?  An object has an “interface”. The outward appearance of an object. How other objects see the object.  The attributes and methods that the object exposes. 
  • What is an Interface?  Normally, an object will only expose some of its attributes and methods.  Some attributes and methods are used only by the object itself. Therefore, no other object should have access to those.  Some attributes and methods may be made accessible only to certain other objects.  Some attributes and methods may be accessible by any other object.
  • What is an Interface?  Normally, only methods are exposed. Objects usually hide their data to protect them from being changed by other objects without their control.  Constants are an exception. These don’t change anyway.
  • What is a “Class” and an “Instance”?  My car is a ’92 Nissan Sentra. That is it’s class. There are many other ’92 Nissan Sentras out there.  But there is only one instance of my car.
  • What is a “Class” and an “Instance”?  Class – the definition of an object  Instance – the created object of a class
  • Three Core Principles of OOP  Encapsulation  Inheritance  Polymorphism (note: different texts will have differing sets of core principles)
  • What is Encapsulation? Encapsulation has two definitions:  The grouping of data and operations into objects.  Hiding of data and operations from other objects.
  • What is Encapsulation?  The first definition can be described as “Cohesion”.  Related data and operations should not be separated. They should be found in a single object.
  • What is Encapsulation? Ex: Car  You shouldn’t have to ask someone with a radar gun to measure the speed of your car. Your car should have its own speedometer to tell you that.
  • What is Encapsulation? Ex: Purchase Order object  Data for purchase orders should not be lumped in the same objects as data for invoices and receipts.  The methods for retrieving data from a purchase order should not be found in a separate class from the data.
  • What is Encapsulation? Ex: DB Connection object  The DB Connection object should not need to lookup the URL to the database from another object every time it does an operation.
  • What is Encapsulation?  The other definition can be defined as “information hiding”.  An object should expose only what is necessary, and only at the appropriate level.  Think CIA... “need-to-know”.
  • What is Encapsulation? Ex: Car  To driver: only steering wheel, pedals, and stick shift exposed. Driver should not access engine or gears or axle to drive the car.  Mechanic: access to engine, gears, etc., but not internals of each part.  Manufacturer: access to internals of each part.
  • What is Encapsulation? Ex: Purchase Order object  Any object can get info from the object, but only certain objects should have authority to set info.  Only certain objects should be allowed to create the PO object.
  • What is Encapsulation? Ex: DB Connection object  Only the Driver Manager object can create a connection  Users cannot set whether a connection is read-only or not.
  • What is Encapsulation? Benefits:  Simpler interfaces  Only a few methods are exposed to other objects. Since interactions between objects are simple, system is easier for the programmer to comprehend.  Data protected from corruption  Easier to modify code or find bugs  Because of simpler interfaces.
  • What is Encapsulation?  Objects should only expose members to each other through well-defined and simple interfaces.  Example: A driver drives a car with only steering wheel, pedals, gear-shift and dashboard meters and gauges.  Changes in one component will not affect the others since the interfaces remain the same.
  • Inheritance  A way to create a new class by “deriving” from another class. The new class acquires the interface of the old class. - “Interface Inheritance”  The new class often also acquires the implementations of the old class. “Implementation Inheritance”  The new class can change the implementations of the older class or add its own methods and attributes. 
  • Inheritance  Subclasses become “sub-types” of the super classes.
  • Inheritance  You can choose to refer to a class by one of its super types if you only need the generic interface.  You can choose to refer to a class by its specific type if you only need the specialized interface.
  • Inheritance  Example of an actual class heirarchy, part of the Java GUI library: Component Button Checkbox Container TextComponent Window Dialog TextArea Frame TextField
  • Inheritance  Inheritance is a way to allow objects to share code, preventing code-duplication.  Code-duplication is the #1 sin in OOP.
  • Inheritance  Implementation inheritance is dangerous!  The Fragile Base Class Problem  A subclass must inherit all inheritable members of the superclass.  No option to “disinherit” a member.  If the subclass inherits members that it doesn’t need, those members might be called by other objects in a way that the creator of the subclass did not intend (remember, you’re working in a team) causing undesirable behavior.
  • Inheritance  Implementation inheritance is dangerous!  The Fragile Base Class Problem   If someone modifies the superclass, the subclass will inherit the change! Again, this might cause undesirable behavior!
  • Inheritance  Implementation inheritance is dangerous!  Other issues:   Long hierarchies become complex and difficult to manage. Long hierarchies lead to classes with complex interfaces.
  • Inheritance  Implementation inheritance is dangerous! Prefer interface inheritance to implementation inheritance. At least you don’t inherit behavior, just the interface.  Never extend a class simply to save yourself some typing! There has to be a strong logical “is-a” relationship between superclass and subclass. 
  • Polymorphism  When a single datatype exhibits different behaviors during execution.  Greek: Poly means “many”, morph means “form”. Polymorphism means “existing in many forms”.
  • Polymorphism  It is the other side of the same coin as Inheritance.  Polymorphism is the reason why we want to have inheritance.
  • Polymorphism  Polymorphism allows for “pluggability” or “substitutability”. Types that implement the same interface can substitute for one another.  Client code just sees one class, but the actual “concrete” type can be different in different cases. 
  • Polymorphism  Method Overriding when a subclass re-implements one or more methods from the superclass  changes the behavior of the method 
  • Polymorphism  You can pass a subclass to a method wherever a particular class is required. void add(Component c);  you can pass instance of Button, TextArea, Dialog, etc, since they all inherit the interface of Component
  • Polymorphism  Since each subclass implements the methods of Component differently, each subtype gets drawn differently, receives input differently, listens for different events, etc. void add(Component c);  you can pass instance of Button, TextArea, Dialog, etc, since they all inherit the interface of Component
  • T he End Java Fundamentals and Object-Oriented Programming The Complete Java Boot Camp