I want to illustrated my question by way of a (hopefully) representative example.
Lets say I have a situation where I am developing a class library in C# to be used in some simulations. I want to define the planets (Earth, Mars, Saturn, etc.) and have each of them have some properties and methods that are common in interface (name, signature, etc.) but unique in implementation per-each. I.e. Earth.Mass is not equal to Mars.Mass.
So far no big deal.
I want to have some other classes/methods/algorithm that accept as an argument a planet and use its defined properties and method:
double MyApparentWeight(Planet someplanet, double MassInKG)
double DistanceFromInKM(Planet someplanet, Planet originplanet)
Planets could be used all over the place by someone using this library. All "Earth"s should be identical and all "Saturn"s should be identical. Obviously the "Earth"s are distinct from the "Saturn"s.
I also want a user of the library to be able to easily create a new planet (e.g. Vulcan, Endor, Tralfamadore, Persephone, Rupert, etc.). It should be forced to supply the properties and methods of the existing ones and hence be useable by the MyApparentWeight and DistanceFromInKM methods.
So the base level approach is that there is a Planet class and then the specific ones (Earth, Vulcan, etc.) simply inherit from that. In this case though a user needs to either create an instance of Earth and carry it around or create a new one every time it is needed. That could be unnecessarily clunky (especially in light of the expected users) and possibly a performance hit since some Planets could have initialization steps of reading date from files, etc.
The next idea was the above but with a singleton paradigm. That's basically what I've done so far. This seems to be dictating internal implementation to any new Planets that are created (and again some what of a concern given the potential level of some users).
This project is how I've been cutting my C#/.NET teeth. My initial naive approach was to try to do static classes with interfaces or inheritance. Obviously I learned quickly the folly of that path. At a high level that is the kind of paradigm I would have wanted though.
Is there some other design pattern that I'm missing that could cover this type of situation?
Appreciate any suggestions.
I may not have made it clear that this
Planet example was only meant to be illustrative structurally and not directly representative of the actual computations. Some people seemed to get a little wrapped up in the implementations of what data is being represented within them and other peripheral aspects.
The suggestions of the individual planets (like Earth) merely being instances of the
Planet class didn't catch my points about potentially significant different implementations for their internal mechanics supporting their methods and properties. I'm also at a loss as to how it helps with not wanting to manage carrying around those instances potentially anywhere you may want to use them or having to create new instances.
Glenn's extension of Stephen's suggestion I think actually works the best in the context of what I need here. I can couple that with rsbarro's suggestion of having static properties for the built in
Planet children. (Actually more like
interface IPlanet implementers). That provides the easiest access for the users for the most commonly used items and offers a slight performance improvement of not having to retrieve from the dictionary by name each time. It still offers the ability for the users to dynamically add more types of Planets.
I don't yet have the rep to up-vote all of the answers I mentioned above or I would.
Thank you all for your suggestions and feedback.