Midterm 2 Review Decorator COMP 401 Spring 2013 Lecture 17 3 19 2013 How Now Brown Cow Professor Revised assignment schedule A5 Wed 3 27 A6 Fri 4 5 A7 Wed 4 17 A8 Fri 4 26 Midterm 2 sTll this Friday Today Midterm 2 Review start of Decorator Thursday Decorator nished start of Observer Observable Inheritance Subinterfacing Extending an exisTng interface Subclassing Extending an exisTng class Extending Interfaces Adds methods to contract Original parent interface super interface New subinterface child interface extended interface Created by using the extends keyword public interface CompressedMedia extends Media int getCompressedSize int getUncompressedSize Media uncompress Extension Creates Hierarchy Is A relaTonship is transiTve up the hierarchy Methods for both must be provided Media extends Compressed Media public class Song implements CompressedMedia Song s new Song OK because s is a CompressedMedia cm CompressedMedia s Compressed Media Media m Media s OK because s is a Media by virtue of extension Cas ng from interface back to speci c object type is Song s2 Song m allowed but at run me if the object s type does not actually match a run me excep on will be thrown Interface Extension vs Interface ComposiTon public interface Compressed int getCompressedSize int getUncompressedSize Media uncompress Instead of extending Media Compressed is a separate interface and Song implements both public interface Media int getLengthInSeconds double getLengthInMinutes int getRaTng void setRaTng int new raTng String getName public class Song implements Compressed Media Song s new Song Media m Media s Compressed c Compressed s Song is a Media AND Song is a Compressed Subinterface vs Subclass Extending interface only added behavior to contract Since interfaces don t specify and don t care how contract is ful lled Extending class creates a new class that shares internal implementaTon details of its super class COMP 401 Spring 2012 7 Is A F or S ubclasses Objects of type A implement class A implements InterA class B extends A implements InterB class C extends B implements InterC interface InterA A is a Inter A Objects of type B implement interface InterB and InterA B is a A B is a InterA B is a InterB Objects of type C implement interface InterC InterB and InterA C is a A C is a B C is a InterA C is a InterB C is a InterC COMP 401 Spring 2012 8 Instance Fields Subclass has direct access to public and protected instance elds Public Everyone has access Generally not a good idea Breaks encapsulaTon Private Only class has access Generally recommended as default Subclasses however also shut out Protected Class and subclasses have access Like private i e appropriate use of encapsulaTon but allows for subclassing even if outside of package lec9 v4 COMP 401 Spring 2012 9 Access Modi er Chart Class Package Subclass World public YES YES YES YES protected YES YES YES NO no modi er YES YES NO NO private YES NO NO NO Subclass Method Polymorphism Subclass can overload methods in superclass Remember overloading is providing a di erent version of an exisTng method An example of polymorphism Method signature is di erent in some way lec10 v1 Overriding Methods A subclass can override a super class method by providing its own de niTon Method signature must be the same Original method is visible from subclass i e public protected or package level access lec10 v2 Class Polymorphism Previously introduced the idea of is a relaTonships Between a class and interfaces implemented Between a class and its superclass hierarchy This is also an example of polymorphism Covariance TreaTng an instance of a subclass as a reference typed as the parent class This can be typed checked at compile type Contravariance TreaTng a reference typed as the parent class as an instance of a subclass Contravariance can not be type checked in advance at compile Tme Fails if the object is actually invariant with respect to the subclass lec10 v4 lec10 v4main Also demonstrates protected base class constructor A Covariant Conundrum Problem What should happen when an overriden method is called on a covariant reference C c obj new C B b obj B c obj A a obj A c obj System out println c obj m System out println b obj m System out println a obj m class A public int m return 0 class B extends A public int m return 1 class C extends B public int m return 2 What should these lines print Virtual Methods Di erent OOP languages choose to solve this problem in di erent ways C C Default is non virtual soluTon Programmer can force virtual soluTon by marking a method with a special virtual keyword Java Methods are always virtual No special keyword needed lec10 v5 Abstract Classes and Methods Parent class has no meaningful implementaTon of a method But part of interface of parent class Expect subclass to provide it In these situaTons we never expect or want the parent class to be instanTated directly We always make new objects using a subclass Syntax Use abstract modi er when declaring parent class Declare any methods that must be provided by subclass in parent Add abstract modi er to method signature Follow signature with semicolon instead of method de niTon ComposiTon and AggregaTon Two design techniques for creaTng an object that encapsulates other objects Any speci c situaTon is not necessarily strictly one or the other In a nutshull ComposiTon The individual parts that make up the whole are owned solely by the whole They don t otherwise have a reason for being AggregaTon The individual parts that make up the whole may also exist on their own outside of the whole Or even as a component or part of other objects CharacterisTcs of AggregaTon Encapsulated objects provided externally As parameters to constructor Gerers and serers for these components osen provided Encapsulated objects may be independently referenced outside of the aggregaTng object Including possibly as part of another aggregaTon CharacterisTcs of ComposiTon Encapsulated objects created internally Usually within the constructor No serers and osen no gerers Encapsulated objects do not make sense outside of the abstracTon Not shared with other abstracTons FuncTonality state of encapsulated objects only accessible through the abstracTon DelegaTon Claiming an is a relaTonship with an interface but relying on another object to actually do the work Can occur with either aggregaTon or composiTon Although more common with composiTon ComposiTon example revisited lec13 v3 Both Car implementaTons also now claim