Introducing Object-Oriented Paradigm

Everyone knows what an object is: a tangible thing that we can sense, feel, and manipulate. The earliest objects we interact with are typically baby toys. Wooden blocks, plastic shapes, and oversized puzzle pieces are common first objects. Babies learn quickly that certain objects do certain things: bells ring, buttons are pressed, and levers are pulled.

The definition of an object in software development is not terribly different. Software objects may not be tangible things that we can pick up, sense, or feel, but they are models of something that can do certain things and have certain things done to them. Formally, an object is a collection of attributes and associated behaviors.

Considering what an object is, what does it mean to be object-oriented? In the dictionary, oriented means directed toward. Object-oriented programming means writing code directed toward modeling objects. This is one of many techniques used for describing the actions of complex systems. It is defined by describing a collection of interacting objects via their attribute and behavior. At some stage in our lives, we’ve probably come across the terms object-oriented analysis, object-oriented design, object-oriented analysis and design, and object-oriented programming. These are all related concepts under the general object-oriented umbrella.

In fact, analysis, design, and programming are all stages of software development. Calling them object-oriented simply specifies what kind of software development is being pursued.

Object-oriented analysis

Object-oriented analysis (OOA) is the process of looking at a problem, system, or task (that somebody wants to turn into a working software application) and identifying the objects and interactions between those objects. The analysis stage is all about what needs to be done.

The output of the analysis stage is a description of the system, often in the form of requirements. In order to grasp the concept of object-oriented analysis, let’s have a look at an example. A botanist needs a website to help users classify plants so he can help with correct identification, into a set of required features. As an example, here are some requirements as to what a website visitor might need to do. Each item is an action bound to an object; we’ve written them here in italics to highlight the actions and bold to highlight the objects:

• Browse previous uploads
• Upload new known examples
• Test for quality
• Browse products
• See recommendations

In some ways, the term analysis is a misnomer. The baby we discussed earlier doesn’t analyze the blocks and puzzle pieces. Instead, she explores her environment, manipulates shapes, and sees where they might fit. A better turn of phrase might be object-oriented exploration. In software development, the initial stages of object-oriented analysis include interviewing customers, studying their processes, and eliminating possibilities.

Object-oriented design

Object-oriented design (OOD) is the process of converting such requirements into an implementation specification. The designer must name the objects, define the behaviors, and formally specify which objects can activate specific behaviors on other objects. The design stage is all about transforming what should be done into how it should be done.

The output of the design stage is an implementation specification. If we were to complete the design stage in a single step, we would have turned the requirements defined during object-oriented analysis into a set of classes and interfaces that could be implemented in (ideally) any object-oriented programming language.

Object-oriented programming

Object-oriented programming (OOP) is the process of converting a design into a working program that does what the product owner originally requested. Yeah, right! It would be lovely if the world met this ideal and we could follow these stages one by one, in perfect order, as all the old textbooks told us to. As usual, the real world is much murkier. No matter how hard we try to separate these stages, we’ll always find things that need further analysis while we’re designing. When we’re programming, we find features that need clarification in the design. Most 21st-century development recognizes that this cascade (or waterfall) of stages doesn’t work out well. What seems to be better is an iterative development model. In iterative development, a small part of the task is modeled, designed, and programmed, and then the product is reviewed and expanded to improve each feature and include new features in a series of short development cycles.

The rest of this course is about object-oriented programming, but in this chapter, we will cover the basic object-oriented principles in the context of design. This allows us to understand concepts without having to argue with software syntax or Python tracebacks.