OK - bear with me, bit of a newbie here - coming from a VB background.
Basically VB has messed my head up, now I am trying to figure out how I should go from static classes or somehow try and make it an object - I take it I should not have loads of static classes around as this is a proper OOP language. (you might have guessed I have migrated VB code to C#).
Does anyone have any hints/tips/advice?
Static classes are rarely necessary. It's hard to give you much information without knowing what specific problem you are facing. What does the static class do that you want to conver?
Well 95% of code is accessing external COM libraries which work with a GIS application. Some code is generic (see below), but how could this be an object - and would it be necessary??
Code:private static int RoundToNearest100(int iNumberToRound) { int iToNearest = 100; int iNearest = 0; bool bIsUpper = false; int iRest = iNumberToRound % iToNearest; if (iNumberToRound == 550) bIsUpper = true; if (bIsUpper == true) { iNearest = (iNumberToRound - iRest) + iToNearest; return iNearest; } else if (iRest > (iToNearest/2)) { iNearest = (iNumberToRound - iRest) + iToNearest; return iNearest; } else if (iRest < (iToNearest/2)) { iNearest =(iNumberToRound - iRest); return iNearest; } return 0; }
Well that's not a static class, it's just a static method. There is nothing wrong with declaring a method like that as static.
I see - yes, of course its a method not a class -
Thing is Ive got loads of these little encapsulated methods every where, some void others returning arrays, strings, ints etc.
It all looks a bit VBish - I just thought it might be the wrong approach, and I cant get my head round these being made into objects.
Having said all this - my application does work - but I suspect as it gets more complex it will become harder to do because I havent taken advantage of the principles of objects.
Well if you are new to OO programming then you can regard an object as an object from real life.
For instance:
A chair is an object, a chair can come in many forms.. and colors... So basically you can create a class Chair ... which will have properties like color, height, width etc etc ... Now you can create multiple chair - objects being all just a bit different... Hell you could even let the class Chair inherit from a class called Furniture ( since every chair is a furniture but not every furniture is a chair ) ...
I hope you see where im going with this...
Then for the statics ... as long as a method doesnt need any property that belongs to an object of that same class , or if it doesnt change any property of an object of that class... then I should make it static.
Thats why methods in the Math class for instance are all statics, since it doesnt modify any object from the class Math ( also because its not even possible to have a Math object ) , and it doesnt need any property from a Math object ( even if it would exist ) , to calculate the sin or cos or pow you don't need anything else then the params you give along with the function, based on those params and those params only it will return you a result....
Hope I made my point clear... if not you should be more specific what exactly you don't understand about static vs nonstatic publics etc ...
-Ganglylamb
Last edited by GanglyLamb; 02-08-2006 at 04:15 PM.
