Every program starts with an idea. Make sure you are working with a topic that you know well and is of interest to you.
Once you have chosen the main idea, research the domain it falls in:
Why does your application fit into this domain? What makes your application similar to existing applications in this domain, and what makes it different?
What does your application need to do? Before programming you should make a detailed list of everything that will be included in your application.
Example for painting application:
Put a time estimate next to your list of requirements. How long will each take? Give yourself lots of room for error.
Is it too much time? Maybe you can cut some requirements? Maybe the idea is beyond your skill level.
Whatever it is, make sure you have scoped your design to something manageable before you start working.
Disclaimer: this is a simplified way to write UML. There are in fact many ways to do UML diagrams, and we will only be looking at those features that are important to this course and multimedia programming.
If you'd like to learn more, take a look. This lecture should provide you with the basics.
A UML diagram for a class begins with the class name at the top. Clearly we are going to define a Moving Object class, followed by two sub-classes: Player and Enemy.
Now we've added some fields to the classes, and notice this takes on the same structure as if we were to actually code the class. Define the class name, list the fields, list the methods.
The fields are marked with a dash because they are private. If they were public we would use a + sign.
When adding methods it is important to encapsulate the method signature (parameters) and the return type. This should give you a clear idea of what the method will be doing based on: name and parameters (signature) and the return type.
Notice how the methods are public since they are written with the + sign.
We're only concerned with showing our inheritance relationship in our UML diagrams. This is displayed by drawing a solid white arrow from the subclass pointing to the superclass.
There are several ways to organize objects into a functioning application. Software design patterns is the name given to a number of ways of organizing classes and objects. The "Design Patterns" name comes from the book "Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. This book describes a number of ways to organizes classes and objects so that they work well together and so that programmers can easily understand the organization of classes and objects.
As we wish to create more complex and interesting programs, the organization of data (objects and classes), and how those data interact gets more complex. The way we have dealt with this so far has been to have a number of arrays and ArrayLists holding the various objects in the main part of the program. The drawback of this idea of having everything in a big central bucket is that it becomes hard to tease apart one part of a program from another.
At some point we'd like those objects to simply take care of themselves. We're going to look at two useful software design patterns that organize complexity in an application.
In the factory pattern there are objects that need to be created with different properties and returned to some object that contains them. A Creator has a factory method to create a Product which can be though of as simply any object that needs creating. Subclasses of the Creator can override the factory method to return products of different types.
A simplified version of this pattern is in the ArmedRocket.fire() method (in
Inheritance PPT Slides).
The fire() method is part of ArmedRocket,
and generates a Missile object.
In the original game, aliens also generate missiles, which can destroy asteroids and your ship.
You can imagine an Alien class that also has a fire() method that generates a Missile
Example: Painting Application
A painting application may have several different instances of a BrushMovement and several different instances of BrushTips. A factory method in the main Brush class can be used to return a single Brush object that combines a BrushMovement with a BrushTip and returns the composite object to the main sketch where it can be added to an ArrayList.
The decorator pattern can be used to extend (decorate) the functionality of a certain object statically, or in some cases at run-time, independently of other instances of the same class, provided some groundwork is done at design time. This is achieved by designing a new decorator class that wraps the original class. This wrapping could be achieved by the following sequence of steps:
Example: Rewards in a Game
A Player can have a number of power-ups that alter the appearance of the player. As the instance of Player gets powerups, instances of PowerUp are created and are "wrapped around" the player. The player instance is now "decorated" with PoswerUp object. When the PowerUp fades, the player gets un-decorated.
Example: Window systems
As an example, consider a window in a windowing system. To allow scrolling of the window's contents, one may wish to add horizontal or vertical scrollbars to it, as appropriate. Assume windows are represented by instances of the Window class, and assume this class has no functionality for adding scrollbars. One could create a subclass ScrollingWindow that provides them, or create a ScrollingWindowDecorator that adds this functionality to existing Window objects.
Everyone should be familiar with the game Asteroids, but how would one go about coding it? Let's take a look at the requirements. Not that this is a bit more complex than the example in the Inheritance PPT Slides.
Notice with the UML diagram that if it were complete we would have everything we needed to know in order to create this game. We would know what classes, fields, methods and everything else to implement. It's highly recommended to always create a detailed UML diagram for any application that goes beyond 2 or 3 classes or has more than a few simple functions.