Conclusion to Part Three

The story of this book has been one of deconstruction and reconstruction. The enormous complexity of three decades of OOP was deconstructed, to find a simple core, and an object-oriented programming experience was reconstructed around that core. The reconstruction contains all of the distinctive and important elements of the paradigm, while shedding the complexity borne of additive consultancy and capitulation to existing processes.

Importantly, this new reconstruction still takes lessons from the two schools of thought in computing, which I call the laboratory school and the library school.

The Laboratory School

The Laboratory School is the experimental approach. Go out, make a thing, and adapt, refine, or reject it based on your observations of how it performs. Don't worry about making the right thing, or making the thing right, just ensure it is made. You can adapt it later.

Extreme Programming (XP) and the Lean Startup movement both exhibit influences of the laboratory school. Both schemes advocate experimentation and fast feedback. Both recommend starting small and simple – XP with its Ya Ain't Gonna Need It principle and the Lean Startup with its minimum viable product – and then rapidly iterating based on feedback.

The Smalltalk style of object-oriented programming also evinces the laboratory way of thinking. Loose coupling via message-sending lets programmers replace the collaborating objects in a system with other objects easily and quickly. Integrated development and deployment environments enable a style called Debugger-Driven Design—https://medium.com/concerning-pharo/pharo-50c66685913c: find the thing that breaks the system because you haven't built it yet, build it, then let the system carry on with its new behavior.

The Library School

The library school is the research-driven approach. Understand your problem, discover the properties of a solution that appropriately addresses the problem, implement the solution with those properties.

The disciplines related to object-oriented software engineering show associations with the library school. While the Rational Unified Process, as one example, does promote iterative and incremental development, the increments tend to be additive rather than exploratory: build the walking skeleton, then design, implement, and test this use case, then that use case. Add more use cases until the funding runs out. Make sure that at each step you retain your carefully-considered hierarchy of class relationships.

The if it type checks, it works principle in programming appears to come from the library school. A type system is a machine for constructing proofs about the software that uses types from that system. Design your software with consistent application of those types and you get theorems for free (https://ecee.colorado.edu/ecen5533/fall11/reading/free.pdf) about the behavior of the software.

Design by contract demonstrates library-school thinking applied to OOP. The principle characteristic of an object is not its named type, but its shape: the messages it responds to and the things it does in response to those messages. Taking the mathematical proof tools from formal methods and applying them to the shape of objects, you end up with the contract: a mathematical statement about the messages an object responds to and the behavior resulting from receiving those messages.

The Labrary

There are lessons to be learned from each of these schools of thought, and rather than siding with either one, the system described here adopts details from both. Not in an additive let's do all the things these people do, and add all the things these people do way, but in a synthetic let's see what ideas these people promote and how they can be combined way. We have contracts from the library, but don't require design by contract: they are part of a live, experimental system from the laboratory that can be added and removed at any time.

There is of course, one big problem with this environment, produced by the synthetic "Labrary" school of thought. That problem is that the environment doesn't exist. Yet. To the Labrary!