Object-oriented – Employer appeal; OOP use in mainstream; solutions that blossom with OOP

Why don't you develop a short training in the SOLID principles and give them this training? It seems to have worked quite well for me in my current organization and I find giving short trainings is actually fun (for everyone involved).

When I gave my training I took some time to search for pathological "bad" examples in the existing code (of various projects), and refactored them in the presentation, step by step, using the principles. This demonstrated that

1. It's not that hard to do these refactorings
2. It doesn't take a long time
3. The end result (carefully chosen ;-) ) is clearly better than the original code.

Abstract classes

Abstract classes are classes where some methods on the class are missing implementations. Python can (sort of) have these, but they're not quite as explicit as languages like Java, where the program will refuse to build. Typically, you inherit from an abstract class, and fill in the missing pieces, possibly using non-abstract methods from the abstract base class. Consider this class, in Python:

class Foo(object):
    def bar(self):
        # code code code

    def baz(self):
        raise NotImplementedError()

This class is kind of like an abstract class: we can't (realistically) call baz. (We can, but we'll get only exceptions.) Unlike Java or C++, where an abstract class is one that can't be instantiated, we can instantiate Foo. Python provides the abc module if you want more "abstract" classes.

Virtual Functions

Virtual functions are functions that, when called from a reference or pointer to a base class, will call the derived version of that function. In C++, if I have:

Foo *foo = ClassDerivedFromFoo();
foo->bar();

If bar isn't virtual, Foo::bar will get called. If it is, ClassDerivedFromFoo::bar will get called, if it exists. (The most-derived version will get called.)

In Python, an over-simplification would be that one can think of all functions as being virtual. This isn't quite correct: an instance's functions are really just attributes on that instance, and you can easily "monkey-patch" them to be an arbitrary function.

Contract

A contract is an agreement between a function and a caller of a function as to things that happen during the execution of a function. It's essentially the guarantees a function makes. To my knowledge, none of Python/Java/C++ enforce these explicitly. See Design by contract.

Interface

In a loose sense, an interface is the API (note that the "I" is interface) some piece of code (a module, class, function, etc.) exposes: it consists of what function calls are available, what types of data do they take and return, and what should that data be composed of.

Java has a special meaning for interface: An interface is a class-like description that contains member functions that contain no body. A class that contains all of those functions then, "implements" that interface. The interface can be used as a base class of sorts.

Python has similar, but much more abstract concepts. Take the enumerate function. It takes an "iterable", and returns the items from that iterable paired with increasing integers. (If you feed it ['a', 'b', 'c'] it spits out (0, 'a'), (1, 'b'), (2, 'c'). My example was a list, but it'll happily take any iterable: sets, dictionaries, generators, tuples, etc. As long as the item meets the interface of an iterable. This interface isn't (in Python) recorded explicitly, but as long as the object you pass in acts like an iterable, everything should just work. (This is duck typing.)

The Java "interface" idea is closely related to the general idea of abstract base classes, and some of the things the abc module can do might be interesting in regards to interfaces, as well.