Mindmap
Software Technics - Model and Code, Interfaces and Abstract Class
Inhalt der Mindmap
Software Technics - Model and Code, Interfaces and Abstract Class
Introduction
- Object oriented approach, paradigm
- Concept of Objects
- - Encapsulates data and operations - Every object is an entity, they can be distiguished from each other. - The state of object can just be queried or modified by the help of the operations that are specified for object -> data hiding
- Concept of Class
- - The same objects belong to the same class - Every object knows which class it belongs to
- Connections Between Classes
- - Association - Generalization and specialization - Aggregation - Dependency
Transforming UML model elements into programming language elements
- Planning Phase
- At the final stage of the planning phase the detailed design of the system is created. One part of it is the implementation model. At this level the elements of the model (e.g. classes) can unambiguously be transformed to elements the programming language that we want to use for implementation.
- Forward engineering
- code from model
- Reverse engineering
- model from code
- Round-trip engineering
- the previous two together
- Modeling tool
- Advantages
- the model and the code are continuously synchronized
- Advantages
- Planning Phase
Advantages of using interfaces
- For the client it is enough just to know the interface of the service > E.g. Stack class: supports an interface with operations push() and pop(). If the client uses just the interface of the service class than there will be no need to modify the implementation of the client when the internal implementation of the service class (behind the interface) changes. So the interface can regarded to be a contract between the client and the service class: until the service guarantees the support of the interface there is no need to modify the client. (just as in the previous example) The implementation class can freely be replaced (even during runtime). This results a more flexible system that can be extended in an easier way. Polymorphism
Using interfaces and abstract base classes
- Concept of Interfaces
- A surface through which the services of on object can be accessed (and this is the only way how we can assess it). > From the programming point of view: a set of semantically coherent operations, that are supported by a service object (they can be used to access the operations of the service object).
- Abstract classes
- An abstract class is a class that has got at least one abstract method. An abstract method is a kind of virtual method that has got no implementation in the abstract class. If we forget to implement on of the abstract methods in a derived class the application will not compile. This is because if in a derived class we do not override all the abstract methods of the base class than the derived class will remain abstract as well: and abstract classes can not be instantiated!
- One class can implement multiple interfaces The point of separation - Defines semantic groups of supported operations - The interfaces are independent of each other
- When should we use interfaces and when should we use abstract base classes?
- Solution that uses an interface • Consequences > We managed to handle the equipments generally > Advantages – The equipment classes can still have a base class > Disadvantages – Code duplication in the IEquipment implementations. yearOfProduction, newPrice, GetAge (their codes are common in all of the classes) > Consequence (we have to judge in all cases separately): – In case of extending the IEquipment interface all the implementation classes should be extended as well!
- Solution that uses an abstract base class • Consequences > We managed to handle the equipments generally > Advantages – No code duplication, the common parts are put into the common base class! – When extending the EquipmentBase base class there is no need to modify the derived classes if the newly added operation is defined to be virtual and not abstract. > Disadvantages – An equipment can not have an other base class • Remark > The GetPrice() is defined to be abstract in the base class so that we have to override it in the derived class
- Combined solution • Consequences > We managed to handle the equipments generally > Advantages – No code duplication, the common parts are put into the common base class! – When extending the EquipmentBase base class there is no need to modify all the derived classes if the newly added operation is defined to be virtual and not abstract. – We can derive from the DisplayBase, but in that case we have to duplicate the code of the EquipmentBase! • Remark > The GetPrice() is defined to be abstract in the base class so that we have to override it in the derived class
- Concept of Interfaces
Informationen
- Beschreibung
- Mindmap am Software Technics - Model and Code, Interfaces and Abstract Class, erstellt von Fe Eyre am 09/03/2015.
- Erstellt von
- Fe Eyre
- Aufrufe
- 0
- Bewertung