Modern Programming: Object Oriented Programming and Best Practices

Deconstruct object-oriented programming and use it with other programming paradigms to build applications

Graham Lee

• Publisher: Packt Publishing
• Year: 2019
• ISBN:
  9781838986902
• Edition: 1
• Topic: Informatique
• Subtopic: Programmation

Discover the untapped features of object-oriented programming and use it with other software tools to code fast, efficient applications.

Key Features

• Explore the complexities of object-oriented programming (OOP)
• Discover what OOP can do for you
• Learn to use the key tools and software engineering practices to support your own programming needs

Book Description

Your experience and knowledge always influence the approach you take and the tools you use to write your programs. With a sound understanding of how to approach your goal and what software paradigms to use, you can create high-performing applications quickly and efficiently.

In this two-part book, you'll discover the untapped features of object-oriented programming and use it with other software tools to code fast and efficient applications. The first part of the book begins with a discussion on how OOP is used today and moves on to analyze the ideas and problems that OOP doesn't address. It continues by deconstructing the complexity of OOP, showing you its fundamentally simple core. You'll see that, by using the distinctive elements of OOP, you can learn to build your applications more easily.

The next part of this book talks about acquiring the skills to become a better programmer. You'll get an overview of how various tools, such as version control and build management, help make your life easier. This book also discusses the pros and cons of other programming paradigms, such as aspect-oriented programming and functional programming, and helps to select the correct approach for your projects. It ends by talking about the philosophy behind designing software and what it means to be a "good" developer.

By the end of this two-part book, you will have learned that OOP is not always complex, and you will know how you can evolve into a better programmer by learning about ethics, teamwork, and documentation.

What you will learn

• Untangle the complexity of object-oriented programming by breaking it down to its essential building blocks
• Realize the full potential of OOP to design efficient, maintainable programs
• Utilize coding best practices, including TDD, pair programming and code reviews, to improve your work
• Use tools, such as source control and IDEs, to work more efficiently
• Learn how to most productively work with other developers
• Build your own software development philosophy

Who this book is for

This book is ideal for programmers who want to understand the philosophy behind creating software and what it means to be "good" at designing software. Programmers who want to deconstruct the OOP paradigm and see how it can be reconstructed in a clear, straightforward way will also find this book useful. To understand the ideas expressed in this book, you must be an experienced programmer who wants to evolve their practice.

Part One – OOP The Easy Way

What is object-oriented programming? My guess is that object-oriented programming will be in the 1980’s what structured programming was in the 1970’s. Everyone will be in favor of it. Every manufacturer will promote his products as supporting it. Every manager will pay lip service to it. Every programmer will practice it (differently). And no one will know just what it is.

Tim Rentsch, Object oriented programming—https://dl.acm.org/citation.cfm?id=947961

Object-Oriented Programming (OOP) has its beginnings in the simulation-focused features of the Simula programming language but was famously developed and evangelized by the Smalltalk team at Xerox’s Palo Alto Research Center. They designed a computing system intended to be personal, with a programming environment accessible to children who could learn about the world and about the computer simultaneously by modeling real-world problems on their computer.

I recently researched the propagation and extension of OOP from PARC to the wider software engineering community, which formed the background to my dissertation We Need to (Small)Talk: object-oriented programming with graphical code browsers—https://www.academia.edu/34882629/We_need_to_Small_talk_object-oriented_programming_with_graphical_code_browsers. What I found confused me: how had this simple design language for children to construct computer programs become so complicated and troublesome that professional software engineers struggled to understand it before declaring it a failure and reaching for other paradigms?

A textbook on my shelf, “A Touch of Class,” by Bertrand Meyer, claims to be “a revolutionary introductory programming textbook that makes learning programming fun and rewarding.” At 876 pages, it makes it a good workout, too: not for the schoolchild, but for the “entering-computer-science student” at degree level.

Digging further showed that the field of object thinking, object technology, OOP, or whatever you would like to call it had been subject to two forces:

• Additive complexity. Consultants, academics, and architects keen to make their mark on the world had extended basic underlying ideas to provide their own, unique, marketable contributions. While potentially valuable in isolation, the aggregation of these additions (and they were, as we shall see, deliberately aggregated in some cases) yields a rat’s nest of complexity.
• Structured on-ramps. To make OOP appear easier and more accessible, people developed “object-oriented” extensions to existing programming tools and processes. While this made it easy to access the observable features of OOP, it made it ironically more difficult to access the mental shift needed to take full advantage of what is fundamentally a thought process and problem-solving technique. By fitting the object model into existing systems, technologists doomed it to stay within existing mindsets.

About the Example Code

In this part of the book, I have consciously chosen to use “mainstream,” popular programming languages wherever possible. I have not stuck to any one language, but have used things that most experienced programmers should be able to understand at a glance: Ruby, Python, and JavaScript will be common. Where I’ve used other languages, I’ve done so to express a particular historical context (Smalltalk, Erlang, and Eiffel will be prevalent here) or to show ideas from certain communities (Haskell or Lisp).

One of the points of this part of the book is that as a cognitive tool, OOP is not specific to any programming language, and indeed many of the languages that are billed as object-oriented languages make what (or at least large parts of what) harder. Picking any one language for the sample code would then mean only presenting a subset of OOP.

Chapter 1

Antithesis

Telling an Object What to Do

The big idea is "messaging" – that is, what the kernal [sic] of Smalltalk/Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase). The Japanese have a small word – ma – for "that which is in between" – perhaps the nearest English equivalent is "interstitial." The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be.

Alan Kay, (squeak-dev mailing list — http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html)

