Learn more with dummies

Enter your email to join our mailing list for FREE content right to your inbox. Easy!

How to Create Classes and Responsibilities for iOS Apps

By Rajiv Ramnath

To create classes and responsibilities in iOS, start by extracting nouns from the description of the app and its use cases. These become potential objects, classes, and attributes of your app. Next, you extract verbs from the description and use cases. These become candidate responsibilities (potential methods of classes).

The following list shows how to identify, define, and extract nouns, then verbs, for an example app: Tic-Tac-Toe.

  • Nouns: Nouns that you may find in the descriptions and use cases of the Tic-Tac-Toe app are pencil, paper, game, nought, cross, player, X, O, space, symbol, grid, mark, vertical row, horizontal row, diagonal row, human user, human, computer, session, board, touchscreen and score.

    Next, write down a one-to-two line definition of each noun in the context of the app that you’re trying to build. Then compare these definitions. If you find that two nouns are defined in the same way, remove one of them. You might also decide to merge two definitions (and therefore the corresponding nouns) into one.

    When you complete this process of definition, removal, and merging, you’re left with a set of nouns that will serve as your candidate classes. Following is an example of this process from Tic-Tac-Toe (using a subset of the nouns and verbs, to avoid taxing your patience):

    • Remove the nouns pencil and paper as physical things not relevant to an iOS-based game.

    • Observe that symbol and mark mean the same in the context of Tic-Tac-Toe, so delete mark and retain symbol.

    • Observe that nought and O mean the same thing in the context of a Tic-Tac-Toe game and that cross and X mean the same as well. So, remove the ill-favored British terms nought and cross, and leave O and X. Also, be aware that O and X appear to be either instances or subclasses of symbol.

    • Compare user and player. Retain player as the player in the game. Depending on the context, human user and human can be the same. These nouns along with computer are instances or subclasses of player.

    • Board and grid are similar enough in meaning that one of them can be removed.

    • What about touchscreen? It refers to a physical component of the phone, so you might be inclined to remove it. On the other hand, something needs to handle the visual display of the board. It could be the board itself. Or you could separate the data structure that represents the board from its visual manifestation.

    • Consider row as a component of game grid and vertical row, diagonal row, and horizontal row as being different subclasses or instances of row (but you don’t know which yet).

    • Retain game, for obvious reasons.

    • Consider session as the manager of games, with score being an attribute of the session for the two players.

  • Verbs: Candidates for verbs in the Tic-Tac-Toe app are take turn, mark, goes, place, win, implement, play, playing first, display, accumulate, quit, reset.

    • Remove take turn and goes as being close enough to play, which you retain. For now, retain playing first and the missing playing second as potential refinements of play. The final design will ultimately show you that these last two verbs aren’t needed.

    • When used as a verb in the context of Tic-Tac-Toe, mark can be seen as similar to play. That is, when you play by making your move, you’re marking a location on the grid. So, remove mark and retain place, but rename it place symbol.

    • Remove implement because it isn’t a responsibility relevant to the game; instead, it’s relevant to the process of building the game.

    • Retain display, accumulate, exit, and reset as valid responsibilities.

You now have the following potential classes, instances, and responsibilities:

  • Classes: Symbol, Player, Human, Computer, Board, Row, Game Session, and Game (with the attribute Score).

  • Instances: O, X of the class Symbol.

  • Responsibilities (which will become methods): play, place, display, accumulate (scores), quit, and reset.

Now it’s time to tentatively assign responsibilities to classes as logically as possible:

  • Allocate the Game Session class the responsibilities, play new game, accumulate Scores, quit, and reset.

  • Allocate the Game class the responsibilities, play.

  • Class Board has Display responsibilities.

  • Class Game Grid has Place.

  • Symbol, Player, Human, Computer, and Row have no responsibilities. But don’t delete them just yet.