In this tutorial I will go through some useful steps toward creating an OOD(Object Oriented Design) for a program(mobile game app). OOD only applies to an OOP(Object Oriented Program). You can also search the web for UML(unified modeling language) tools.

Create a 'use cases' (UML):

A game where you start by killing enemies. After all the enemies are dead, you then rescue the princess and win the game. If the enemies kill you then you lose the game and you have to restart.

Create a 'noun list':

Create a list of nouns(underlined above) that makeup your program.  Erase duplicates. This is to develop a vague concept of the program.

• actor(player)
• enemies
• princess
• start menu
• win menu
• lose menu
• play button

Create 'Conceptual Object Model' or 'Conceptual Diagram':

Put the nouns into boxes and draw lines and describe the lines to indicate associations between the objects.This is to develop a vague concept of the program.

Assign Responsibilities

Move the actions under the potential classes that will be responsible for them.

Create your list of UML class diagrams

Create your list of class diagrams. Each class diagram will follow this basic structure.

Here is an actual class diagram of class player. I went ahead and added a 'die' property and associated method to the player class. Static properties or methods are represented as underlined in class diagrams.

Interfaces in class diagrams

A dotted lined hollow arrow indicates that a class implements an interface. A solid lined hollow arrow indicates that a subclass inherits from that superclass.

The open diamond solid arrow indicates that an object is associated with another object, but it won't be destroyed if the object it's associated with it is destroyed (aggregation. A solid diamond arrow indicates that an object is associated with another object, but that it is dependent on that object and will be destroyed when that object is destroyed (composition). 

The above diagrams are structural diagrams or static diagrams. Although very useful, they don't show the process of the program. To show the process of the program you can use a 'sequence diagram'. Sequence diagrams can't realistically show the entire program all at once, just portions or certain scenarios.

Sequence Diagram

Here is an example sequence diagram, but it doesn't apply to our game example.

S.O.L.I.D. Principles of object-oriented design

'SOLID' a useful checklist to consider while doing object oriented design.

1. S. Single Responsibility Principle -  Create objects for 1 purpose. Don't combine multiple objects into 1 object (god objects). Objects should be responsible for itself.
2. O. Open / Close Principle - Open for extension, but closed for modification. If you need to modify expand on a program, don't modify old classes, objects or functions; instead create new objects or classes in addition to the old code.
3. L. Liskov Substitution Principle - Subclasses should be able to be treated like their super class.
4. I. Interface Segregation Principle - Interfaces shouldn't have too many signatures; if it does then those signatures should be split up into multiple interfaces. Classes can implement multiple interfaces.
5. D. Dependency Inversion Principle - It's often more intuitive or logical to create subclasses of abstract classes rather than subclasses of concrete classes. Example: a subclass 'blueJ' of super class 'robin', isn't intuituve. Instead there should be a third abstract class called 'bird' that classes 'blueJ' and 'robin' inherit from.

G.R.A.S.P.

General, Responsibility, Assignment, Software, Patterns.

1. Creator - Determining which objects should be responsible for creating other objects. Does one object contain, very closely use, or know about another object? If so it should be the object to create the other object.
2. Controller - Instead of linking a UI object directly to the application main objects, it's better to use a controlling between the two.
3. Pure Fabrication - This is a class that's roll is for pure functionality of the program. Sometimes concept models don't account for a realistic functioning program. Sometimes additional, purely functional classes are needed.
4. Information Expert - Assign responsibility to the class that has the most information needed to fulfill it. Example: containing data regarding the number of orders should be in the 'shoppingcart' class rather than the 'customer' class of the 'item' class.
5. High Cohesion - When an object's behaviors are related to its single responsibility. 'Low cohesion' means the opposite like in a 'god object'.
6. Indirection - Sometimes there's no getting around many objects that need to communicate with one another. This can lead to 'high coupling'. Instead create a new object to mediate or simplify communication between these objects.
7. Low Coupling - A coupling is a dependency i.e. a subclass is dependent on it's superclass. Low coupling means that an object has the least amount of dependencies as possible while still functioning.
8. Polymorphism - The ability for a class to function with different subclasses.
9. Protected variations - 'Encapsulation' and 'data hiding' do this. the consept 'Open / Close Principle' & 'Liskov Substitution Principle' from the S.O.L.I.D. checklist do this. Protecting variations is basically the goal of changing a program as needed with the least amount of change and risk possible.

A.E.I.P.

Also known as 'apie'. Concepts for good object oriented programming.

1. A. Abstraction - Grouping your code into sections, like classes, objects & APIs where the complex processing is happening 'behind the scenes' and all that you need to know or all that communicating objects need to know are a small number of input or output variables.
2. E. Encapsulation - Hides internal details of one object from another.
3. I. Inheritance - Instead of rewriting code, have classes inherit from super classes. This means your program will require less code and be easier to add onto or update.
4. P. Polymorphism - The ability of one object to be generic and used in many different ways. taking a different form is called polymorphism.