A huge amount of complexity is wrapped up in that most common of operations: invoking an object's method. In many programming languages – C++, Java, Python, and others – this takes the form anObject.methodName(), which means "there will be a method on the class that anObject is an instance of, or some antecedent class, where the method is called methodName, please find it and run it, with the self or this value aliased to anObject." So, for example, in Java we would expect to find a (non-abstract) public void methodName() { /* ... */ } somewhere in anObject's class or parent.

This guarantee introduces a lot of coupling between the caller and the object that holds the method:

1. The caller knows that the object is an instance of some class (there are so many issues bound up with inheritance that it gets its own chapter, later).
2. The caller knows that the object's class, or some ancestor of it, provides a method with the given name.
3. The method will run to completion in this context, then give control back to the caller (this is not particularly evident from the syntax in isolation, but nonetheless is assumed).

What would it mean to lift those assumptions? It would make the object a truly independent computer program, communicating from a distance over an agreed protocol based on message passing. What that object does, how it does it, even what programming language it's implemented in, are all private to the object. Does it collaborate with a class to find out how to respond to the message? Does that class have one parent or multiple parents?

The idea behind message-passing is exactly that arms-length separation of concerns, but even programming languages that are based on the message-passing scheme usually treat it as a special case of "look up a method," to be followed only if the usual method-resolution fails. These languages typically have a particular named method that will be run when the requested method isn't found. In Smalltalk, it's called doesNotUnderstand:, while in Ruby it's called method_missing(). Each one receives the selector (that is, the unique name of the method the caller was hoping to invoke) to decide what to do with it. This gets us a higher level of decoupling: objects can send messages to one another without having to peek at the others' implementations to discover whether they implement a method matching the message.

Why is that decoupling valuable? It lets us build our objects as truly standalone programs, considering only what their contract is with the outside world and how their implementation supports that contract. By requiring, for example, that an object will only receive a message if it is an instance of a class that contains a Java function of the same name that can be pushed onto the call stack, even if via a Java interface (a list of methods that a Java class can provide), we adopt a lot of assumptions about the implementation of the message receiver, turning them into constraints that the programmer must deal with when building the sender. We do not have independent, decoupled programs collaborating over a message interface, but a rigid system with a limited amount of modularity. Understanding one object means pulling in information about other parts of the system.

This is not merely an academic distinction, as it constrains the design of real systems. Consider an application to visualize some information about a company's staff, which is located in a key-value store. If I need every object between the view and the store to know about all of the available methods, then I either duplicate my data schema everywhere in the app by defining methods like salary() or payrollNumber(), or I provide meaningless generic interfaces like getValue(String key) that remove the useful information that I'm working with representations of people in the company.

Conversely, I could say to my Employee object "if you get a message you do not recognize, but it looks like a key in the key-value store, reply with the value you find for that key." I could say to my view object "if you get a message you do not recognize, but the Employee gives you a value in response to it, prepare that value for display and use the selector name as the label for that value." The behavior – looking up arbitrary values in the key-value store – remains the same but the message network tells us more about why the application is doing what it does.

By providing lazy resolution paths like method_missing, systems like Ruby partially lift these assumptions and provide tools to enable greater decoupling and independence of objects in the network. To fully take advantage of this, we must change the language used and the way we think about these features.

A guide to OOP in Ruby will probably tell you that methods are looked up by name, but if that fails, the class can optionally implement method_missing to supply custom behavior. This is exactly backwards: saying that objects are bags of named methods until that stops working, when they gain some autonomy.

Flip this language: an object is responsible for deciding how it handles messages, and one particular convenience is that they automatically run methods that match a received selector without any extra processing. Now your object truly is an autonomous actor responding to messages, rather than a place to store particular named routines in a procedural program.

There are object systems that expose this way of thinking about objects, a good example being the CMU Mach system. Mach is an operating system kernel that supplies communication between threads (in the same or different tasks) using message passing. A sender need know nothing about the receiver other than its port (the place to put outgoing messages) and how to arrange a message to be put in the port. The receiver knows nothing about the sender; just that a message has appeared on its port and can be acted on. The two could be in the same task, or not even on the same computer. They do not even need to be written in the same language, they just need to know what the messages are and how to put them on a port.

In the world of service-oriented architecture, a microservice is an independent program that collaborates with peers over a loosely coupled interface comprised of messages sent over some implementation-independent transport mechanism – often HTTPS or protocol buffers. This sounds a lot like OOP.

Microservice adopters are able to implement different services in different technologies, to think about changes to a given service only in terms of how they satisfy the message contract, and to independently replace individual services without disrupting the whole system. This, too, sounds a lot like OOP.

Designing an Object

The object-oriented approach attempts to manage the complexity inherent in real-world problems by abstracting out knowledge and encapsulating it within objects. Finding or creating these objects is a problem of structuring knowledge and activities.

Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener, Designing Object-Oriented Software

An early goal of OOP was to simplify the work of software system design by reducing the big problem "design this large system to solve these problems" into the small problems "design these small systems" and "combine these small systems such that they solve these problems in concert". Brad Cox, an object technologist who built the Objective-C language and cofounded a company to exploit it, wrote an article "What if there's a Silver Bullet...And the Competition Gets It First?" in which he asserted that OOP represented a significant reduction in software complexity.

In the broadest sense, "object-oriented" refers to the war and not the weapons, the ends and not the means, an objective rather than technologies for achieving it. It means orienting on objects rather than on processes for building them; wielding all the tools programmers can muster, from well-proven antiques like Cobol to as-yet missing ones like specification/testing languages, to enable software consumers, letting them reason about software products with the common-sense skills we all use to understand the tangible objects of everyday experience.

It means relinquishing the traditional proc...