You might think that’s a unusual way to prepare for an interview, and you’d be right. Nothing close to these notes arose during the interview, but I find this stuff interesting. If I’m motivated enough to study it, then I think that’s a good enough reason by itself, without a specific reason. These are some brief notes.
Object Orientated Programming has four key aspects:
- Encapsulation (Hiding information)
- Abstraction (Hiding the implementation)
- Each object keeps its state private, inside a class.
- Instance variables/properties/attributes are kept private and accessor methods are made public.
- Other objects don’t have direct access to this state. They can only call a list of public functions (methods).
- The object manages its own state via methods, no other class can touch it unless explicitly (not default) allowed.
- Private variables.
- Public methods.
- You can define classes within classes, and functions within functions.
- A natural extension of encapsulation
- A concept or idea that is not associated with any particular instance.
- Expresses the intent of the class, rather than a specific implementation.
- Programs are often extremely large and separate objects communicate with each other a lot. This makes maintaining large programs difficult, and abstraction tries to solve this.
- Applying abstraction means that each object should only expose a high-level mechanism for using it.
- This mechanism should hide internal implementation details. It should only reveal operations relevant for the other objects.
- This mechanism should be easy to use and should rarely change over time.
- Implementation changes — for example, a software update — rarely affect the abstraction you use.
- e.g. a coffee machine. It does a lot of stuff and makes quirky noises under the hood. But all you have to do is put in coffee and press a button.
- In OOP, objects are often similar, sharing similar logic. But they are not 100% the same.
- Create a (child) class by deriving from another (parent) class. This way, we form a hierarchy.
- child class reuses all fields and methods of the parent class (common part) and can implement its own unique part using method or attribute overloading.
- Gives a way to use a class exactly like its parent so there’s no confusion with mixing types. But each child class keeps its own methods as they are.
- This typically happens by defining a (parent) interface to be reused. It outlines a bunch of common methods. Then, each child class implements its own version of these methods.
- Any time a collection (such as a list) or a method expects an instance of the parent (where common methods are outlined), the language takes care of evaluating the right implementation of the common method — regardless of which child is passed.
I’d like to be so familiar with the following features that I can use them without referring to notes:
- Getters and setters.
- Instance methods compared to class methods.
- Inheritance, mixins, and decorators.
- The “magic” within the
Djangosource code that requires
mypyto use extensions in order to do its static type checking correctly.
- Unfortunately, I didn’t get the job. They wanted a senior Python developer with experience with
Infrastructure As Code, and also working at an agency. Can’t win them all. ↩