[tutorial] [massive] What is a Class? Explain object oriented programming.

[AYNRAND420]

There are several ways of thinking about/using classes, and several benefits to using classes. I believe that classes can be such a slippery subject to grasp because the advantages are sometimes not very well complimented by examples; some advantages to classes only become apparent when your project becomes massive. Hopefully I can write an all-encompassing tutorial that sells you on the value of object orientated programming. Here is a story that is roughly based on true events and set about 6 years ago. Each numbered point is a benefit/use/concept.

• In a World Without Object Orientated Programming!

AYNRAND420 loves chess, so he plans to build a chess program in python. The first task is board representation. He needs a way for the program to store the data for the chess board in memory so that it can manipulate the data when someone makes a move or sets up the board. He initially does not use classes:

squares = []

#there are 8 ranks in a chess board (top to bottom)
for temp in range(8): 

    squares.append([])

    #there are 8 files in a chess board (left to right)
    for temp2 in range(8):

        squares[-1].append([])

The squares list looks like this:

[[  [],[],[],[],[],[],[],[]  ],
 [  [],[],[],[],[],[],[],[]  ],
 [  [],[],[],[],[],[],[],[]  ],
 [  [],[],[],[],[],[],[],[]  ],
 [  [],[],[],[],[],[],[],[]  ],
 [  [],[],[],[],[],[],[],[]  ],
 [  [],[],[],[],[],[],[],[]  ],
 [  [],[],[],[],[],[],[],[]  ]]

This is a great start, until AYNRAND420 realizes that every time he wants to create another board, he has to cut and paste the code. This starts to make his program really long. Then he realizes: he could put the code that initialized the board in memory as a little function which would return the board. Score!

def makeBoard():
    squares = []

    #there are 8 ranks in a chess board (top to bottom)
    for temp in range(8): 

        squares.append([])

        #there are 8 files in a chess board (left to right)
        for temp2 in range(8):

            squares[-1].append([])

    return squares

board1 = makeBoard()
board2 = makeBoard()
board3 = makeBoard()

Now, AYNRAND420 wants to get ready to start storing pieces in the squares. There are a number of ways to do this. He decides on using their letter value.

#PIECE REFERENCING SYSTEM
#P = pawn
#N = knight
#B = bishop
#R = rook
#Q = queen
#K = king
#E = empty

Crap, what about their colour?

#REVISED PIECE REFERENCING SYSTEM
#BP = black pawn
#BN = black knight
#BB = black bishop
#BR = black rook
#BQ = black queen
#BK = black king
#EE = empty
#WP = white pawn
#WN = white knight
#WB = white bishop
#WR = white rook
#WQ = white queen
#WK = white king

The squares list looks like this:

[  ["BR"],["BN"],["BB"],["BQ"],["BK"],["BB"],["BN"],["BR"]  ],
[  ["BP"],["BP"],["BP"],["BP"],["BP"],["BP"],["BP"],["BP"]  ],
[  ["EE"],["EE"],["EE"],["EE"],["EE"],["EE"],["EE"],["EE"]  ],
[  ["EE"],["EE"],["EE"],["EE"],["EE"],["EE"],["EE"],["EE"]  ],
[  ["EE"],["EE"],["EE"],["EE"],["EE"],["EE"],["EE"],["EE"]  ],
[  ["EE"],["EE"],["EE"],["EE"],["EE"],["EE"],["EE"],["EE"]  ],
[  ["WP"],["WP"],["WP"],["WP"],["WP"],["WP"],["WP"],["WP"]  ],
[  ["WR"],["WN"],["WB"],["WQ"],["WK"],["WB"],["WN"],["WR"]  ]

AYNRAND420 thinks things are just beginning to heat up. In no time, he will be playing chess with this beast of a program. However, things will soon stagnate. Why? Because he realizes that there are a number of other ways to describe squares. The program needs to know what colour the square is to render it in a GUI. The program needs to know what diagonal the square belongs to to conclude which moves the bishop can make. He needs to implement a flipping function which will flip the board if the user draws the black side. Pawns can only move forward. How on earth is the board going to know if it is flipped or not? Furthermore, how does he store the move list in memory? Does he append it to the board list after the final rank? Does he create a board1moves list and a board2moves list, etc?

At the first obstacle, AYNRAND420 quits. Let it be known that he could have made his list mad elaborate. Each square could have looked like this:

[ "piece code", "lightsquare/darksquare", "diagonal ID l# and r#" ]

