I’ve reached exercise 43 in Learn Python the Hard Way. 📈 This chapter is “Basic Object-Oriented Analysis and Design” and introduces process. How do I break down the problem of how to build something? The exercise demonstrates suggested steps in a top down process. The interesting part for me right now; this is radically different from the stabs I’ve taken at making a game by playing around with the very random bits of Python I happen to have learnt. Haha! 🙊

Bottom up (start with code)

One approach is to start hacking away at something, refining the program as I go. The book suggests this process is better for programmers who are already thinking in code, and that makes a lot of sense for me when I’m reading it described like this. When I was self-employed, this was basically how I used to design websites — ensuring both me and my client focused on content and building an MVP. Starting with code is often how I build UIs at work now; HTML/CSS first. But… as a total newbie Python coder, I’m now eager to try the recommendation of top down.

Top down (start with abstract ideas)

Start from the most abstract ideas, and refine down to something that can be coded. Write, draw, research and so on. This part is what I’m used to doing for most projects. The a-ha moment for me in this chapter, was how to pull out key concepts and exactly what to do with them.

make a list of all the nouns and verbs in your writing and drawings (…) This gives me a good list of names for classes, objects, and functions in the next step.

Once I have my list of concepts I create a simple outline/tree of the concepts and how they are related as classes. You can usually take your list of nouns and start asking “Is this one like other concept nouns? That means they have a common parent class, so what is it called?” Keep doing this until you have a class hierarchy that’s just a simple tree list or a diagram. Then take the verbs you have and see if those are function names (…)

  • nouns —> classes
  • verbs —> functions

This is of course not a straight path directly to an end result, but it’s feels like a great move in that general direction. Then: create a class hierarchy and object map. The hierarchy part makes sense, but I’m confused by the word map, because there is a map object. Are we talking about “mapping out the objects”? Or something specific to this code? 🤔 (Moving on for now, next up is… 👇)

Start coding a skeleton

class Mountain(object): # explicit, but not needed in python3
    def climb(self):
    pass  # useful placeholder when making a skeleton
          # this pass statement is a null operation
          # function climb does nothing (yet) but the script can continue

That pass thingy is apparently a simple statement.
And the ones I’ve met before are return, break and import.


More notes from the code in this exercise

from sys import exit              # from module import function
from random import randint
from textwrap import dedent

sys

This module provides access to some variables used or maintained by the interpreter and to functions that interact strongly with the interpreter. It is always available.

exit() is a system-specific function. 👉 exit (The argument is optional, not sure what they mean?! 0 is default. The code in the exercise uses 1.)

random.randint(a, b) for generating pseudo-random numbers 👉 randint

textwrap.dedent(text) to remove leading whitespace 👉 dedent


All right. *exhale* Two days later, I have typed in the different parts of code from exercise 43, and I have the “Gothons from Planet Percal #25” game working. 🎉 The interwebs reveal that plenty of folks have struggled with this exercise — and yeah… this one was quite a stretch. I didn’t complete it exactly as described — I was completely stuck at attempts to code up the classes myself, and I didn’t understand if the script was supposed to run successfully section by section. Mine didn’t until I had everything in place. …but I’m super happy with what I’ve learnt, and ready to move forward.