Programming in Nouns and Verbs

Programming in nouns and verbs

Many developers become swamped when they start creating a new piece of software. There are so many things to learn and think about:

  • Infrastructure
  • Platform software
  • Software architecture
  • Design patterns
  • The programming language
  • Frameworks

This post isn’t about any of that. It’s about something very basic. It’s about how to design your classes. I’m shocked at how explaining this to a new developer immediately results in much better code from them. Class (and software) construction is all about programming in nouns and verbs. In short, nouns are properties and verbs are methods.

Object oriented programming

An object oriented programming has three main features:

  • Encapsulation
  • Inheritance
  • Polymorphism

Programming in nouns and verbs is all about the encapsulation. It’s grouping properties (nouns) and methods (verbs) into a single cohesive unit. The tricky part, it seems, is to decide what are the properties and methods to group together. Reducing this to nouns and verbs makes this much simpler.

Identifying nouns and verbs

When you talk to the project owner or think about what you’re building you need to listen for nouns and verbs. Nouns are things you can touch, see, smell, taste, or feel. A verb is an action.

  • A dog (noun) runs (verb) on four feet (noun).
  • The player (noun) aims (verb) at the ghoul (noun).
  • Users (noun) need to login (verb) with their username (noun) and password (noun)

It seems easy enough, right? Sometimes it’s a bit trickier. Good modeling requires hard thinking about what nouns and verbs belong together. And sometimes there are implicit nouns and verbs.

Finding hidden nouns and verbs

Let’s take the “The player aims at the ghoul” for analysis. What if the sentence was this:

  • The player shoots at the ghoul.

Does the player actually “shoot”? A weapon shoots. A player aims and pulls the trigger. So the sentences are really this:

  1. A player aims a weapon at the ghoul.
  2. A player pulls the trigger.
  3. The weapon fires at the ghoul.

In this case, you discover players, weapons, and ghouls. Each of which can be abstracted out with different characteristics. A player can have a variety of different weapons with different aiming capabilities focusing on different targets.

So here we have objects which look like this:

class Player {
 Weapon CurrentWeapon {get;set;}
 void PullTrigger() {}
 void Aim() {}
}

class Weapon {
 void FireAtTarget()
 Ghoul Target {get; set;}
}

class Ghoul {}

This is very reduced for simplicity. The goal is not to actually create a first person shooter model but to show the process of taking business requirements and turning them into code.

Take a few minutes and think about what the models would look like if you didn’t find the hidden “Weapon” class.

Hearing the nouns and verbs

Developers can do a fairly good job of creating software from business requirements if they listen for the nouns and verbs. As you listen to your product owners write down as many nouns as you can. These are the properties you’ll need to create. The verbs define methods which need to be written. The classes you create are the logical grouping of the two. The hard part is writing the interaction between all the classes. This is where Design Patterns come in. A good software architect will design a system using well-known patterns to enable the objects to interact with each other without being tightly coupled.

Wm. Barrett Simms
Follow Me
Latest posts by Wm. Barrett Simms (see all)