* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Advanced Object Oriented Systems
Survey
Document related concepts
Scala (programming language) wikipedia , lookup
Java syntax wikipedia , lookup
Java (programming language) wikipedia , lookup
Java ConcurrentMap wikipedia , lookup
Class (computer programming) wikipedia , lookup
Java performance wikipedia , lookup
Least squares wikipedia , lookup
Design Patterns wikipedia , lookup
Horner's method wikipedia , lookup
Newton's method wikipedia , lookup
Object-oriented programming wikipedia , lookup
Go (programming language) wikipedia , lookup
Covariance and contravariance (computer science) wikipedia , lookup
False position method wikipedia , lookup
Root-finding algorithm wikipedia , lookup
Name mangling wikipedia , lookup
Transcript
1 Advanced Object Oriented Systems (CM0318) Lecture 4 (Last modified 13th February 2001) 2 What’s the point of OO? We are trying to build (large) systems that are: • relatively easy to implement • reliable • maintainable • extensible • of satisfactory performance • ... 3 2 distinct philosophies • The ‘hacker’ philosophy – (let’s just tweak a few classes and hope it all works!) • The ‘methodologies’ philosophy – (good software doesn’t just happen: it requires discipline!) 4 Smalltalk philosophy (Ingalls) – – – – System entirely comprehensible to individual minimum set of unchangeable, v. general parts uniform framework Do programs look like they are doing what they are doing?? (cf. Design by Contract) – Everything-is-an-object – An operating system is a collection of things that don’t fit into a language. There shouldn’t be one 5 Methodologists (Booch) Functional Decomposition is limiting: Cruise Control System Get Desired Speed Get Current Speed ..... Put Throttle Value 6 OO Decomposition Wheel Driver Brake Curr. speed Throttle Engine Accelerator 7 OO Development steps (Booch) • Identify the objects and their attributes • Identify operations undergone by & required of each object • Establish visibility of each object in relation to others • Establish interface of each object • Implement each object 8 Some issues • How to approach the problem (life-cycle) • How to document & think about the domain and the design • How to implement the software designed • Tools to support the programmer, designer, etc. • To what extent does the chosen programming language support these concepts? 9 Our approach • Extend our knowledge of OO languages, discussing a few specific design principles • Then learn how a programming environment supports rapid prototyping in Smalltalk (using SQUEAK) • Then survey the principles of methodologies, design notations etc. 10 But first ... • An important design principle that most programming languages don’t fully enforce: type safety. 11 Type safety and Co/Contravariance Class 1 Class 2 foo(arg1:type1, ..., argn:typen): type0 foo(arg1:type1’, ..., argn:typen’): type0’ 12 Requirements for type safety • For foo in Class2 to be able to take all arguments of foo in Class1, type1’ … typen’ must all be the same as, or superclasses of, type1 … typen • For the return argument of foo in Class2 to be useable, its class type0’ must be either the same class, or a subclass of, type0 13 Put another way ... • Covariance: a relation between an operation overridden in a subclass and the original operation in which the type of each argument remains unchanged or becomes specialised • Contravariance: a relation between an operation overridden in a subclass and the original operation in which the type of each argument either remains unchanged or becomes generalised 14 For type safety ... • There must be contra-variance of parameters of an operation • There must be co-variance of the return parameters of an operation 15 Generally OO languages don’t support this • Consider the attached Java programs (Test0 & Test1). Results are E:\Lect99-00\ADVOOA\Lect 4>java Test0 Test0 version for Test0 parameter Test1 version Test1 version Test1 version Test0 version for Test0 parameter Test0 version for Test1 parameter Test0 version for Test0 parameter Test1 version Test1 version Exception in thread "main" java.lang.ClassCastException: Test0 at Test0.main(Test0.java:20) 16 Explanation • Can have multiple signatures for a single method in Java. This is method overloading. • In contrast to method overriding (where choice of methods with same signature is determined dynamically at run-time, on the class of the object receiving a message), method overloading is done statically. 17 Method overloading rules • Only methods defined in the declared class/interface of a variable and its superclasses/superinterfaces are considered • Only methods with same no. of parameters as the calling message are considered • Informally, one method declaration is more specific than another if any invocation handled by the first method could be passed on to the other one. The most specific method is chosen. 18 Method overloading (ctd.) • Let m be a name and suppose there are 2 declarations of methods named m, each having n parameters. Then ... 19 Method overloading (ctd.) • Suppose one declaration appears within a class or interface T and that the types of the parameters are T1, . . . , Tn; suppose the other declaration appears within a class or interface U and the types of the parameters are U1, . . . , Un. Method m declared in T is more specific than method m declared in U if and only if both: – T can be converted to U by method invocation conversion (i.e. a “T” can be validly used where a “U” has been declared, because U is, e.g., a superclass of T). – Tj can be converted to Uj by method invocation conversion, for all j from 1 to n. 20 Method overloading (ctd.) • A method is said to be maximally specific for a method invocation if it is applicable and accessible and there is no other applicable and accessible method that is more specific. • If there is only one maximally specific method for a given method invocation, it is called the most specific method • If a most specific method cannot be found, there is ambiguity and the compiler reports an error. (There are a few esoteric exceptions to this last rule) 21 Type casting • Note that you can compile code that casts to a more specialised type (needed, e.g., to process objects retrieved from collections as anything other than Objects) • But whether this is admissible is determined at run-time. 22 Lessons • In a way you can have co-/contra- variance in Java, by using multiple signatures. • In fact, co-variance of all parameters (including return parameters) is a Good Thing (because, e.g., in an MVC-style framework, more specialised ‘views’ should work with more specialised ‘controllers’) • But beware: it’s your responsibility to make sure that your code doesn’t have nasty runtime type violations! 23 Lessons (ctd.) • Method overloading for different numbers of parameters is fairly harmless (e.g. consider the various constructors for Vector) • Method overloading where there are two distinct method signatures for the same number of parameters has to be done sparingly, and with great care • Perhaps Java’s type system isn’t so good after all! 24 Some background reading • To understand the topics in this lecture, and to prepare for the survey of OO languages in the next couple of lectures, you may wish to skim the first 3 chapters of Bouzeghoub et al • The Java language specification, in all its glory, is available at: http://java.sun.com/docs/books/jls/second_edition/html/j.title.doc.html