Lecture 20: Design Alternatives

– the direction of the call – server-client diagram

Though it came from many motivations, two were central. ... The small scale one was to find a more flexible version of assignment, and then to try to eliminate it altogether — Alan Kay, History of SmallTalk, 1993

The design of the player-referee interface is really a choice among many alternatives. Indeed, you can think of it as a spectrum with conventional object-oriented design on one end and functional design on the other.

An interface design starts from an understanding of “which software components knows what” and the question of “which component needs to know what.” The follow-up question is “is there a common understanding of knowledge” (common ontology) and “how is the knowledge conveyed.”

How and when should the server interact with the clients?

The object-oriented alternative is that after every interaction with one client, the server shares the newly acquired public knowledge with all other clients. It becomes the client’s job to collect all the small pieces of new knowledge and maintain a consistent view for its own sake.

The functional alternative is that the server waits until it must interact with a specific client and then shares all relevant public knowledge since the last interaction with this specific client, including any newly acquired and old knowledge. Here the server maintains a consistent view of (all) knowledge and shares everything as appropriate.

Some (social) contexts determine which alternative—or which compromise between these two alternatives—has to be implemented. Some others leave it to the software architect or even to the programmer.

In the context of a software system that consists of distributed, communicating programs on the internet, the object-oriented design dominated the world until the advent of the web. Given the freedom of the dominant TCP protocol and the mindset of programmers, this choice was a natural one. The web superimposed a new protocol, HTTP(s), on top of the internet, and this protocol leans towards functional programming. The web client sends a request to the web server and gets a complete page in response; it basically conducts a function call. The app layer on top of this web-page layer has become even more explicitly functional; most of these apps get their information via “function calls” to so-called endpoints. RESTful has become the slogan.

The functional design is winning out because of two key advantages. First, it reduces the number of remote interactions and the associated programming overhead in ordinary programming languages. Furthermore, networking suggests that means that reasonably large, infrequent communications are superior to frequent small message exchanges. Second, functional interactions are far more easily testable than object-oriented ones. Unit testing—and property testing more recently—emerged in parallel to the transition from the internet (TCP) to the web and apps (HTTP). Since debugging distributed communicating system is hard, anything that improves testing is highly welcome.

09:15am

01:35pm

04:35pm