github twitter email rss
CS Notes: Object Oriented Programming
Feb 3, 2017
4 minutes read

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)

Advantages

  • 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.)

Encapsulation

  • 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 hiding means 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 methods.

Classes

  • A “blueprint” that describes a related group of things.
  • Objects are instantiated from a class, they are known as instances.
  • Classes have properties, these are the data. For instance, a Human might have an age property.
  • Classes also have methods, these are functions or subroutines that describe how data can behave.

The definitions of all classes are stored in class libraries.

Instantiation

Mentioned above, this is just the process of creating an object from a class.

Inheritance

  • Properties and methods described in the base class are common in all classes.

  • A + 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.

Polymorphism

Meaning “many forms”. Inherited methods can be redifined and used differently depending on the data in the subclass.

Static

The method can be used without an object of the class being instantiated.

Virtual

Defined in the base class, but can be overridden in the subclass. A feature of polymorphism.

Abstract

Actual method not supplied in the base class, must be provided in the subclass.

Aggregation

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.

Composition aggregation

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 Employee or Manager were removed, then Workforce would no longer exist.

Association aggregation

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.

Design principles

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.


Back to posts