8 min read

Python 3 Object Oriented Programming

Python 3 Object Oriented Programming

Harness the power of Python 3 objects

  • Learn how to do Object Oriented Programming in Python using this step-by-step tutorial
  • Design public interfaces using abstraction, encapsulation, and information hiding
  • Turn your designs into working software by studying the Python syntax
  • Raise, handle, define, and manipulate exceptions using special error objects
  • Implement Object Oriented Programming in Python using practical examples     

Object-oriented?

Everyone knows what an object is: a tangible “something” that we can sense, feel, and manipulate. The earliest objects we interact with are typically baby toys. Wooden blocks, plastic shapes, and over-sized puzzle pieces are common first objects. Babies learn quickly that certain objects do certain things. Triangles fit in triangle-shaped holes. Bells ring, buttons press, and levers pull.

The definition of an object in software development is not so very different. Objects are not typically tangible somethings that you can pick up, sense, or feel, but they are models of somethings that can do certain things and have certain things done to them. Formally, an object is a collection of data and associated behaviors.

So knowing what an object is, what does it mean to be object-oriented? Oriented simply means directed toward. So object-oriented simply means, “functionally directed toward modeling objects”. It is one of many techniques used for modeling complex systems by describing a collection of interacting objects via their data and behavior.

If you’ve read any hype, you’ve probably come across the terms object-oriented analysis, object-oriented design, object-oriented analysis and design, and object-oriented programming. These are all highly 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 style of software development is being pursued.

Object-oriented Analysis (OOA) is the process of looking at a problem, system, or task that somebody wants to turn into an 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 set of requirements. If we were to complete the analysis stage in one step, we would have turned a task, such as, “I need a website”, into a set of requirements, such as:

Visitors to the website need to be able to (italic represents actions, bold represents objects):

  • review our history
  • apply for jobs
  • browse, compare, and order our products

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 what objects can activate specific behaviors on other objects. The design stage is all about how things should be done. The output of the design stage is an implementation specification. If we were to complete the design stage in one step, we would have turned the requirements into a set of classes and interfaces that could be implemented in (ideally) any object-oriented programming language.

Object-oriented Programming (OOP) is the process of converting this perfectly defined design into a working program that does exactly what the CEO 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 like 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. In the fast-paced modern world, most development happens in an iterative development model. In iterative development, a small part of the task is modeled, designed, and programmed, then the program is reviewed and expanded to improve each feature and include new features in a series of short cycles.

In this article we will cover the basic object-oriented principles in the context of design. This allows us to understand these rather simple concepts without having to argue with software syntax or interpreters.

Objects and classes

So, an object is a collection of data with associated behaviors. How do we tell two types of objects apart? Apples and oranges are both objects, but it is a common adage that they cannot be compared. Apples and oranges aren’t modeled very often in computer programming, but let’s pretend we’re doing an inventory application for a fruit farm! As an example, we can assume that apples go in barrels and oranges go in baskets.

Now, we have four kinds of objects: apples, oranges, baskets, and barrels. In object-oriented modeling, the term used for kinds of objects is class. So, in technical terms, we now have four classes of objects.

What’s the difference between an object and a class? Classes describe objects. They are like blueprints for creating an object. You might have three oranges sitting on the table in front of you. Each orange is a distinct object, but all three have the attributes and behaviors associated with one class: the general class of oranges.

The relationship between the four classes of objects in our inventory system can be described using a Unified Modeling Language (invariably referred to as UML, because three letter acronyms are cool) class diagram. Here is our first class diagram:

Python 3: Object-Oriented Design

This diagram simply shows that an Orange is somehow associated with a Basket and that an Apple is also somehow associated with a Barrel. Association is the most basic way for two classes to be related.

UML is very popular among managers, and occasionally disparaged by programmers. The syntax of a UML diagram is generally pretty obvious; you don’t have to read a tutorial to (mostly) understand what is going on when you see one. UML is also fairly easy to draw, and quite intuitive. After all, many people, when describing classes and their relationships, will naturally draw boxes with lines between them. Having a standard based on these intuitive diagrams makes it easy for programmers to communicate with designers, managers, and each other.

However, some programmers think UML is a waste of time. Citing iterative development, they will argue that formal specifications done up in fancy UML diagrams are going to be redundant before they’re implemented, and that maintaining those formal diagrams will only waste time and not benefit anyone.

This is true of some organizations, and hogwash in other corporate cultures. However, every programming team consisting of more than one person will occasionally have to sit down and hash out the details of part of the system they are currently working on. UML is extremely useful, in these brainstorming sessions, for quick and easy communication. Even those organizations that scoff at formal class diagrams tend to use some informal version of UML in their design meetings, or team discussions.

Further, the most important person you ever have to communicate with is yourself. We all think we can remember the design decisions we’ve made, but there are always, “Why did I do that?” moments hiding in our future. If we keep the scraps of paper we did our initial diagramming on when we started a design, we’ll eventually find that they are a useful reference.

UML covers far more than class and object diagrams; it also has syntax for use cases, deployment, state changes, and activities. We’ll be dealing with some common class diagram syntax in this discussion of object-oriented design. You’ll find you can pick up the structure by example, and you’ll subconsciously choose UML-inspired syntax in your own team or personal design sessions.

Our initial diagram, while correct, does not remind us that apples go in barrels or how many barrels a single apple can go in. It only tells us that apples are somehow associated with barrels. The association between classes is often obvious and needs no further explanation, but the option to add further clarification is always there. The beauty of UML is that most things are optional. We only need to specify as much information in a diagram as makes sense for the current situation. In a quick whiteboard session, we might just quickly draw lines between boxes. In a formal document that needs to make sense in six months, we might go into more detail. In the case of apples and barrels, we can be fairly confident that the association is, “many apples go in one barrel”, but just to make sure nobody confuses it with, “one apple spoils one barrel”, we can enhance the diagram as shown:

Python 3: Object-Oriented Design

This diagram tells us that oranges go in baskets with a little arrow showing what goes in what. It also tells us the multiplicity (number of that object that can be used in the association) on both sides of the relationship. One Basket can hold many (represented by a *) Orange objects. Any one Orange can go in exactly one Basket.

It can be easy to confuse which side of a relationship the multiplicity goes on. The multiplicity is the number of objects of that class that can be associated with any one object at the other end of the association. For the apple goes in barrel association, reading from left to right, many instances of the Apple class (that is many Apple objects) can go in any one Barrel. Reading from right to left, exactly one Barrel can be associated with any one Apple.

LEAVE A REPLY

Please enter your comment!
Please enter your name here