1 / 18

Lecture 12

Lecture 12. Implementation Issues with Polymorphism. Memory Allocation. Consider the code. class Professor: public Person{ public: virtual void f(); private: Classes c; }. class Person{ public: virtual void f(); private: Name n; }.

deanne
Download Presentation

Lecture 12

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 12 Implementation Issues with Polymorphism

  2. Memory Allocation • Consider the code class Professor: public Person{ public: virtual void f(); private: Classes c; } class Person{ public: virtual void f(); private: Name n; } Person per; Professor prof;

  3. Allocation • The assignment per = prof in C++ (remember, this is an object assignment) slices the extra fields off. • The field c is gone • For members use static binding: • per.f(); //accesses Person • With virtual methods with pointers or refs use the dynamic information, e.g. Person *pper; Professor *pprof; pper=&prof; pper->f(); //accesses Professor f() pprof=&prof; pprof->f(); //clearly professor

  4. Other Strategies • Allocate the maximal amount for the largest subclass. • No slicing • Need to know all subclasses • Nobody does this • Allocate memory for pointers • If the data is kept on the heap: allocated upon request • E.g. Professor = new Professor(); • Referred by pointer or reference

  5. Heap Allocation (ctd) • Data is anonymous • Assignment statements and equality tests are pointer/reference oriented • Copy semantics require new objects, pointer/reference not • In C++ the == operator can be overloaded to any meaning • Smalltalk & Java use pointer/reference semantics, but allow the use of clones

  6. Cloning • Implement a copy method • Create a new object • Copy the existing object’s contents into it public class structure{ public structure copy(){ structure x = new structure(); x.setValue(getValue()); return x; } structure copy = obj.copy(); //cloning

  7. Forms of Polymorphism • Variable: variables can hold values from a base class and subclasses. • The dynamic type must be a subclass of the static type of the base class • C++ requires use of pointers and references for polymorphism • Pure: Methods can have polymorphic parameters. • In Java and C++ need double dispatch • accept(Visitor v){return v.visitXXX(this); accepts any legal Visitor

  8. Other Types of Polymorphism • Overloading: Allow several function bodies, e.g. overloading “+” operator in C++ • The function signature determines the body • Can use static and dynamic signatures • Overriding: Change the semantics of the parent in the child • Different children can override in different ways • Ensures common interfaces

  9. Other Types of Polymorphism • Deferred Methods: Force the children to have method bodies (generalization of overriding) class Shape{ ... void virtual draw() = 0; ... } class Circle: public Shape{ ... void draw{drawCircle();} ... }

  10. Coupling and Cohesion • Measure dependency between classes by coupling • Dependency limits code reuse • Could be intentional: E.g. MVC and Listener • Modules should minimize external dependencies, e.g. GUI and business logic • Modules should address common behavior, i.e. internal cohesion

  11. Coupling • Measure of dependency between modules • Types in order of desirability • Data Coupling: Output from one module is input to another • Control Coupling: Passing control flags between modules so that one module controls sequencing of processing in another • Global Data Coupling: Two or more modules share common data structures • Internal Data Coupling: One module directly modifies local data of another

  12. Data Coupling • Output from one module is the input from another • E.g. using parameter lists to ship objects between classes • Object X passes Object O to Object Y • Objects O and Y are coupled • Change interface in O may require change in Y

  13. Example class Y{ public void funnyStuff(Object O){ ... O.doSomethingFunny(String t); ... } }

  14. Control Coupling • A sends a message to B • B returns control information to A class tryPrint{ public: int printFile(File toPrint){ if (toPrint is corrupt) return CORRUPTFLAG; else ... ... } } tryPrint when = new tryPrint(); int result = when.printFile(popQuiz); if (result == CORRUPTFLAG) ...

  15. Global Data Coupling • Modules has access to common data areas • E.g. external in C • Variables in public interfaces whose structure is public • Even items in a public interface whose values remain constant and whose implementations are hidden • Modules are very tightly coupled • Reusability is severely limited • Hard to tell who updated the global data • What happens when data structure is changed?

  16. Global Data Coupling • Cure: Make a separate module with public methods to access the global data • Very bad form of coupling, especially with pointers to global dating because of aliasing • Hard to understand classes in isolation

  17. Internal Data Coupling • Modules modify each other’s internal data • Also dependencies between items that make up an object • The worst form of coupling-always to be avoided!

  18. Other Forms of Coupling • Interface Coupling (a form of Object Coupling): Referring to specific items in another object’s public interface (very weak form of coupling) • Outside Internal Coupling from Underneath: coupling between parent and child with respect to state or operations • Unwanted inheritance • Makes subclass complex

More Related