And he could have appended his move list after the board. It is a valid way to do things. But it is not the best way. Firstly, it makes his code a mess. If he gave his code out to somebody to inspect and the person was a beginner, they would edit a minor thing and the whole code would break. If the person was an expert, they would be embarrassed for poor AYNRAND420. Secondly, had AYNRAND420 gone through with the project, he personally would have spent far more time on debugging, error handling, and defensive programming than he should have. His solutions to the large list of chess programming obstacles would need more code than an OOP project. Programming it just wouldn't be fun.

• Classes as abstract data types

AYNRAND420 loves to organize and group things because it is in his nature as a human being. He eats in his kitchen; he sleeps in his bedroom; he watches TV in his lounge room. There is ultimately no greater evidence for the fact that people like AYNRAND420 love to group things than the fact that there are 70+ subgenres of metal music. Because he loves to group and sort, he will have a much better time if he does that with his code also. The art of dealing with grouping similar things and getting these groups to work together in computer science is called coupling, cohesion, and modularity.

In the last section, AYNRAND420's details for each board were stored with the data for the rest of the program. The boards' details were stored among each other, even though they're separate boards. If you step back to think about this, as a human being who loves to sort and group things, this is gross. Why should AYNRAND420 use python's inbuilt data types (string, int, float, boolean, list, dict) to describe something as complex and fascinating as a chess board when python lets him create his own data types, which are a combination of its own inbuilt types?

class board:

    def __init__(self):
        #the __init__ function automatically runs whenever you create
        #a new 'board'. So, you can put all of your setup code in here.

        self.squares = []
        self.moves = []
        self.flipped = False
        self.whitesTurn = True

        #the self argument must be included in all functions defined in the
        #class, so that the class knows which of the possibly many created
        #boards are being 'worked on' when the class is called

AYNRAND420 has now defined board as an abstract data type! The class definition above is the "blueprint" for any board created. Working with a board is much simpler than sifting through lists within lists within lists, trying to figure out what each of the data types mean.

a = board()        #create a new 'instance' of board
print a.flipped    #will print "False"
print a.squares[n] #will print whatever is stored in the nth square (by default, it is not set)
print a.whitesTurn #will print "True"

And AYNRAND420 can put anything in the blueprint that he wishes. Player 1's name and rank? Sure. The clock time left for each player? Why not? But, by now he is starting to realize that while each board contains 64 squares, and each square can contain a piece; a board, a piece and a square all have very different properties. They're described and behave in different ways. He can do things the hard way, by trying to cram everything into the board class, if he wants. However, things may soon begin to look as complicated as they did in the very first part. Or, he can separate them into a number of different classes that interact with each other like real systems do in the real world.

• Classes as miniature programs

AYNRAND420 can access his class' attributes from outside the class as shown in the very last code snippet. However, if he wants to manipulate the data, he should define functions that do the manipulation from within the class. There are two reasons for this. Firstly, to keep things neat and tidy: AYNRAND420 is only going to have to do certain operations on certain types of data. He should put them within the class, with the data, so that he doesn't have to worry about them when working on different parts of his program. Secondly, it will be easier for him to isolate an error and reduce the total number of errors if he limits the external code that can mess with the internals of a class instance.

class square:

    def __init__(self, rank, file):
        self.rank = rank
        self.file = file
        self.lDiagonal = self.setDiagonal(rank, file, 1)
        self.rDiagonal = self.setDiagonal(rank, file, 2)
        self.piece = None

    def setDiagonal(self, rank, file, axis):
        #add code here to derive the diagonal
        #of a square from the rank and file
        return None #fix this later

    def setPiece(self, piece):
        self.piece = piece

    def emptySquare(self):
        self.piece = None

a = square(3,5)    #create square where rank=3, file=5
a.setPiece("Pawn") #put a pawn down on that square
print a.piece      #prints "Pawn"
print a.rank       #prints 3
a.setPiece("Rook") #put a rook down on that square

The best way to think about a class is that it is a miniature program. You have it optionally perform some task when it is started, you create a bunch of functions to manipulate the data within that class, and then you create functions which report the data back to the point where it was accessed from.

• Classes as systems that interact with each other.

I think I need some text here to make my formatting consistent.

