Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

In fact, if you think of Go as an OO language (which I guess many won't), it has all the things you actually care about from OO. It doesn't have inheritance and you don't explicitly declare that a type implements some interface (). Since there is no inheritance of implementation you are forced to use composition, which is what people tend to end up recommending after a few years of fighting with OO code that has been written by people in love with a Linnean hierarchies and complex approaches to DRY.

() There are tricks to accomplish this, for instance creating a New() function that returns an interface type, which will make the compiler ensure you implement the interface).

* That has a hardcoded list of strings baked into it

* Accepts as inputs a filename (but can be empty) and a substring to search for

* At runtime, either (a) (if filename empty) iterates over hardcoded list of strings, or (b) opens file and iterates over lines in it

* For each string / line, if contains search string then output to stdout (and maybe also increment a counter).

It's very artificial but does allow the basic idea of OO to be illustrated and it's far less code than a GUI example. You have a base class and two derived classes that really do have a different mechanism, and even have different state (file handle or integer index). The program logic is also quite decoupled (the class interface is not tied to the fact you're doing string search).

You could solve the problem without classes by reading the whole file into the same list structure as the hardcoded strings, but that aspect is actually quite nice because you can present that first and then ask what to do if you want to avoid that unnecessary memory usage. It's also nice that you're illustrating a really common OO pattern (iterator).

The only slight downside is that some languages make this easy to do without (explicit) classes e.g. Python generator functions. But you can add a footnote that they exist and this is just to illustrate classes - it still beats the abstract examples.

There are aspects of DRY that are worth pursuing (like reducing the number of places you need to get things right) and some that aren't worth pursuing (thinking you reduce the amount of work by re-using code heavily). For code to be reusable you have to be sure that developers only have to care about its interface. Implementation inheritance often doesn't do that. I've worked on projects with people who were obsessed with DRY and made heavy use of implementation inheritance, and the projects inevitably needed extra work to untangle a brittle mess with lots of surprising behaviors.

It takes a brave interview candidate to say "the best solution depends on the exact nature of the problem - and your problem doesn't make any sense so there's no valid solution".