Class Size and Object Instantiation

[Roey]

What are the general thoughts on class sizes. I have been trying to follow an OOP design methodology and was just wondered what other people out there were doing.

 

Is it best to have large classes (objects) instansiated at form load which can address multiple requirements of a specific form, or small classes (objects) that can be instantiated and then disposed of as needed by calling methods.

[Mike_R]

This is a judgment call (of course) and you're just looking for an opinion... But I think that a decent rule of thumb would involve how many Public Members it has. I'd say up to 8-12 is fine for one object. Maybe 15. Past that and I really start to think about breaking up my objects.

 

With too many public members for one class, it can be hard for the user to "see" them all. In that case, creating a sub-class (also public) that contains some of the functionality starts to make sense. It becomes a sort of Tree-View, if you will.

 

Make sure your nomenclature is clear. I prefer Noun-Adjective for my Methods, e.g., I would use .PermissioningSet() and .PermissioningClearAll() instead of, say, .SetPermissioning() and .ClearPermissioning(). I know it's a little awkward to read it "backwards", but it's very nice to have all related commands together alphabetically under IntelliSense. Otherwise "Clear" and "Set" are very far apart and the User may not realize all the Permissioning-related commands that could be done. However, if you only have 8-12 Members, or less, then this is less critical, as the User can generally be aware of all the Members rather easily.

 

As you develop and add features you may start to see several members all clustered. You might get four or more related commands, like the following:

.PermissioningClear()
.PermissionLevel(int)
.PermissionPassword(string)
.PermissionAdmin(bool)
.PermissionLog(string)

I made this up, but the point is that that if this set of Methods begins to "take up a lot of real-estate" you might want to seriously consider making a nested public class called 'Permissioning' and then have these 5 methods within that. And then you need a Method that returns a 'Permission' object. A call to one of these would then become something like 'myObject.Permissioning.Clear()' or the like.

 

So if you have too many Members overall, or if you find that too many start to group in one category, then it becomes a serious consideration to regroup your Class into Sub-classes.

 

Invariably this stuff just "evolves"... Unfortunately, this means that all Callers also have to adjust after you've Refactored your Classes to be broken up. So best if you can see all this ahead of time (and code it for multiple objects from day one), but the reality is that one can only see so far...

 

I find that adjusting the callers of your Class(es) after Refactoring tends to be very easy, trivial even. A straight text-replacement tends to do the trick. However, if you work in a multi-programmer environment, then changing your object model mid-stream cannot be taken so lightly...

 

I hope this was some food for thought?

 

-- Mike

[IngisKahn]

Don't run FXCop on that! :p

According to Patterns and Practices, made-up words and public nested classes are taboo.

 

Whether you load on startup or on demand depends only upon how you think it should work.

[Mike_R]

Ok, well, hmm... that's interesting. I don't have a problem with nested classes myself, I actually find it clearer. But you're right, I guess it's more standard for them to be "tandem". An example might be the Process Class and the ProcessStartInfo Class. However, although technically not "nested", it is quite clear that the ProcessStartInfo Class is "subordinate" to the Process Class.

 

I don't know what you mean by made up words? I made up a whole set of Methods that don't really exist as an example. But the words "Permission", "Clear", etc., are all words, yeah? I'm not sure that I follow...

 

The loading on demand or on startup depends on how you think the resources are best used. Large resources that are used from start-to finish could be loaded immediately and "held" for the duration of your App. I would generally just "let it fly" and not worry about it too much, although I will sometimes keep several forms loaded at all times and simply Hide/Show them (instead of Load/Unload them) as necessary. For more substantial resources it may or may not make sense to have it kept loaded the whole time. Generally I'd not worry too much about this and just let the Garbage Collector do its thing, but there are times when you'll want to think about this, esp. for larger resources.

[PlausiblyDamp]

If a resource might be needed rather than always needed during a program execution you may want to look at a more established pattern (Singleton, Proxy etc) to hide the logic of exactly when it gets created. This can be especially useful if the resource is memory intensive as well.

[Nerseus]

@Roey: Generally, you'll find more smaller classes will popup. A first pass might yield one big class with 50 properties, but some good refactoring will help you find smaller classes that make the code more managable. One technique I found to work well was to take that existing procedural code (even if it has a lot of events and other non-procedural code) and refactor everything into one or two classes (as a first pass). As you start refactoring out temp variables into functions/methods you'll probably start to recognize some "classes". As you use the functions and methods more, you may refactor more and more until the code starts pointing you to the objects. It's a bit backwards from the usual "identify the classes first" approach of OOP, but works very well when you start with a lot of non OO code.

 

I guess the simple answer is: more smaller classes.

 

-ner

[IngisKahn]

Mike - sorry, by made-up I meant permissioning. FXCop performs a spellcheck on all tokens and handles PascalCase and camelCase.

[Mike_R]

Hey, no prob., and that FXCop looks pretty darn cool.:cool:... I'll give that a whirl sometime.

 

I guess "PermissionSettings" would be the correct term for "Permissioning"? I don't think it matters much here, but sometimes using a reasonably-clear abreviation is in order to shorten the length... Just avoid meaningless terms like "Widget"! :p

[Nerseus]

Last I heard/saw, fxcop has been included/integrated into the new Visual Studio. What's more, you can set options on the new sourcesafe to not allow checkins if the code isn't "clean". I'm not 100% sure that it can see the "errors" that fxcop finds, but it will have options to not allow checkins if there are syntax errors or other Build Errors (which might be Warnings treated as errors).

 

And yes, fxcop is VERY picky, but very nice.

 

-ner

[IngisKahn]

Ya, we use FXCop at work. It's really a godsend when you have to work with other people's code or even older code you've written.