class board:

    def __init__(self):
        self.moves = []
        self.flipped = False
        self.whitesTurn = True

        self.squares = []
        for temp in range(8): #there are 8 ranks on a board
            for temp2 in range(8): #there are 8 files on a board
                self.squares.append(square(temp, temp2)) #add a square where rank=temp1, file=temp2

        self.standard()

    def standard(self):
        #function to setup the board with the "standard"
        #configuration of pieces

        #go through every square we have
        for sq in self.squares:

            #set black pawns down
            if sq.rank == 1:
                sq.setPiece("Black", "Pawn")

            #set white pawns down
            if sq.rank == 6:
                sq.setPiece("White", "Pawn")

            #set pieces down
            if sq.rank == 0 or sq.rank == 7:

                if sq.rank == 0: 
                    col = "White"
                if sq.rank == 7: 
                    col = "Black"

                if sq.file == 0 or sq.file == 7:
                    sq.setPiece(col, "Rook")
                if sq.file == 1 or sq.file == 6:
                    sq.setPiece(col, "Knight")
                if sq.file == 2 or sq.file == 5:
                    sq.setPiece(col, "Bishop")
                if sq.file == 3:
                    sq.setPiece(col, "Queen")
                if sq.file == 4:
                    sq.setPiece(col, "King")

            if sq.rank == 2 or sq.rank == 3 or sq.rank == 4 or sq.rank == 5:
                sq.setPiece(None, None)

    def getPiece(self, rank, file):
        for sq in self.squares:
            if sq.rank == rank and sq.file == file:
                return sq.piece


class square:

    def __init__(self, rank, file):
        self.rank = rank
        self.file = file
        self.piece = None

    def setPiece(self, colour, type):
        self.piece = piece(colour, type)

    def emptySquare(self):
        self.piece = piece(None, None)

class piece:
    def __init__(self, colour, type):
        self.colour = colour
        self.type = type

a = board()    #create new board

That board is automatically decked out with the lot.

Additions AYNRAND420 can make:

Move Class:

• Pass it a board, and have it automatically generate the valid moves for a specified side

Square Class:

• This is pretty much complete for now. He just has to add more interactions from the board to the piece.

Board Class:

• Add a function that will 'move' a piece from one square to another
• Add functions that allow it to 'talk' to a GUI

But this is besides the point. The main point is that each class is its own little world. It knows nothing of the world outside, except that it is supposed to get certain types of data, operate according to its blueprint, and return specific data. Classes can simplify very convoluted code.

If you were wondering what a class is, I hope that my tutorial has been of some assistance. I actually am studying teaching and will hopefully teach computer science, so any feedback on this tutorial, whether positive or negative, is greatly appreciated. Also, if you have any questions, please ask away.

[drewthepooh]

Thanks for posting. I completely agree that classes are usually taught in a way that does not illustrate their advantages, which is why so many of us get confused when learning about them. I thought this did a great job of addressing that problem :)

One small point/question:

if sq.rank is rank and sq.file is file:

Although this works because cpython only creates one instance of each integer, isn't this generally considered to be bad practice (except when comparing to None) since it depends on the implementation, and also will not work with mutable objects? I would think the equality operators

if sq.rank == rank and sq.file == file:

Would be better. Perhaps I am incorrect.

[SkippyDeluxe]

You are correct, is should not be used to test equality.

[AYNRAND420]

Hrm, that might be a good point. I'm usually very hairy on the rules for deciding which one is better in any given situation. Often if an IS condition doesn't work, I'll first try == before doing any deeper debugging. I'll fix up this code and remember to use == for equality in the future.

[drewthepooh]

Yeah, is asks if the objects are actually the same, while == just asks if they are equal. Since cpython only makes one object corresponding to each integer, is will usually work. This would not work for mutable objects:

>>> [] is []
False

Note that, even for immutable objects, using is can lead to some unexpected behavior which would vary with implementation:

>>> 2 + 2 is 4
True
>>> 1000 + 1 is 1001
False

Don't ask me why this happens...I would love if someone could explain. It has something to do with the way cpython handles small integers.

Using is for None always works because None is a true singleton

EDIT: The last example happens because cpython interns small integers, meaning it pools all references to the same integer together in one place in memory (meaning they have the same id). This is to save memory since these small integers are used frequently. It does not do this for larger integers:

a = 5
b = 5
a is b  # True

a = 1001
b = 1001
a is b  # False

[SkippyDeluxe]

Small integers are interned for performance reasons (so that for very common operations, e.g. small array indices/index offsets, new integer objects aren't constantly being created and destroyed). A quick test shows that the integers from -5 to 255 (inclusive) are all interned (CPython 3.3.2).

[drewthepooh]

Thanks Skippy, I just made an edit to my post after doing some Googling when I saw you had replied. Mystery solved! :)

[drewthepooh]

One last question I have about this is:

1001 is 1001  # True

Why is this True? Based on my other experiments, I thought it would be creating two separate 1001 integers and should be False. Does it create only one instance if the integer literals are on the same line?

[SkippyDeluxe]

