The Mixin Class

• Also known as the mix-in class.
  • See page 985+
• This is a problem solving technique.
• It is sometimes called a design pattern
  • A design pattern is a best practices solution to a known problem.
• For the Mixin class
  • A mixin class allows derived classes to inherit a specializations
  • Frequently this is described as "a small piece of extra behavior" (Gregorie)
• The mixin class mixes in this new behavior
• This avoids the double diamond problem as we are not adding a generalized base class.
• It avoids rewriting code from a single inheritance point of view.
• An example:
  • In my character class, we did not consider the "race" of the character.
  • To keep it simple, I am going to assume that race would add the following characteristics
    • A race name.
    • An Advantage/disadvantage to healing.
    • An Advantage/disadvantage to being wounded.
    • An Advantage/disadvantage to causing damage.
    • RaceT.h
    • RaceT.cpp
  • I then constructed a derived ElfT
    • ElfT.h
    • ElfT.cpp
  • C++ does not natively support the mixin class
    • You accomplish this with multiple inheritance.
    • So I built a FighterElf class.
      • FighterElfT.h
      • FighterElfT.cpp
  • This is not bad
    • There is a clear boundary between the character and the race.
    • They are mixed in when needed.
  • But
    • I think that the race should be in a composition with Character to align with how most RPGs work.
      • If everything possesses race, it should be a composition.
      • If only some characters posses race, it should be a mixin.
    • The RaceT and ElfT have no member data. This would be different if they were actually doing something, not just printing.
      • Fight in the FighterElfT is definitely Broken. Again this would be different if it were actually doing something.
    • A hierarchy for mixin might not be the best idea either.
      • But someone might want a dwarf-elf-battlemage
  • 
• Gregorie says that mixin classes are really useful when you have a hierarchy designed across one axis
  • But you have a set of similarities across another axis.
• In Booch they say
  • You build little classes, which you combine (or mixin) to produce sophisticated classes.
  • He has a quote "A mixin is syntactically identical to a regular class, but its intent is different. The purpose of the mixin class is solely to ... [add] functions to other flavors[classes] -- one never creates an instance of a mixin"
• Meyers says mixin-classes are "base class ie a base class that's designed to allow derived classes to inherit a single specific capability"
• I found other examples that used templates.
  • this is from here
  • You build the mixins as classes.
  • Then you use templates to combine the mixins.
  • I think this is cool
  • mixTemplate.cpp
• This can become much more complex.
  • See this article

The Handle Class

• This is from Stroustrup, C++ programming Language, 3rd.
  • This code is mostly taken from Stroustrup
• This is probably an outdated topic.
  • This class can be replaced with smart pointers.
  • I will try to get a lecture on smart pointers ready for next time.
• When dealing with pointers, it is often problematic to know when to delete the data the pointer is pointing at.
• The handle class helps with this.
• The idea is to
  • Hold the pointer to an object in a "handle"
  • This handle is responsible for determining how many references to the class are currently in use.
  • This is done through a reference count.
  • When another reference is added, the reference count goes up.
  • When a reference is removed, the reference count goes down.
  • When the last reference is removed, the object is deleted.
• Data in the handle class.
  • The handle class holds a pointer to an object.
  • As well as a count.

  •        private:
               T * rep;
               int * count;
            

  • The pointer to the count means that it is shared across handles to the same object.
  • A static variable would not do because we might have different objects we are pointing to.
• Methods.
  • Look at handle.cpp
  • Note that the -> operator is overloaded.
  • Note that I used a typedef to avoid Handle<BoardT>