Relation between class and object
This reusability is possible due to the relationship b/w the classes. Object oriented programming generally support 4 types of relationships that. Using is not the same as aggregation, since the class being used doesn't satisfy the whole/part question. The used class exists to help the first class. In Python, there are two main types of relationships between classes: composition . between two objects using the phrase is-a, that relationship is inheritance.
When we can describe the relationship between two objects using the phrase is-a, that relationship is inheritance. We also often say that a class is a subclass or child class of a class from which it inherits, or that the other class is its superclass or parent class. We can refer to the most generic class at the base of a hierarchy as a base class.
Inheritance can help us to represent objects which have some differences and some similarities in the way they work. We can put all the functionality that the objects have in common in a base class, and then define one or more subclasses with their own custom functionality.
Inheritance is also a way of reusing existing code easily. If we already have a class which does almost what we want, we can create a subclass in which we partially override some of its behaviour, or perhaps add some new functionality. Here is a simple example of inheritance: We create a subclass to represent students and one to represent staff members, and then a subclass of StaffMember for people who teach courses as opposed to staff members who have administrative positions.
We represent both student numbers and staff numbers by a single attribute, number, which we define in the base class, because it makes sense for us to treat them as a unified form of identification for any person. We use different attributes for the kind of student undergraduate or postgraduate that someone is and whether a staff member is a permanent or a temporary employee, because these are different sets of options. We have also added a method to Student for enrolling a student in a course, and a method to Lecturer for assigning a course to be taught by a lecturer.
Other Object Oriented Class Relationships | Atomic Object
Because we use the class of an exception to determine whether it should be caught by a particular except block, it is useful for us to define custom classes for exceptions which we want to raise in our code.
Using inheritance in our classes is useful because if an except block catches a particular exception class, it will also catch its child classes because a child class is its parent class. That means that we can efficiently write except blocks which handle groups of related exceptions, just by arranging them in a logical hierarchy. Write a simple program which loops over a list of user data tuples containing a username, email and age and adds each user to a directory if the user is at least 16 years old.
You do not need to store the age. Write a simple exception hierarchy which defines a different exception for each of these error conditions: Whenever an exception occurs, your program should move onto the next set of data in the list.
Print a different error message for each different kind of exception. Think about where else it would be a good idea to use a custom class, and what kind of collection type would be most appropriate for your directory.
You can assume that the age is already an integer value. At a real university, the divisions between staff and students and administrative and teaching staff are not always clear-cut. A student who tutors a course is also a kind of temporary staff member. A staff member can enrol in a course. A staff member can have both an administrative role in the department and a teaching position. In Python it is possible for a class to inherit from multiple other classes.
Lecture Notes on Object-Oriented Programming
We could, for example, create a class called Tutor, which inherits from both Student and StaffMember. This ambiguity is known as the diamond problem, and different languages resolve it in different ways. Fortunately the super function knows how to deal gracefully with multiple inheritance.
We would then end up with a class which has all the attributes and methods found in both Student and StaffMember. One way of doing this is to split up optional functionality into mix-ins.
Class diagram - Wikipedia
A Mix-in is a class which is not intended to stand on its own — it exists to add extra functionality to another class through multiple inheritance. For example, let us try to rewrite the example above so that each set of related things that a person can do at a university is written as a mix-in: Each mix-in is responsible for providing a specific piece of optional functionality.
This sometimes means that they depend on other properties which already exist in the class which inherits from them. We could extend this example with more mix-ins which represent the ability to pay fees, the ability to get paid for services, and so on — we could then create a relatively flat hierarchy of classes for different kinds of people which inherit from Person and some number of mix-ins. Why would we want to do this?
- Class diagram
- Relation between class and object
Sometimes we want to specify a set of properties that an object needs to have in order to be suitable for some task — for example, we may have written a function which expects one of its parameters to be an object with certain methods that our function will need to use. We can create a class which serves as a template for suitable objects by defining a list of methods that these objects must implement.
This class is not intended to be instantiated because all our method definitions are empty — all the insides of the methods must be implemented in a subclass. The abstract class is thus an interface definition — some languages also have a type of structure called an interface, which is very similar. We say that a class implements an interface if it inherits from the class which specifies that interface. The formulae for working out area and volume differ depending on what shape we have, and objects for different shapes may have completely different attributes.Object Oriented Programming 2 - Classes and Objects
Write a simple Item class which has a name attribute and a value attribute — you can assume that all the items you will use will be Item objects. Now write two subclasses of Box which use different underlying collections to store items: ListBox should use a list, and DictBox should use a dict.
There are multiple ways of doing this. You should end up with two boxes with 11 items each, and one box with 12 items. As we have already discussed, multiple inheritance can cause a lot of ambiguity and confusion, and hierarchies which use multiple inheritance should be designed carefully to minimise this. A deep hierarchy with many layers of subclasses may be difficult to read and understand.
In our first inheritance example, to understand how the Lecturer class works we have to read through three different classes instead of one. If our classes are long and split into several different files, it can be hard to figure out which subclass is responsible for a particular piece of behaviour.
You should avoid creating hierarchies which are more than one or two classes deep. In some statically typed languages inheritance is very popular because it allows the programmer to work around some of the restrictions of static typing.
If a lecturer and a student are both a kind of person, we can write a function which accepts a parameter of type Person and have it work on both lecturer and student objects because they both inherit from Person. This is known as polymorphism. In Python inheritance is not compulsory for polymorphism, because Python is not statically typed.
Association represents the static relationship shared among the objects of two classes. Aggregation[ edit ] Class diagram showing Aggregation between two classes. Here, a Professor 'has a' class to teach. Aggregation is a variant of the "has a" association relationship; aggregation is more specific than association.
It is an association that represents a part-whole or part-of relationship. As shown in the image, a Professor 'has a' class to teach.
As a type of association, an aggregation can be named and have the same adornments that an association can. However, an aggregation may not involve more than two classes; it must be a binary association. Furthermore, there is hardly a difference between aggregations and associations during implementation, and the diagram may skip aggregation relations altogether. The contents of the container still exist when the container is destroyed.
In UMLit is graphically represented as a hollow diamond shape on the containing class with a single line that connects it to the contained class.
The aggregate is semantically an extended object that is treated as a unit in many operations, although physically it is made of several lesser objects. Here the student can exist without library, the relation between student and library is aggregation. Composition[ edit ] Two class diagrams. The diagram on top shows Composition between two classes: A Car has exactly one Carburetor, and a Carburetor has at most one Car Carburetors may exist as separate parts, detached from a specific car.
The diagram on bottom shows Aggregation between two classes: A Pond has zero or more Ducks, and a Duck has at most one Pond at a time. The UML representation of a composition relationship shows composition as a filled diamond shape on the containing class end of the lines that connect contained class es to the containing class. Differences between Composition and Aggregation[ edit ] Composition relationship 1.
When attempting to represent real-world whole-part relationships, e. When the container is destroyed, the contents are also destroyed, e. When representing a software or database relationship, e. When the container is destroyed, the contents are usually not destroyed, e. Thus the aggregation relationship is often "catalog" containment to distinguish it from composition's "physical" containment. In practice, means that any instance of the subtype is also an instance of the superclass.
An exemplary tree of generalizations of this form is found in biological classification: The relationship is most easily understood by the phrase 'an A is a B' a human is a mammal, a mammal is an animal. The UML graphical representation of a Generalization is a hollow triangle shape on the superclass end of the line or tree of lines that connects it to one or more subtypes.
The generalization relationship is also known as the inheritance or "is a" relationship.
The superclass base class in the generalization relationship is also known as the "parent", superclass, base class, or base type. The subtype in the specialization relationship is also known as the "child", subclass, derived class, derived type, inheriting class, or inheriting type.