程序代写代做代考 finance compiler concurrency c++ Java html Erlang go Programming Paradigms CSI2120

Programming Paradigms CSI2120
Jochen Lang
EECS, University of Ottawa Canada

Review of Object-oriented Programming
• Acknowledgement
– These slides are a barely modified version of the slides for Chapter 2, Object-Oriented Software Engineering: Practical Software Development using UML and Java by Tim Lethbridge and Robert Laganière
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

1. What is Object Orientation?
• Procedural paradigm:
– Software is organized around the notion of procedures – Proceduralabstraction
• Works as long as the data is simple – Addingdataabstractions
• Groups together the pieces of data that describe some entity
• Helps reduce the system’s complexity. – Such as records and structures
• Object oriented paradigm:
– Organizing procedural abstractions in the context of data
abstractions
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Object Oriented Paradigm
• An approach to the solution of problems in which all computations are performed in the context of objects.
– The objects are instances of classes, which:
• are data abstractions
• contain procedural abstractions that operate on the objects
– Arunningprogramcanbeseenasacollectionofobjects collaborating to perform a given task
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

A View of the Two Paradigms
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

2 Classes and Objects
• Object
– Achunkofstructureddatainarunningsoftwaresystem
– Has properties
• Representing its state
– Has behaviour
• How it acts and reacts
• May simulate the behaviour of an object in the real world
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Objects
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Classes
• A class:
– Aunitofabstractioninanobjectoriented(OO)program
– Represents similar objects • Its instances
– A kind of software module
• Describes its instances’ structure (properties)
• Contains methods to implement their behaviour
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Is Something a Class or an Instance?
– Somethingshouldbeaclassifitcouldhaveinstances
– Somethingshouldbeaninstanceifitisclearlyasinglemember of the set defined by a class
• Film
– Class; instances are individual films.
• Reel of Film:
– Class; instances are physical reels
• Film reel with serial number SW19876 – InstanceofReelOfFilm
• Science Fiction
– InstanceoftheclassGenre.
• Science Fiction Film
– Class; instances include ‘Star Wars’
• Showing of ‘Star Wars’ in the Phoenix Cinema at 7 p.m.: – InstanceofShowingOfFilm
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Common Approach to Naming Classes
– Use capital letters
• E.g. BankAccount not bankAccount
– Use singular nouns
– Use the right level of generality • E.g. Municipality, not City
– Make sure the name has only one meaning • E.g. ‘bus’ has several meanings
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Bjarne Stroustrup: What is so great about classes?
• “Classes are there to help you organize your code and to reason about your programs”.
• “A class is the representation of an idea, a concept, in the code. An object of a class represents a particular example of the idea in the code”.
– “Without classes, a reader of the code would have to guess about the relationships among data items and functions – classes make such relationships explicit and “understood” by compilers. With classes, more of the high-level structure of your program is reflected in the code, not just in the comments”. [emphasis added]
Source: http://www.stroustrup.com/bs_faq.html#class, accesed Jan. 2019
CSI2120 Programming Paradigms

3 Instance Variables
• Variables defined inside a class corresponding to data present in each instance
– Alsocalledfieldsormembervariables – Attributes
• Simple data
• E.g. name, dateOfBirth – Associations
• Relationships to other important classes • E.g. supervisor, coursesTaken
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Variables vs. Objects
• A variable
– Refers to an object
– May refer to different objects at different points in time
• An object can be referred to by several different variables at the same time
• Type of a variable
– Determines what classes of objects it may contain
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Class variables
• A class variable’s value is shared by all instances of a class.
– Also called a static variable
– If one instance sets the value of a class variable, then all the other instances see the same changed value.
– Class variables are useful for:
• Default or ‘constant’ values (e.g. PI) • Lookup tables and similar structures
– Caution: do not over-use class variables
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

4 Methods, Operations and Polymorphism
• Operation
– Ahigher-levelproceduralabstractionthatspecifiesatypeof
behaviour
– Independent of any code which implements that behaviour
• E.g. calculating area (in general)
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Methods, Operations and Polymorphism
• Method
– Aproceduralabstractionusedtoimplementthebehaviourof
a class
– Several different classes can have methods with the same name
• They implement the same abstract operation in ways suitable to each class
• E.g. calculating area in a rectangle is done differently from in a circle
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Polymorphism
• A property of object oriented software by which an abstract operation may be performed in different ways in different classes.
– Requires that there be multiple methods of the same name
– The choice of which one to execute depends on the object that is in a variable
– Reduces the need for programmers to code many if-else or switch statements
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

