Please note, this post is part of my notes for the AQA Computer Science exams, which I am taking in 2017. The content is taken directly from the course, so any inaccuracies are the fault of AQA (I have to know them regardless)
- Programs are written in modules, so it is easy to adjust the program as only the affected module needs to be modified.
- It is easy to add new functionality, as you just need to add a new module.
- Modular design allows different programmers to work on different parts, without stepping on each other’s toes.
- Objects can inherit attributes and behaviour, allowing for easy reuse. Don’t repeat yourself!
- Changes are local to an object, affecting just its
properties. This means that there does not need to be global state, which can be unreliable and buggy.
- Libraries enable easy code reuse (though this is not unique to OOP, yet still in this section of the book.)
- Objects are self contained, data and code is kept in the same place.
- Seeing as objects just mutate themselves, OOP theoretically has fewer side-effects than procedural - however it is not as successful at this as Functional Programming is.
Information hidingmeans that only the parts of the code that need to know about the data do know about it.
- Outside code can only access data via
- A “blueprint” that describes a related group of things.
- Objects are
instantiatedfrom a class, they are known as
- Classes have
properties, these are the data. For instance, a
Humanmight have an
- Classes also have
methods, these are
subroutinesthat describe how data can behave.
The definitions of all classes are stored in
Mentioned above, this is just the process of creating an object from a class.
- Properties and methods described in the base class are common in all classes.
+indicates that the property/method is public, and a
-indicates that it is private. A
#indicates that it is protected, and can only be used in the class or its subclasses.
- Arrows point towards the base class.
- Data types are defined for each property.
Meaning “many forms”. Inherited methods can be redifined and used differently depending on the data in the subclass.
The method can be used without an object of the class being instantiated.
Defined in the base class, but can be overridden in the subclass. A feature of polymorphism.
Actual method not supplied in the base class, must be provided in the subclass.
The method of creating new objects that contain existing objects, based on the way in which objects are related.
This method can be said to represent “real life”, where objects have relations to each other.
Objects are composed of (or made up of) purely other objects. This is also known as “composition”, and if any of the component objects are deleted, then by definition so is the main object.
Here is a UML diagram:
Note the shape of the “arrow head”, and the fact that it is coloured in bold.
As in the diagram, if either
Manager were removed, then
Workforce would no longer exist.
Much like composition, except that objects are not dependent on each other for their existence. An object is made up of one or more other objects, but is not dependent on them.
Another UML diagram:
Note that this is very similar to the above, however the arrow heads are not in bold.
There are three main design principles.
Encapsulate what varies
Properties and objects should be subdivided into as many classes as needed, in order to mirror the real-life scenario.
Favour composition over inheritance
This is much less error-prone, and leads to simpler maintenance. A popular example of this is Unity, where Game Objects are made up of many components. Give it a go if you have the time!
Program to interfaces, not implementation
An interface is essentially a base class that is entirely abstract. When a class is created that implements these, it is an implementation of an interface.
Using interfaces means that so long as your program knows how the interfaces are to be called, then the underlying implementation can be changed with little impact.