OOP Spring 2004 address 7 Legacy.

Uploaded on:
Scandinavian school of OOP. we see/make various leveled perspectives constantly. bloom, nourishment, bank ... { void feed(Food f).. 14. Sort astute alright since a race auto is an auto, consequently ...
Slide 1

OOP Spring 2004 address 7 Inheritance Kasper B. Graversen IT-University of Copenhagen

Slide 2

Today\'s projects A foo(A a).. B foo(A a).. foo(B a)..

Slide 3

Today\'s projects Types fluctuation sort wellbeing java difference Method dispatching virtual strategies over-burdening Interface based programming advancement Perspectives Run-time legacy Languages "without" sorts A foo(A a).. B foo(A a).. foo(B a)..

Slide 4

Inheritance Can be clarified from two perspectives Code re-use: legacy = D x  o Just indicate changes (delta x) and union them (  ) with the old (o) Scandinavian school of OOP we see/make various leveled sees all the time bloom, sustenance, bank accounts,... Idea from this present reality. Since 1968 possibly prior Was a key idea in persuading OO to be acknowledged in industry (30 years after its development!)

Slide 5

Inheritance and sorts We say B is a subtype of A. That is, B is of sort B and A. Once in a while composed as A <: B or A  B Simply signifies, "I need the sort OOPIterator" – you in this manner submit yourself to actualize the techniques for that interface. class A { void foo() .. } class B amplifies A { void foo() .. /overwrite void bar() .. /new stuff } class C actualizes OOPIterator { .. }

Slide 6

Types A sort is a kind of an agreement. It indicates an arrangement of marks and fields A mark is the arrival sort, name of the strategy, and the sorts of the contentions. In the event that some article has sort A , you are ensured to have the capacity to call any technique on the item, which has a mark given in A . Why? May appear to be inflexible contrasted with how we think and talk, yet for PCs I believe it\'s alright. Helps the software engineer in that he can determine desires to information and guarantees on yield. Helps compilers (and different devices) in discovering mistakes, making presentations, refactoring and so forth

Slide 7

Type checking Who issues the certifications? Moderate check contrasted with run-time tests Types are a great deal less expressive (ie. can express whole numbers, however not positive numbers). The sweeping statement empowers a static (critical) watch that the agreements are not broken. compose class record read java document sort check ... ...

Slide 8

Subtypes A subtype is an expansion of a current get (the subtype\'s supertype\'s agreement). The augmentation is dependably 0.. n extra marks and fields and 0.. n re-meanings of strategies. The subtype consequently acquires the agreement of its supertype, along these lines the accompanying property dependably hold A  B (A will be a subset of B mark and field-wise) when is it additionally A = B ? A B

Slide 9

Polymorphism A key issue of legacy is polymorphic references. Permits use of subtypes in every one of the spots of an application where a sort is normal. Practically you definitely know this from playing with accumulations... each component is put away utilizing Object references.

Slide 10

Polymorphism Using learning on subtypes, we can conclude a few tenets. Object o = new A() ?? An a = new A() ?? B = new A() ?? An a = new B() ?? Applies to all references-incorporating contentions in technique assertions. Since a reference can hold subtypes it is said to be polymorphic .

Slide 11

Type fluctuation Looking at strategies overwritten in subclasses, their contentions and return sort can differ in three ways Invariance : no change Covariance : more particular Contravariance : less particular covariant specialization of the contention of meet class Office { void meet(Person p) ... } class PrincipalOffice broadens Office void meet(Student s)... }

Slide 12

Type safe difference The principles of sort wellbeing are equivalent to the ones utilized on polymorphic references Contravariance for contentions. covariance for return values. invariance is unimportantly sort safe. A C E class A { C foo(F e) ... } class B amplifies A { D foo(E f) ... } B D F

Slide 13

Type safe difference (covariant contentions) Type insightful alright since the agreement of creature is not softened up snake.. i.e. Creature a = new Snake() a.feed(new Meat()) Carnivore Food class Carnivore { void feed(Meat m).. } class Snake develops Carnivore { void feed(Food f).. } Snake Meat

Slide 14

Type safe fluctuation (covariant return sort) Type shrewd alright since a race auto is an auto, henceforth we can substitute an auto manufacturing plant with a racecar production line CarFactory f = new RacecarFactory() Car c = f.produce() Car CarFactory class CarFactory { Car produce().. } class RaceCarFactory augments CarFactory { Racecar produce().. } Racecar RaceCarFactory

Slide 15

Inheritance in Java Generally Java just backings invariance ! foo essentially gets to be over-burden Is unrealistic class B amplifies A { void foo(B a).. } class A { void foo(A a).. } class B augments A { D foo().. } class A { C foo().. }

Slide 16

Inheritance in Java We can practice return sort in subclasses, the typechecker simply does not think about this. In any case, we are not permitted to say class CarFactory { Car construct() { return new Car(); } class RacecarFactory broadens CarFactory { Car manufacture() { return new Racecar(); } RacecarFactory fac = new RacecarFactory(); Racecar r = fac.build(); r.driveLikeCrazy();/r = (Racecar) fac.build();

Slide 17

Inheritance in Java has covariance for clusters. The addition is adaptability at the cost of sort security. How would we see that exhibits are covariant? At the point when are we stuck in an unfortunate situation? Car[] ca = new Car[] { new Car() } ;/fine Racecar[] ra = new Racecar[] { new Car() };/sort mistake Racecar[] ra = new Racecar[] { new Racecar() }; Car[] ca = ra; /ought to be alright, yet isn\'t ca[0] = new Car();/yields run-time blunder Racecar r = ra[0];

Slide 18

Method dispatching (how strategies are called) What is imprinted on the screen? class A { void foo() { this.bar(); } void bar() { print("aaa"); } class B augments A { void foo() { super.foo(); } void bar() { print("bbb"); } new B().foo();

Slide 19

Method dispatching Instance strategies in Java are virtual. Techniques are "late bound" or "late authoritative of self" (in Java self is called this) It is dependably the most particular (most specific) strategy which is called. That strategy can then conjure a less particular technique utilizing super An a = new B() a.bar();/"bbb" is still printed

Slide 20

Virtual strategies A graphical clarification: An a = new B(); An a = new A(); vtable :B fieldsA fieldsB foo bar foo bar an A section B part vtable :An a foo bar A section

Slide 21

Virtual techniques this changes covariantly class A { void foo() { this.bar(); } class B augments A { void foo() { this.bar(); } void bar() { print("b"); } :A::foo ..code.. this:A B vtable :B fieldsA fieldsB foo bar foo bar r A section B part :B::foo ..code.. this:B

Slide 22

Virtual strategies Why?? so subclasses has 100% flexibility to re-characterize usefulness. Take note of no change to automaticGear() class Car { void shiftGearUp() .. void automaticGear() { if(motor.rpm > 7800) shiftGearUp(); } class Racecar augments Car { void shiftGearUp() { checkSuperInfusion(); igniteRockets(); .. /may call super }

Slide 23

Method dispatching All occurrence strategies in Java are characterized virtual. In different dialects this must be expressly proclaimed (thus they are non-virtual as a matter of course). This implies there is distinction amongst an and b in: An a = new B(); b = an; a.foo(); b.foo(); when foo is overwritten in B, and B amplifies A

Slide 24

virtual strategies Advantages More adaptable subclasses Disadvantages Harder to peruse code as "this" might be bound to any subclass Calling virtual techniques from inside the constructor of a super class the strategy for the super class may utilize fields just characterized in the subclass… which are not introduced yet.

Slide 25

Overloading Nice in that it maintains a strategic distance from sort packaging class A { void process(Video v).. void process(House h).. } class A { void process(Object o) { if(o instanceof Video).. if(o instanceof House).. }

Slide 26

Overloading The most particular technique is called foo(B an) instead of foo(A a) But some of the time it is not characterized which is the most particular strategy! class A { void foo(A x, D y) { .. } void foo(B x, C y) { .. } } new A().foo(new(), another C()); new A().foo(new B(), new D()); A C B D

Slide 27

Overloading "Comes up short" when over-burdening on subclasses Who is called? Clarification: Static official of strategy determination class Processor { void process(Document d).. void process(RTFDoc d).. } Document doc = new RTFDoc(); RTFDoc rtf = (RTFDoc) doc; Processor p = new Processor(); p.process(doc); p.process(rtf); Document RFTDoc PDFDoc WordDoc

Slide 28

Interface based programming improvement Goal of OO projects are measured free coupling of elements ideally substitution of elements One methodology is somewhat basic Substitutable elements has the same sort Implements the same interface (contract)

Slide 29

Interface based programming advancement Code against interfaces All references ought to be of an interface sort as opposed to a solid sort B r = new B() I r = new B() B I B I B C

Slide 30

Interface based programming improvement A case of modules of a framework << Filesystem>> <<CommandLine>> CryptFS InodeFS SmallShell Kernel <<Scheduler>> RoundRobin PriorityQueue

Slide 31

Interface based programming advancement Instantiating is somewhat distinctive Filesystem fs = new INodeFS() as opposed to INodeFS fs = new INodeFS() Ensures just strategies characterized in the interface is called is executed by all elements of that interface. takes into account substitutions like fs = new CryptFS() Statements, for example, instanceof(INodeFS) gets to be perilous as it firmly associated with a specific usage.

Slide 32

Dynamically wrote dialects No sort check stage No sort presentation in the projects! Shorter code More flexi

View more...