Monday, September 26, 2016

Abstract Data Types

I was reading "Contracts, Scenarios and Prototypes" and learned that Abstract Data Types were first presented by Barbara Liskov and Stephen Zilles in their paper "Programming with abstract data types" (requires access to the ACM Digital Library). The main contribution made by this paper is that it identifies an abstract data type as class of object completely characterized by the operations it can perform.

Liskov and Zilles' paper was written in 1974. It lists thirteen references that provide insight on how abstract data types were arrived at. It's an interesting list of references including work from Dijkstra, Neumann, Parnas and Wirth.

What is compelling about the introduction of "Contracts, Scenarios and Prototypes" is the depth of the references provided on the development of contracts. In addition to abstract data types, this introduction includes a look at Hoare's "An Axiomatic Basis for Computer Programming" which introduces pre- and post-conditions via Hoare Triples and Parnas' "A Technique for Software Module Specifications with Examples" for description of good specifications and strongly typed languages.

Saturday, September 3, 2016

Object-Oriented Programming: A Disaster Story

Read Object-Oriented Programming: A Disaster Story, not so much for what it said but for what ended up on Reddit. If you are looking for perspectives on object-oriented programming, the comments are a good read.

One commenter, discussed Closures and Objects are Equivalent, another brought in Alan Kay on Object-Oriented Programming. Both reasonable responses.

In my opinion, the best comment:
The value of objects is in treating systems behaviourally. Inheritance and even immutability are orthogonal. An object is a first-class, dynamically dispatched behaviour.   (/u/discretevent)
The lesson, is know your tools, use them appropriately and recognize their limitations. Orthogonality is a good way to organize your thinking on this.

In Object-Oriented Programming: A Disaster Story,  I do agree that shallow object hierarchies are better than deep but I'm not sure if the argument presented there is in response to programs that derive all classes from the same object or and argument against deep class hierarchies.

With respect to
Among OOP practitioners, there are competing schools of thought on the degree to which a program’s behaviors should be expressed as class methods rather than free-floating functions.
Isn't the correct answer to apply what is appropriate to the context?

I've made arguments wherein a free-floating function is the best tool for ensuring consistency between different classes whose behaviour is related only due to business rules and logic. For example. do you want a manager class in an automobile that ensures the lights are on and the doors are locked while driving? You can construct arguments for both approach.

The right approach is the one that leads to the simplest implementation. In this case, I agree with the author and avoid "nonsense Doer" classes.

There is a great set of comments in the Reddit thread relating to context and object decomposition.