3. Classes Model Virtual Reality¶

3.1. Attributes, Abilities, and Responsibilities¶

A real-life dog is an entity that has attributes (gender, breed, height, weight, maybe a name) and abilities (can bark, can bite, can eat, can run, can fetch newspaper, can wag tail). A “responsibility” is an activity that an entity must do; a dog might have the responsibility to bark when there is an intruder. Even real-life entities that we consider inanimate have attributes and abilities: A car is inanimate, has lots of attributes, and has the ability to propel a human to Chicago or New York. (A car is unlikely to have responsibilities, however.) When we computerize dogs and cars, their attributes, abilities, and responsibilities will be coded in class definitions as fields, methods, and commands.

Now consider a card game: In a card game, a “card” is an entity with attribute suit (spades, hearts, diamonds, clubs) and attribute count (2, 3, 4, ..., king, ace). A card has few abilities — maybe it can “tell” you its suit and count, and it has no responsibilities. A “card deck” is an entity that holds cards inside it, can “shuffle itself” and can yield (“deal”) cards, one at a time. A deck has no responsibilities.

But a card game has other entities, who do have resposibilities: the dealer (who owns the card deck, who deals from it, and who enforces the rules of the game) and the players (each one owns a “hand” of cards and plays the game). We code these entities as class definitions.

3.2. Class¶

Here is an example of a playing card that might be coded in C#:

// A _NAMESPACE_ IS THE SAME THING AS A VISUAL STUDIO PROJECT:
namespace CardConcepts {

  // AN _ENUMERATION_ IS A NEW "PRIMITIVE DATA TYPE" THAT YOU DEFINE:
  // enumerations of the Suits and Counts that a playing card can have:
  public enum Suit { Spades, Hearts, Diamonds, Clubs };
  public enum Count { Ace, Two, Three, Four, Five, Six, Seven, Eight, Nine, Ten, Jack, Queen, King };

  // CLASS FOR CONSTRUCTING A PLAYING CARD:
  public class Card {
    public readonly Count count; // THIS IS A _FIELD_; SO IS THE LINE BELOW:
    public readonly Suit suit;   // "readonly" means var's value cannot change

    // THIS IS A _CONSTRUCTOR METHOD_; IT TAKES TWO _PARAMETERS_:
    public Card(Count a, Suit b) { count = a;  suit = b; }

    // THIS IS A _METHOD_; IT RETURNS AN ANSWER:
    // returns the int value of a card in Blackjack (it assumes an Ace has value 1)
    public int BJvalue() {
      int i = (int)count + 1;   // obtain int value that underlies the Count
      if (i > 10) { i = 10; }   // in Blackjack, face cards have value 10
      return i;
    }

    // returns the string value of a card; overrides default  ToString  coding
    public override string ToString() { return count + " of " + suit; }
  }
}

Make certain you understand all the constructions and all the comments in the above example. The fields in class Card list its attributes, count and suit; the methods are the abilities. Although inanimate, a card can tell you its Blackjack value and its name (a string).

The class is saved in a Visual Studio project named CardConcepts. In the main program, we construct objects,

public static void Main() {
  Card c1 = new Card(Count.Ace, Suit.Hearts);
  Console.WriteLine("card {0} has value {1}", c1.ToString(), c1.BJvalue());
  if (c1.suit == Suit.Clubs) {
    Console.WriteLine("it's a club!");
  }
}

and the card entities come to (virtual, electrical) life.

3.3. Unit Testing¶

A program is an assembly of objects constructed from classes. A class by itself is not a program and might not “execute” all alone. This is a serious problem in modern software engineering — if we develop a complex software system in stages, we want to design, build, and test the components (classes) one at a time, so that when we assemble them, we have high confidence that the assembly operates as desired.

How do we test and validate the quality of a class that cannot “execute” all alone?

There are special tools to test a class alone; Visual Studio provides an easy way to write a `test harness <http://istqbexamcertification.com/what-is-test-harness-unit-test-framework-tools-in-software-testing/`__ for unit testing an individual class. (Like its name suggests, “unit testing” is the testing of one unit of a system.)

A unit test of a class is a script of actions that use one or more objects constructed from the class. The script exercises the attributes and methods. There should be enough unit tests that all the attributes and methods are exercised, in all possible, significant orders.

That last phrase is important — most classes are defined with multiple methods, where the methods are to be used in a certain order, a protocol.

For example, here is the protocol for using the methods of a text-file object:

1. open the file in mode M, where M is either read or write
2. do operation M multiple times
3. close the file

When we unit-test class TextFile, we test that it operates properly with the proper protocol, and we test that it does not corrupt its contents if a caller violates the protocol:

 public enum FileMode { read, write, available };

 class TextFile {
   private string filename;
   private FileStream address_on_disk;
   private Mode mode;  // should be  Mode.Read  or  Mode.Write

   public TextFile(string name, Mode mode) {
     // ...code to initialize  mode  and open the file
   }

   public string ReadLine() {
     // ... code to read textline from filename, provided mode == Mode.Read
   }

   public string WriteLine() {
     // ... code to write textline to filename, provided mode == Mode.Write
   }

   public bool CloseFile() { mode = Mode.available; }
}

The unit tests for class TextFile should include scripts that follow the proper protocol, as well as scripts that call methods in the wrong order (e.g., construct, close, read) as well as scripts that call methods improperly (e.g., construct a read-file and then write to it).

The unit tests should be collected together, used, and reused while the class is coded, and maintained. The unit tests form a “validation suite” for establishing confidence in the quality of the class code.

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Classes_VR_CardConcepts;

namespace Classes_VR_UnitTests {

  [TestClass]
  public class UnitTest1 {

    [TestMethod]
    public void TestMethod1() {
      Card c1 = new Card(Count.Ace, Suit.Hearts);
      Assert.AreEqual(Count.Ace, c1.count);
    }

    [TestMethod]
    public void TestMethod2() {
      Card c1 = new Card(Count.Ace, Suit.Hearts);
      Assert.AreEqual(Suit.Hearts, c1.suit);
    }

    [TestMethod]
    public void TestMethod3() {
      Card c1 = new Card(Count.Ace, Suit.Hearts);
      Assert.AreEqual(1, c1.BJvalue());
      Console.WriteLine(c1.ToString());
    }
  }
}