Good Interactions

Some design principles have fancy names (you’ll find them under Further Reading (Section 4.3), and they are often described one by one as if you can first apply one, then the next, and so on. In reality you work with all of them at once, and they are essentially different aspects of a few fundamental principles:

To put this into the context of a single class, this means that a good class has:

• A single, well-defined abstraction and well-defined responsibilities
  • Tip: Let classes distribute work to other classes
  • Tip: avoid “God Classes” that tries to do everything
• Has low coupling to other classes
  • Tip: Minimise fan-out in a class
• Has a sufficient and complete public interface to be able to access the behaviour and state relevant for the abstraction that the class models
• Has a primitive public interface that does not expose anything more than necessary to the outside.
  • Tip: All data should be hidden within the class.
  • Tip: Do not clutter the public interface with items that users of that class are not interested in or able to use.
• Has high cohesion (the methods and attributes belong strongly together)
  • Tip: Most of the methods defined on a class should be using most of the data in the class most of the time.

These are just some of the principles for how to define classes. Under Further Reading (Section 4.3) I have listed some more. Luckily, many of these have also been expressed in a slightly more accessible way in the course book. Larman calls them GRASP patterns, and the idea is that when you are doing your design you always try to define the responsibilities of the involved objects and classes according to these GRASP patterns. This is why he also refers to them as Responsibility Driven Design. The patterns are listed on the inside of the book cover:

• Information Expert
• Creator
• Controller
• Low Coupling
• High Cohesion
• Polymorphism
• Pure Fabrication
• Indirection
• Protected Variations

Make sure you understand the principles of each one of these. Think about how you may apply them in different settings. Discuss them with your classmates, and use the course discussion forum. How might they impact your design?

• C. Larman, Applying UML and Patterns, 3rd Edition, Chapters:
  17. GRASP: Designing Objects with Responsibilities
  18. Object Design Examples with GRASP
  19. Designing for Visibility
  25. GRASP More Objects with Responsibilities

• GRASP Patterns

• Law of Demeter: Keep entities as ignorant as possible of other entities, don’t let them talk to strangers.
• Liskow Substitution Principle: Defines how sub- and supertypes can be used in each others place.
• Open/Closed Principle: Software Entities should be open for extensions but closed for modifications.
• Dependency Inversion Principle: high-level (abstract) entities should not depend on more low-level (detailed) entities. Instead, the low-level entities should depend on the abstractions.
• Interface Segregation Principle: Prefer many smaller interfaces with well-defined roles instead of one big interface.
• Single Responsibility Principle: Let each class take care of one single responsibility. Split classes that do more than one thing.
• Common Closure Principle: Coupling and cohesion for packages (as opposed to individual classes)
• Program to an Interface, not an Implementation: Define role-based interfaces and use these instead of “direct links” to the instantiated class. NOTE: Also read the “Wizards and Warriors” rant for a counter-argument.
• Wizards and Warriors Part I Part II Part III Part IV Part V: Introduces the need for an Entity Component System (ECS), which is a common game design pattern since the normal inheritance practices break down.
• Favour Object Composition over Class Inheritance: The same pattern, with a different name.

Go through the user stories for this sprint and make sure you have a clear understanding of how to solve each of them.

Revisit and update your risks and contingencies section.

Add and/or revise the following items to your glossary:

• Abstraction
• Coupling and Cohesion
• Encapsulation
• Code Refactoring
• Design Principles
• Design Patterns
• Responsibility Driven Design
• GRASP Patterns
  • Information Expert
  • Creator
  • Controller
  • Low Coupling
  • High Cohesion
  • Polymorphism
  • Pure Fabrication
  • Indirection
  • Protected Variations

Make sure you understand what each item is, the notation for them, and how to use them either in isolation or together with the other concepts.

Use a small system that you know well, for exampe a Pacman game. Think about the GRASP patterns in the context of this game. For example:

• Who is the information expert on knowing the location of pacman on the game board?
• Who creates the ghosts?
• Who takes care of input and orchestrates navigation in the main menu (controller)?
• How should the ghosts be made aware of pacman’s position so that you maintain low coupling and information expert?
• How do you design the game board so that it still has high cohesion?
• How does polymorphism work with the different ghosts?
• etc.

Are there similar principles that can help you decide how a larger collection of classes can interact? How do you find the classes in the first place? How do you explore the interactions between objects?

Are there any other questions that you want answered? Add them, along with a brief strategy for how to find an answer.