5 Organizing Classes into Inheritance Hierarchies
• Superclasses
– Contain features common to a set of subclasses
• Inheritance hierarchies
– Show the relationships among superclasses and subclasses – A triangle shows a generalization in UML
• Inheritance
– The implicit possession by all subclasses of features defined
in its superclasses
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

An Example Inheritance Hierarchy
• Inheritance
– The implicit possession by all subclasses of features defined
in its superclasses
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation
See in Umple

The Isa Rule
• Always check generalizations to ensure they obey the isa rule
– “A checking account is an account”
– “A village is a municipality”
• Should ‘Province’ be a subclass of ‘Country’?
– No, it violates the isa rule
• “A province is a country” is invalid!
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

A Possible Inheritance Hierarchy of Mathematical Objects
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Make Sure all Inherited Features Make Sense in Subclasses
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

6 Inheritance, Polymorphism and Variables
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Some Operations in the Shape Example
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Abstract Classes and Methods
• An operation should be declared to exist at the highest class in the hierarchy where it makes sense
– The operation may be abstract (lacking implementation) at that level
– If so, the class also must be abstract
• No instances can be created
• The opposite of an abstract class is a concrete class
– If a superclass has an abstract operation then its subclasses at some level must have a concrete method for the operation
• Leaf classes must have or inherit concrete methods for all operations
• Leaf classes must be concrete
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Overriding
• A method would be inherited, but a subclass contains a new version instead
– For restriction
• E.g. scale(x,y) would not work in Circle
– For extension
• E.g. SavingsAccount might charge an extra fee following every debit
– For optimization
• E.g. The getPerimeterLength method in Circle is much simpler than the one in Ellipse
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Methods and Inheritance
• How a decision is made about which method to run
1. If there is a concrete method for the operation in the current
class, run that method.
2. Otherwise, check in the immediate superclass to see if there is a method there; if so, run it.
3. Repeat step 2, looking in successively higher superclasses until a concrete method is found and run.
4. If no method is found, then there is an error
• In Java and C++ the program would not have compiled
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Dynamic Binding
• Occurs when decision about which method to run can only be made at run time
– Needed when:
• A variable is declared to have a superclass as its type, and
• There is more than one possible polymorphic method that could be run among the type of the variable and its subclasses
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

7 Concepts that Define Object Orientation
• The following are necessary for a system or language to be OO
– Identity
• Each object is distinct from each other object, and can be referred to
• Two objects are distinct even if they have the same data – Classes
• The code is organized using classes, each of which describes a set of objects
– Inheritance
• The mechanism where features in a hierarchy inherit from superclasses to subclasses
– Polymorphism
• The mechanism by which several methods can have the same name and implement the same abstract operation.
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Other Key Concepts
• Abstraction
– Object->somethingintheworld
– Class->objects
– Superclass -> subclasses
– Operation->methods
– Attributesandassociations->instancevariables
• Modularity
– Code can be constructed entirely of classes
• Encapsulation
– Details can be hidden in classes
– Thisgivesrisetoinformationhiding:
• Programmers do not need to know all the details of a class
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Bjarne Stroustrup: What is “OOP” and what’s so great about it?
• “Object-oriented programming is a style of programming originating with Simula (…) relying of encapsulation, inheritance, and polymorphism.”
• “It means programming using class hierarchies and virtual functions to allow manipulation of objects of a variety of types through well-defined interfaces and to allow a program to be extended incrementally through derivation.”
Source: http://www.stroustrup.com/bs_faq.html#class, accesed Jan. 2019
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

The Origins of Java
• Origin
– The first object oriented programming language was Simula-67
• designed to allow programmers to write simulation programs
• 1980s
– Smalltalk was developed at Xerox PARC
• New syntax, large open-source library of reusable code, bytecode, platform independence, garbage collection.
– C++ was developed by B. Stroustrup at ATT Labs
• Started in 1979. The initial version was called “C with Classes”.
• 1990s
– Sun Microsystems started a project to design a language that
could be used in consumer ‘smart devices’: Oak
• When the Internet gained popularity, Sun seized the opportunity and renamed the new language Java. It was first presented at the SunWorld ’95 conference.
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Appendix
• Review of Java in a Few Slides
CSI2120 Programming Paradigms

