1 / 25

Session 07: C# OOP 4

Session 07: C# OOP 4. Review of: Inheritance and Polymorphism. Static and dynamic type of an object. Abstract Classes. Interfaces. Object-Oriented Programming. “ The Three Pillars of OOP”: Encapsulation Inheritance Polymorphism The Substitution Principle. Recall: Quality Factors.

kerri
Télécharger la présentation

Session 07: C# OOP 4

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. Session 07:C# OOP 4 Review of: Inheritance and Polymorphism. Static and dynamic type of an object. Abstract Classes. Interfaces. AK - IT: Softwarekonstruktion

  2. Object-Oriented Programming “ The Three Pillars of OOP”: Encapsulation Inheritance Polymorphism The Substitution Principle AK - IT: Softwarekonstruktion

  3. Recall: Quality Factors • The most important ones: • Reliability: • Correctness • Robustness • Modularity: • Extendibility • Reusability • This is addressed through: • Inheritance and polymorphism AK - IT: Softwarekonstruktion

  4. Inheritance in C# • Every method and property is inherited – constructors are not. • private members are inherited, but are not directly accessible in the subclass. • Every protected member of the base class is visible in subclasses, but hidden from other parts of the program. • Members may be added in the subclass. • Multiple inheritance is not supported (by classes). • In C# every class inherits from Object. AK - IT: Softwarekonstruktion

  5. OO-Principles -inheritance • Supports code-reuse. • Existing classes may be extended through inheritance. • Inheritance is to used as type specialisation, that is: we are modelling an “is-a” relationship between super- and subclass. For instance: CheckAccount is an Account, a special kind of account, but an account. • So when we want to add specialised functionality to our system, inheritance may used by adding specialised classes. • E.g.: CheckAccount may inherit BankAccount. AK - IT: Softwarekonstruktion

  6. Inheritance - redefining methods • A method inherited from the base-class may be redefined (“overridden”) in the sub-class. • For instance the Withdraw-method on Account/CheckAccout. • In C# the must be specified “virtual” in the base-class and “override” in sub-class. • The method in the sub-class has the same signature (name and parameter list) and the same return type as the method in the base-class. • In the sub-class the redefined method in the base-class may be called using base.methodName(); AK - IT: Softwarekonstruktion

  7. Inheritance- polymorphism • All reference variables in C# may refer to objects of subtypes. • In the case of virtual methods it is first at execution time it is determined which method exactly is to be called. • The method called is the one defined on the object that the reference currently is referring to. • This is called dynamic binding – the call is bound to an actual code segment at runtime (dynamically). AK - IT: Softwarekonstruktion

  8. Polymorphism/Dynamic Binding Static type The way it used to be: Employee programmer = new Employee(“H. Acker","Programmer",22222); Static type = Dynamic type Static method call Dynamic type Statisc type • Using polymorphism: • Employee boss = new Manager(”Big Boss",”CEO",52525, 500); • Dynamic type must be the same or a sub-type of the static type. • The compiler checks method-calls on the static type. Runtime the call is bonded to the dynamic type (dynamic binding). • Dynamic binding requires methods to be specified virtual in the base-class and explicitly overridden in the sub-classes. Dynamic type AK - IT: Softwarekonstruktion

  9. Example • Let’s look at the implementation of the model from earlier Now: Employees at the cantina get double bonus. View Source (EmpProjectV2.rar) AK - IT: Softwarekonstruktion

  10. Exercises – Solutions? • ..\lektion06\Session06.docx AK - IT: Softwarekonstruktion

  11. Abstract Classes • In many cases we have an inheritance hierarchy where every subclass must implement the same method, but differently. • In this case we would like to declare the signature of the method in the base class, so that the compiler is able to perform static checking of calls to the method. • This can be done by declaring the method abstract. • When a class has one or more abstract methods, the class it selves must be declared abstract. AK - IT: Softwarekonstruktion

  12. Class Diagram and Code In Client: AbstractBase a = new Concrete1(); AbstractBase b= new Concrete2(); a.foo(); b.foo(); The dynamic type must be a subtype of the static type Dynamic method lookup finds the right implementation of foo() The compiler checks that foo() is defined on the static type AK - IT: Softwarekonstruktion

  13. In C#: • The definition of an abstract class • The implementation AK - IT: Softwarekonstruktion

  14. In C#: Cannot instantiate an abstract class. • In the client: AK - IT: Softwarekonstruktion

  15. Exercise • Exercise 1 on Session07.docx. AK - IT: Softwarekonstruktion

  16. Inheritance - abstract classes • A class that defines one or more methods that are not implemented is called abstract. And the non-implemented methods are specified abstract. • An abstract class can not be instantiated. It can only serve as base-class. • An abstract class can only be used as static type, not dynamic type for object. • Abstract methods must be implemented in the sub-classes. Otherwise the subclass itself becomes abstract. • So an abstract method defines or specifies functionality (but does not implement) what must be implemented in the subclasses. • Constructors in an abstract class are only used by the constructors in the subclasses AK - IT: Softwarekonstruktion

  17. Inheritance - design considerations • If we need a class to hold a list of employees, and it should be possible to add employees at the end of list, but nowhere else. Should we inherit Array or List or…? • We are not to inherit at all!!! But use delegation. • Inheritance is not to be used senselessly trying to reuse code! Inheritance is to be seen as sub typing! • Inheritance models “is-a” relationships. • Code-reuse is obtainable by using existing classes (composition, delegation etc.) AK - IT: Softwarekonstruktion

  18. Interfaces • An interface may be seen as a purely abstract class. • Interface: only method signatures, no implementation! (All methods are abstract) • An interface represents a design. • Example: • Using interfaces in the Dome example: • (In C# interfaces are normally named “ISomething” – here IItem) AK - IT: Softwarekonstruktion

  19. Interfaces • The Item must implement the interface (inherit it): AK - IT: Softwarekonstruktion

  20. Interfaces • The interface is now used as static type: AK - IT: Softwarekonstruktion

  21. Interfaces • We can also create an interface to the DomeDatabase class: Using the IItem interface as static type AK - IT: Softwarekonstruktion

  22. Interfaces • DomeDatabase class must implement the interface: AK - IT: Softwarekonstruktion

  23. Interfaces • In the main program: Weonlyneed to know the interface as static type AK - IT: Softwarekonstruktion

  24. Why use interfaces? • Formalise system design before implementation • especially useful with large systems. • Contract-based programming • the interface represents the contract between client and object. • Low coupling! • decouples specification and implementation. • facilitates reusable client code. • client code will work with both existing and future objects as long as the interface is not changed. • Multiple inheritance • A class may implement several interfaces, but only inherit one class. (No competing implementations). AK - IT: Softwarekonstruktion

  25. Exercises • Exercise 2 and 3 on Session07.docx. AK - IT: Softwarekonstruktion

More Related