Hmm there are a number of patterns I like...
The singleton pattern is a very good one. Although lately I've been doing it a little differently.
Instead of exposing the instance reference (which I always call 'fetch') as a public static member, I leave it as a static private. Only the class itself has access to 'fetch'. Then for each property I want to expose, I create a get { return fetch.myInternalProperty; } }.
This way, all other classes only see the bits of the singleton I choose to expose. Makes for much prettier autocompletes
Another pattern I like, but very rarely get a chance to use, is Parameter Chaining.
It allows you to define parameters when constructing a new instance, but those parameters are optional and can be set in any order.
It's done like this:
Code:
class MyClass
{
private myProp1;
private myProp2;
private myProp3;
// constructor
public MyClass()
{
}
// setters for each property
public MyClass setMyProp1(value)
{
myProp1 = value;
return this;
}
public MyClass setMyProp2(value)
{
myProp2 = value;
return this;
}
public MyClass setMyProp3(value)
{
myProp3 = value;
return this;
}
}
// then, when instantiating, you can do this:
MyClass myNewInstance = new MyClass().setMyProp3('blah').setMyProp1('bleh');
It's a very cool pattern for when you have small classes and you don't want to add too many lines of code for them, or declare a lot of variables...
I did this for the Tutorial Arrows that pop up in the KSP tutorials... they have methods for setting their colors and arrow orientation, and since they're stored in a base class for later deletion, and don't do nothing by themselves after being created, I don't need to store them again in the actual tutorial extension
It's not often that one gets to use the Parameter Chaining pattern, but it's a cool one.
I'm not a huge fan of the Factory pattern... I guess it brings back memories of the J2ME classes back in college...
The Wrapper pattern is another one I like... when things don't fit, you create another class to abstract the differences, and that class has a more solid external interface.
I did this for the part sounds and effects in KSP, too... since parts are loaded in runtime, and the asset structure isn't known, I created an FXGroup wrapper class for the sounds and particle effects. This class let's you assign effects and sound to it, and provides methods to activate them all. So each part has a number of FXGroups, one for each event in which there is sound or particles. An effect might be assigned to multiple groups also, to facilitate things like RCS thrusters and stuff like that.
In fact, the whole FXGroup idea isn't actually mine. Orbiter does it. They're called ThrusterGroups. I just tweaked the concept a little
Cheers