Java documentation
• Looking up classes and methods is an essential skill
– Looking up unknown classes and methods will get you a
long way towards understanding code
• Java documentation can be automatically generated by a
program called Javadoc
– Documentation is generated from the code and its comments
– You should format your comments as shown in some of the book’s examples
• These may include embeded html
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Characters and Strings
• Character is a class representing Unicode characters – More than a byte each
– Represent any world language
• char is a primitive data type containing a Unicode character
• String is a class containing collections of characters
– + is the operator used to concatenate strings
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Arrays and Collections
• Native arrays are of fixed size and lack methods to manipulate them
• ArrayList is part of the collection framework and is a growable array to hold a collection of other objects
• Iterators can be used to access members ArrayList numbers = new ArrayList();
numbers.addAll(Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8)); Iterator i = numbers.iterator();
while(i.hasNext())
{
System.out.println(i.next()); }
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Casting
• Java is very strict about types
– IfvariablevisdeclaredtohavetypeX,youcanonlyinvoke
operations on v that are defined in X or its superclasses
• Even though an instance of a subclass of X may be actually stored in the variable
– Ifyouknowaninstanceofasubclassisstored,thenyoucan cast the variable to the subclass
E.g. if I know a Vector contains instances of String, I can get the next element of its Iterator using:
(String)i.next();
To avoid casting you should use generics as in the previous slide:
ArrayList a; i=a.iterator(); i.next()
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Exceptions
• Anything that can go wrong should result in the raising of an Exception in Java
– Exception is a class with many subclasses for specific things that can go wrong
• Use a try – catch block to trap an exception try
{
// some code
}
catch (ArithmeticException e)
{
// code to handle division by zero
}
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Interfaces
• Like abstract classes, but cannot have executable statements
– Define a set of operations that make sense in several classes
– AbstractDataTypes
• A class can implement any number of interfaces
– It must have concrete methods for the operations
• You can declare the type of a variable to be an interface – This is just like declaring the type to be an abstract class
• Important interfaces in Java’s library include
– Runnable, Collection, Iterator, Comparable, Cloneable
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Packages and importing
• A package combines related classes into subsystems – Alltheclassesinaparticulardirectory
• Classes in different packages can have the same name – Althoughnotrecommended
• Importing a package is done as follows: – import finance.banking.accounts.*;
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Access control
• Applies to methods and variables – public
• Any class can access – protected
• Only code in the package, or subclasses can access – no modifier (blank)
• Only code in the package can access but not sub- classes outside package
– private
• Only code written in the class can access • Inheritance still occurs!
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Threads and concurrency
• Thread:
– Sequence of executing statements that can be running
concurrently with other threads • To create a thread in Java:
1. Create a class implementing Runnable or create a class extending Thread
2. Implement the run method as a loop that does something for a period of time
3. Create an instance of this class
4. Invoke the start operation, which calls run
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Programming Style Guidelines
• Remember that programs are for people to read – Alwayschoosethesimpleralternative
– Reject clever code that is hard to understand
• Stroustrup: “Don’t be clever”.
– Shorter code is not necessarily better
• Choose good names
– Make them highly descriptive
– Lethbridge/Laganière: “Do not worry about using long names”
– Stroustrup: “Don’t use overly long names; they are hard to type, make lines so long that they don’t fit on a screen, and are hard to read quickly.”
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Programming style …
• Comment extensively
– Comment whatever is non-obvious
– Do not comment the obvious
– Comments should be 25-50% of the code
– Stroustrup: “If the comment and code disagree, both are probably wrong”.
• Organize class elements consistently
– Variables, constructors, public methods then private
methods
• Be consistent regarding layout of code
– Stroustrup: “Such style issues are a matter of personal taste. Often, opinions about code layout are strongly held, but probably consistency matters more than any particular style”
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Programming style …
• Avoid duplication of code – Do not ‘clone’ if possible
• Create a new method and call it
• Cloning results in two copies that may both have bugs
– When one copy of the bug is fixed, the other may be forgotten
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Programming style …
• Adhere to good object oriented principles – E.g. the ‘isa rule’
• Prefer private as opposed to public
• Do not mix user interface code with non-user interface code – Interact with the user in separate classes
• This makes non-UI classes more reusable
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

10 Difficulties and Risks in Object- Oriented Programming
• Language evolution and deprecated features:
– Java is evolving, so some features are ‘deprecated’ at every
release
– Butthesamethingistrueofmostotherlanguages
• Efficiency can be a concern in some object oriented systems – Javacanbelessefficientthanotherlanguages
• VM-based
• Dynamic binding
• Stroustrup [HOPL-III, 2007]
– “Another problem was that Java encouraged a limited “pure object-oriented” view of programming with a heavy emphasis on run-time resolution and a de-emphasis of the static type system”
© Lethbridge/Laganière 2005 Chapter 2: Review of Object Orientation

Related Posts