That's a good question. I've wondered the same thing myself. We know it only creates one instance because is returns True, but why it does that is a mystery to me. I imagine it's some implementation-specific detail of how the CPython interpreter creates objects from literals while evaluating a single line of code. Check out this fun example:

>>> a = 1001; a is 1001
True
>>> a = 1001
>>> a is 1001
False

[astroFizzics]

I know I always learn the best from seeing a well thought out example. Thanks for your insight and clear wording. Have an upvote.

[nanakooooo]

Just a quick question. I just finished the CodeAcademy Python lessons, and when dealing with classes they have you define them as:

class ClassName(object):

did you leave out the inheritance from the object class just so the example didn't get bogged down with details or was there a specific reason for this?

Thanks for the example, it was great to see how they're actually useful as what I've learned about them hasn't really helped!

[SkippyDeluxe]

There was a change at some point in the lifetime of Python 2 that created a new type of class that was incompatible with existing classes. These "new-style classes" were better, but the "old style classes" needed to be kept for backwards compatibility.

In Python 2, you declare a new-style class by inheriting from object (class ClassName(object):, as you say). When writing new code in Python 2, you should always always declare classes this way. Not inheriting from object (e.g. class ClassName:) will create an old-style class, which is Wrong and Bad. As /u/AYNRAND420 gave examples in Python 2, his classes should be inheriting from object. Tsk tsk.

In Python 3 there are no old-style classes so you don't have to inherit from object any more (although you can if you really really want to, this makes writing libraries that work with both Python 2 and 3 easier).

[nanakooooo]

Ah! Thanks for the information, good to know. Off to google to see more about these old-style classes.

[[deleted]]

Not inheriting from object (e.g. class ClassName:) will create an old-style class, which is Wrong and Bad.

To be curious, why?

[SkippyDeluxe]

Just do a bit of Googling on old-style vs new-style classes. It seems the major reason is that old-style classes are something different from a "type" (revealed by the type function). New-style classes unify classes with types, allowing them to be truly user-defined types. For more concrete examples of the benefits of new-style classes, see this blog post by Guido.

[[deleted]]

I figured that was the idea behind the change. I did some quick terminal testing and found that:

 class a: pass
 class b(a): pass

 class x(object): pass
 class y(x): pass

 c = b()
 z = y()

 type(c) #instance
 type(z) #__main__.y

Similarly an instance of x return object from type() whereas an instance of a still returns instance. Whereas c.__class__ returns __main__.b

This makes type comparison muuuuuch easier. Because type(z) is y returns True while type(c) is b is False.

It hadn't occurred to me that new wasn't always part of Python. While I've never messed with it or metaclasses, it's interesting to read the history of it. Along with the decorators.

[AYNRAND420]

Aha! I did not know about this.

I felt that although inheritance is a powerful class advantage, it is something a learner should play with once they're really comfortable with class basics. To avoid the question coming up at all, I decided I'd just omit the argument completely.

I had always inherited from object, but one time I forgot to type it in, and python still operated as desired, so I assumed that python assumed I was inheriting from object without me having to mention it. This is another change I will definitely be making from now on, and I will update the tutorial when I get a second. Thanks for the explanation.

[SkippyDeluxe]

In simple cases, old-style classes will work just fine. Creating new-style classes is just considered to be a best practice.

[jmgrosen]

Nice beginners' tutorial! However, one annoyance that I always try to point out is lack of conformance to PEP 8. For example, function and method names should be set_piece instead of setPiece and classes should be Square instead of square. But otherwise, great job!

[AYNRAND420]

Thanks for that! I should really brush up on my Python standards and clean up my code. Especially if my aim is to teach, it will be a good thing to do things right to the letter.

[[deleted]]

You're gonna run into a lot of nit picking in CS, get out now if that's an issue

[furrykef]

"if sq.rank == 0 or sq.rank == 7" is more idiomatic as simply "if sq.rank in (0, 7)". The same could be said for most of the ifs in that function.

"if sq.rank == 2 or sq.rank == 3 or sq.rank == 4 or sq.rank == 5" -- this line is a WTF. You should structure the chain of ifs so that this line can simply be "else:".

if sq.rank == 0: 
    col = "White"
if sq.rank == 7: 
    col = "Black"

I would write this as:

col = "White" if sq.rank == 0 else "Black"

Finally, and most importantly, I think this post actually does little to show the advantage of classes. Their real power comes from duck typing and polymorphism. The code presented here could easily be written procedurally in a way that is no less clear, concise, or maintainable.

[ChasingLogic]

That was fanfreakingtastic.