(OOP) is something that you have to learn by doing. You can read all you want about how a Car can be a subclass of a Vehicle, and buzzwords like “ ”, but until you rewire your brain to think in a different way you won’t fully understand it. Object Oriented Programming polymorphism In this post, I’ll walk you through a real problem, strip out the jargon, and show you how you can understand OOP by changing the way you think about your program. Content Overview Prerequisites Problem Scenario What NOT to do What you SHOULD do Conclusion Prerequisites This isn’t for complete newcomers to OOP, although you may still find it useful. . Perhaps you’ve never really got OOP, and you struggle to design object-oriented programs yourself You should have a working knowledge of OOP - for example, what a constructor is, and the meaning of and . basic public private Problem Scenario We’ll work through a coding test I once had to do for a job application. You are given a text file that represents a maze: XXXXXXXXXXXXXXX
X             X
X XXXXXXXXXXX X
X XS        X X
X XXXXXXXXX X X
X XXXXXXXXX X X
X XXXX      X X
X XXXX XXXX X X
X XXXX XXXX X X
X X    XXXXXX X
X X XXXXXXXXX X
X X XXXXXXXXX X
X X         X X
X XXXXXXXXX   X
XEXXXXXXXXXXXXX `X` represents a wall, `S` is the ‘start’, and `E` is the ‘end’. Spaces are where your ‘explorer’ can travel through the maze. The task is to write a program that fulfills the following criteria: Given a maze, the explorer should be able to drop into the Start location (facing north) An explorer in a maze must be able to move forward, turn left, and turn right An explorer must be able to declare what is in front of them An explorer must be able to declare all ‘movement options’ given their location An explorer must be able to declare how many steps they have taken so far An explorer must be able to report a record of where they have been in an understandable fashion What NOT to do In my early career I would have made the following mistakes when thinking about this problem: I would have thought of my program as a sequence of instructions for the computer to carry out I would have thought about how I would model the data in the computer’s memory I would have imagined a user running the program and interacting with it These are a bit abstract, so let me explain them. I would have thought of my program as a sequence of instructions for the computer to carry out I first learned to program in C, and so my mental model of programming was writing a sequence of step-by-step instructions for the computer to execute. You may have started learning with Python or JavaScript, in which case your mental model will be the same. Unless the very first language you ever used was or C#, you would have thought of your programs as a sequence of instructions. Data comes into the program, each line in the program performs operations on that data, and an output is produced. This is called . Java imperative programming I would probably have thought . And I would have written code - in a main function - that read the file. “What is the very first thing that the program needs to do?…..it needs to read the text file” I’ll use Java as an example, but all this applies to any language, and there’s nothing specific to Java here. public class Main {
    public static void main(String[] args) {
        String maze = new String(Files.readAllBytes(Paths.get("maze.txt")));
} I would have thought about how I would model the data in the computer’s memory Then I would have considered the data, and how it would be stored. I’d perhaps store the data in a 2D array, which makes sense given the maze is a 2D grid of characters. public class Main {
    public static void main(String[] args) {
        List<String> lines = Files.readAllLines(Paths.get(filePath));
        char[][] maze = new char[lines.size()][];
        for (int i = 0; i < lines.size(); i++) {
            maze[i] = lines.get(i).toCharArray();
        }
} I would have imagined a user running the program and interacting with it I would have looked at the specification and considered how the user would interact with the program. So the first one: ). I probably would have done something like this: Given a maze, the explorer should be able to drop into the Start location (facing north public class Main {
    public static void main(String[] args) {
        List<String> lines = Files.readAllLines(Paths.get(filePath));
        char[][] maze = new char[lines.size()][];
        for (int i = 0; i < lines.size(); i++) {
            maze[i] = lines.get(i).toCharArray();
        }

        int[] startCoordinates = getStartCoordinates(maze);
        int[] explorerCoordinates = startCoordinates;
        char explorerDirection = 'N';
    }

    private int[] getStartCoordinates(char[][] maze) {
        // search grid and return coordinates of 'S' [x, y]
} Then maybe I would have given the user a way to interact with the program: public class Main {
    public static void main(String[] args) {

        ...

        int[] startCoordinates = getStartCoordinates(maze);
        int[] explorerCoordinates = startCoordinates;
        char explorerDirection = 'N';

        String userInput = getUserInput();
        
        if (userInput.equals("turn left") {
            explorerDirection = 'W';
            ...
    }

    ...
} ..and so on. At some point, I’d have to have some kind of input loop and kept the state maintained according to the user input, but you get the idea. The point is: I would have primarily had in my mind the idea that this is an actual program that could be used by a real user. I would have modeled the data at a low level. I would have tackled the problem step by step, from when the program is first run.# Perhaps you’re now thinking: but programs made for real users, you think of how data is represented in memory and a program a sequence of instructions! are should is If you’re thinking this then and you you are of course correct there is hope for you yet. You would be amazed at how many people don’t think of programs this way. As a reminder: : Thinking of programs like this will prevent you from properly understanding OOP. You need to rewire your brain and think about your programs a little differently, if only temporarily. But our job for today is to understand OOP and not get fired. What you SHOULD do The first thing is to move away from the computer and get a pen and some paper. What are the ‘things’ in this problem? Write them down. Maze Explorer Great. These are our ‘objects’. class Maze {

}

class Explorer {

} Now let’s consider the two things that objects have: and . state methods State What ‘state’ can a maze be in? It’s the state defined by the text file. It could be this: XXXXXXXXXXXXXXX
X             X
X XXXXXXXXXXX X
X XS        X X
X XXXXXXXXX X X
X XXXXXXXXX X X
X XXXX      X X
X XXXX XXXX X X
X XXXX XXXX X X
X X    XXXXXX X
X X XXXXXXXXX X
X X XXXXXXXXX X
X X         X X
X XXXXXXXXX   X
XEXXXXXXXXXXEXX Or it could be this: XXXXXXXXXXXXXXX
X             X
X XXX     SXX X
X X         X X
X XX   XXXX X X
X XX   XXXX X X
X XXXX      X X
X XXXX XXXX X X
X XXXX XXXX X X
X X    XXXXXX X
X X XXXXXXXXX X
X X XXXXXXXXX X
X X         X X
X XXXXXXXXX   X
XXXXXXXXXXXXXXX So how can we represent that in our `Maze` object? How about a 2D array of characters: class Maze {
    char[][] grid;
} That’s fine: the grid literally is a 2D array of characters. But we can go further and pick out some more objects from our problem. What about the allowed characters in the maze and their meaning? We can define a `MazeElement`, like this: enum MazeElement {
    WALL('X'),
    SPACE(' '),
    START('S'),
    EXIT('E');
} And now our `Maze` is this: class Maze {
    MazeElement[][] grid;
} This has some benefits. For example, instead of writing something like this: if (grid[i][j] == 'X') ..we can instead write this: if (grid[i][j] == MazeElement.WALL) Now we’re working explicitly in the . Instead of the reader perhaps not knowing what `X` was, or having to check for themselves which characters are allowed, now we’re explicitly telling them. problem domain That’s all we need to represent the state of the maze at any time.  Now what about the Explorer? What ‘state’ can the Explorer have? Well, the Explorer has a position in the Maze, which we can represent with grid coordinates. What’s the best ‘type’ to represent that? The primitive example would be to use an array of two integers, but we can do better than that. Most languages will have their own classes to represent coordinates, as it’s such a common problem. In Java, we can use the Point class, from `java.awt`. class Explorer {
    Point currentLocation;
} The Maze itself is also part of the Explorer’s state. Perhaps there are multiple mazes and the Explorer could be in any one of them. class Explorer {
    Maze currentMaze;
    Point currentLocation;
} We know from the problem spec that the Explorer can face in different directions: class Explorer {
    Maze currentMaze;
    Point currentLocation;
    String directionFacing;
} where the direction can be north, south, east or west. But like the MazeElements we can go one better, and define another object: enum Direction {
    NORTH,
    SOUTH,
    EAST,
    WEST;
} then the Explorer becomes: class Explorer {
    Maze currentMaze;
    Point currentLocation;
    Direction directionFacing;
} Again looking at the problem spec the Explorer has a ‘history’: the path they have taken and the number of steps. So we can add: class Explorer {
    Maze currentMaze;
    Point currentLocation;
    Direction directionFacing;
    int stepCount;
    List<Direction> path;
} Actions We’ve defined all our objects, and their state: Maze
    grid
    
Explorer
    currentMaze
    currentLocation
    directionFacing
    stepCount
    path

MazeElement
    WALL, SPACE, START, EXIT

Direction
    NORTH, SOUTH, EAST, WEST As well as state, objects do things. Or more accurately, . things they allow you to do to them So let’s go through the problem spec to see what we need them to let us do. Given a maze the explorer should be able to drop in to the Start location (facing north) class Explorer {
    ...

    void enterMaze(Maze maze) {
        // TODO
    }
} We’re not going to implement the method yet as we’re still designing our objects. Remember to sketch out your objects up front, before you start writing any real code. An explorer in a maze must be able to move forward, turn left or turn right Now we’re seeing how easy this is: class Explorer {
    ...

    void enterMaze(Maze maze) {
        // TODO
    }

    void moveForward() {
        // TODO
    }

    void turnLeft() {
        // TODO
    }
   
    void turnRight() {
        // TODO
    }

} Note that each of these will change the state of the Explorer. will set , and . will increment , add to the and change the . methods enterMaze currentMaze directionFacing currentLocation moveForward stepCount path currentLocation An explorer must be able to declare what is in front of them class Explorer {
    
    ...

    MazeElement declareWhatIsInFront() {
        // TODO
    }    

} An explorer must be able to declare all movement options from their given location We might have questions about what exactly this means, but it doesn’t matter for now. class Explorer {
    
    ...

    Set<Direction> declareMovementOptions() {
        // TODO
    }    

} An explorer must be able to declare the number of times they have moved forward so far class Explorer {
    
    ...

    int declareNumberOfSteps() {
        // TODO
    }    

} An explorer must be able to report a record of where they have been in an understandable fashion class Explorer {
    
    ...

    List<Direction> declarePath() {
        // TODO
    }    

} Notice our method names have “declare” in them a lot. This matches the language of the spec, but actually it’s a little unclear what “declare” means. Does it mean “return” or could it mean “print”? To make things clearer we can change “declare” to “get”, so our object now looks like this: class Explorer {
    Maze currentMaze;
    Point currentLocation;
    Direction directionFacing;
    int stepCount;
    List<Direction> path;

    void enterMaze(Maze maze) {}
    void moveForward() {}
    void turnLeft() {}
    void turnRight() {}
    MazeElement getMazeElementInFront() {}
    Set<Direction> getMovementOptions() {}
    int getNumberOfSteps() {}
    List<Direction> getPath() {}
} Public vs Private Looking at the Explorer object above, we only need to “expose” the to the user (the user of the class) to fulfil the spec. We don’t need the user to be able to access the state - they do that through the methods. methods class Explorer {
    private Maze currentMaze;
    private Point currentLocation;
    private Direction directionFacing;
    private int stepCount;
    private List<Direction> path;

    public void enterMaze(Maze maze) {}
    public void moveForward() {}
    public void turnLeft() {}
    public void turnRight() {}
    public MazeElement getMazeElementInFront() {}
    public Set<Direction> getMovementOptions() {}
    public int getNumberOfSteps() {}
    public List<Direction> getPath() {}
} In general, state is always private, and methods are usually public. The public methods define the : how a user of the object interacts with it. interface Let’s say though that when writing the public methods we find we’ve got repeated code in a few of them, and we want to extract that into a different method. Let’s say the new method is this: Point getPointInDirectionOf(Direction d) {} which returns the in a given direction. This could be used by the method, and . Point moveForward declareWhatsInFront declareMovementOptions This method should be private. It’s only used internally, by the object itself. The ‘user’ of the class doesn’t need to access that method. They don’t even need to know that it exists, because it doesn’t affect the behaviour of the class at all. This is called encapsulation. The ‘inner workings’ of the object are not exposed to the ‘user’ of the object. class Explorer {
    private Maze currentMaze;
    private Point currentLocation;
    private Direction directionFacing;
    private int stepCount;
    private List<Direction> path;

    public void enterMaze(Maze maze) {}
    public void moveForward() {}
    public void turnLeft() {}
    public void turnRight() {}
    public MazeElement getMazeElementInFront() {}
    public Set<Direction> getMovementOptions() {}
    public int getNumberOfSteps() {}
    public List<Direction> getPath() {}

    private Point getPointInDirectionOf(Direction d) {}
} This private method isn’t something you’ll be able to plan up front - you’ll only encounter it when you get to actually implementing the methods. I include it here simply to explain public and private methods. As you begin to write the actual code you’ll also discover things you need the Maze to do, which aren’t necessarily in the problem spec. For example, the Explorer is going to have to ‘ask’ the Maze “ ”. In that case the method on the Maze should be , because that functionality being made available to other objects, in this case to the Explorer. which elements are at coordinate x, y? public is Constructors All classes need a constructor. The function of the constructor is to initialise the object’s state. In the case of the Maze, we need to set the , which we read from a text file. grid public Maze (String fileName) {
    // TODO: iterate though characters in the file and assign them to the grid
} For the Explorer, what state do we need to set? private Maze currentMaze;
private Point currentLocation;
private Direction directionFacing;
private int stepCount;
private List<Direction> path; We already have a separate method which will assign (although you may choose to do that in the constructor instead if you wanted), so the can be initialised to . enterMaze currentMaze currentMaze null The other can be initialised to in the case of the and , for , and an empty list for . fields null Point Direction 0 stepCount path public Explorer() {
    currentMaze = null;
    currentLocation = null;
    directionFacing = null;
    stepCount = 0;
    path = new ArrayList<>();
} Conclusion Our objects look like this: class Maze {
    private MazeElement[][] grid;

    public Maze (String fileName) {}

    public MazeElement getElementAtCoordinate(int x, int y) {}
}

class Explorer {
    private Maze currentMaze;
    private Point currentLocation;
    private Direction directionFacing;
    private int stepCount;
    private List<Direction> path;

    public Explorer() {}

    public void enterMaze(Maze maze) {}
    public void moveForward() {}
    public void turnLeft() {}
    public void turnRight() {}
    public MazeElement getMazeElementInFront() {}
    public Set<Direction> getMovementOptions() {}
    public int getNumberOfSteps() {}
    public List<Direction> getPath() {}
}

enum MazeElement {
    WALL('X'),
    SPACE(' '),
    START('S'),
    EXIT('E');
}

enum Direction {
    NORTH,
    SOUTH,
    EAST,
    WEST;
} Note that we haven’t written any actual code yet - this is all just designing our objects up front. Notice how different that is from our first tactic of seeing the program as a sequence of instructions executed one by one. In fact, there’s almost nothing here that’s language specific. You can apply the principles here to almost any object-oriented language. By thinking about your objects up front you’ve simplified the task massively. Now you can tackle each part of the problem spec in isolation. This relieves you of the burden of having to keep the whole problem in your head at once, which you’d have to do if you were writing imperative code that goes from top to bottom. Note as well that we haven’t considered how a user would run and interact with this problem. When writing OOP you need to think more abstractly, and tackle small pieces of the problem in isolation. If we did want to add a UI on later that would be easy to do in a new object, that interacted with our Maze and Explorer via their interfaces. The problem spec doesn’t ask for that. Also published here. Next In my next post, I’ll use this same Maze example to show you how to use Test Driven Development (TDD) to make your life even easier when implementing the methods.  To make sure you don’t miss it, . follow me on Twitter

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

To Understand Object Oriented Programming, Think About Programs a Little Differently

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Seven Steps for Surviving Your First Programming Job

104 Stories To Learn About Go

105 Stories To Learn About Functional Programming

100+ Free Pluralsight Courses to learn Python, Java, and Spring Boot

10 Websites to Learn JavaScript for Beginners

104 Stories To Learn About Programming Top Story

Seven Steps for Surviving Your First Programming Job

104 Stories To Learn About Go

105 Stories To Learn About Functional Programming

100+ Free Pluralsight Courses to learn Python, Java, and Spring Boot

10 Websites to Learn JavaScript for Beginners

104 Stories To Learn About Programming Top Story

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps