That's a valid question.
There is no real performance related reason for this (in this case anyways), but merely a 'code of conduct' when it comes to OOP programming.
This type of doing things is called a Design Pattern (http://www.dofactory.com/). This one in particular is called a Singleton(http://www.dofactory.com/Patterns/PatternSingleton.aspx).
Ensure a class has only one instance and provide a global point of access to it.
Design patterns are meant to standardize the layout of code and offer solutions to potential pittfalls that may occur in OOP programming.
The reason I am using it here is because the situation faced here is best solved using a Singleton. And simply because it has become a habbit I picked up working with C#/.NET.
This does bring us back to the original post: Why do I make the 'Instance' variable Part of the Type and not have it outside the Type? This to is done partly as per the Design pattern specification. In my view, this Instance is the 'Entry Point' or 'Door' to the only available version of my Manager class. And therefor it has very strong ties to the Type/Class itself. Which gives only one logical solution, make it part of the Class/Type itself.
Also, as said, I have been using Design Patterns in C# rather extensively and C# does not support Global Variables or Functions. Wlell, not in the sense that Blitzmax knows them anyways. C# only supports Static and Constant members for a class, which can only be defined as a part of a class (as is done in the code in my Manager type).
When dealing with OO code it may be wise to read up on Design patterns. Some of them are rather complicated and some may not serve you any purpose what so ever, but if anything, they provide a usefull insight into the way of thinking behind OOP programming and may help you solve some potential problems you may encounter, before they actually happen by sticking with a tried and tested way of designing your code.
Note that contrary to what some OO guru's may tell you, Design patterns are NOT the Be-all-end-all. They are not some magical way to make your program Bugfree and the easiest to understand code you have ever written. That's bogus. Also some patterns are expressly made to cover some very very rare situations and will hardly ever proove usefull. Also many patterns are geared towards everyday use in commercial software design, where performance is not often as paramount as in a high stakes environment as a Game. So you may, at times, want to do things your own way because it's simply a lot more efficient and squeezes just a few more Fps out of your engine.
Think of these patterns as Guidelines, not Rules.
Ironically, even the hardcore OO programmers, who used to be completely full of Design Patterns, have realized this and they created 'Anti Patterns'. Yes that's right, these are official :p
They are not just for study though, but also used in situations where a regular Design pattern just wont do the job.
There is no real performance related reason for this (in this case anyways), but merely a 'code of conduct' when it comes to OOP programming.
This type of doing things is called a Design Pattern (http://www.dofactory.com/). This one in particular is called a Singleton(http://www.dofactory.com/Patterns/PatternSingleton.aspx).
Ensure a class has only one instance and provide a global point of access to it.
Design patterns are meant to standardize the layout of code and offer solutions to potential pittfalls that may occur in OOP programming.
The reason I am using it here is because the situation faced here is best solved using a Singleton. And simply because it has become a habbit I picked up working with C#/.NET.
This does bring us back to the original post: Why do I make the 'Instance' variable Part of the Type and not have it outside the Type? This to is done partly as per the Design pattern specification. In my view, this Instance is the 'Entry Point' or 'Door' to the only available version of my Manager class. And therefor it has very strong ties to the Type/Class itself. Which gives only one logical solution, make it part of the Class/Type itself.
Also, as said, I have been using Design Patterns in C# rather extensively and C# does not support Global Variables or Functions. Wlell, not in the sense that Blitzmax knows them anyways. C# only supports Static and Constant members for a class, which can only be defined as a part of a class (as is done in the code in my Manager type).
When dealing with OO code it may be wise to read up on Design patterns. Some of them are rather complicated and some may not serve you any purpose what so ever, but if anything, they provide a usefull insight into the way of thinking behind OOP programming and may help you solve some potential problems you may encounter, before they actually happen by sticking with a tried and tested way of designing your code.
Note that contrary to what some OO guru's may tell you, Design patterns are NOT the Be-all-end-all. They are not some magical way to make your program Bugfree and the easiest to understand code you have ever written. That's bogus. Also some patterns are expressly made to cover some very very rare situations and will hardly ever proove usefull. Also many patterns are geared towards everyday use in commercial software design, where performance is not often as paramount as in a high stakes environment as a Game. So you may, at times, want to do things your own way because it's simply a lot more efficient and squeezes just a few more Fps out of your engine.
Think of these patterns as Guidelines, not Rules.
Ironically, even the hardcore OO programmers, who used to be completely full of Design Patterns, have realized this and they created 'Anti Patterns'. Yes that's right, these are official :p
Anti-patterns, also referred to as pitfalls, are classes of commonly-reinvented bad solutions to problems. They are studied, as a category, in order that they may be avoided in the future, and that instances of them may be recognized when investigating non-working systems
They are not just for study though, but also used in situations where a regular Design pattern just wont do the job.