static/Shared methods

One of my co-workers is designing an enterprise software architecture and is finding that most of the method calls in classes that form the Business Facade layer are stateless. He is proposing, then, to use Shared methods (in VB.NET, or static methods in C#) as a coding standard.

My thinking is that this would increase the memory working set for the application as all these shared methods would instantiate an object on startup and never discard it. Is this correct? Are there other downsides? The advantage, he says, is that the coders don't have to instantiate the class to call the method - it simply reduces code.

What are the best practices around when to use static/Shared methods and when not to use them?

 

7 Comments

  • I would say that in general to stay away from static methods.



    The only exception for this is methods like the Parse method of Int32.



    Since you would not want to do something like



    Int32 value = Int32("123")



    Because constructors are not meant to be hefty just only initializers you would instead want to call a method which implies processing.



    Int32 value = Int32.Parse("123")



    You would not want to do something like



    Int32 value = new Int32() // if this was possible

    value.Parse("123")

    // or

    value = value.Parse("123")



    That is when you want to use a static method because you do not require an instance of the method.



    Now for the business services you will ALWAYS want to create a unique instance of the class or at the very least make a Singleton object.



    Also remember, static methods cannot be overriden in inherited classes.



    I just found it easier to maintain objects that are instantiated versus ones with static methods.



    Why, well I wrote an exception manager class and I decided, well for ease of use I'm going to make all the methods static and use a singleton approach.



    Well its a nightmare now if I want to change functionality or something else on the object. What if I wanted to inherit the manager into something more specific. I can't, I'm stuck. Not to mention I had to use two objects to get the same thing one would have done.



    It wasn't a true singleton. It created an instance of the instantiatble exception manager and called its methods from the static methods. NIghtmare when I look back on it. But guess what, everyone is using it and I'm stuck.



    If I had done it right I would have made the exception manager abstract and then provided some base functionality then forced each app to at least create one class that implements the exception manager in an appropriate manner for their application rather than forcing all applications to fit into one container (set of methods).



    Just examples of my bad experiences with static methods ...

  • When a method does not consume or modify state information within a class, it is perfectly reasonble to expose it using the static modifier. Your static methods then become more of a function library that you have chosen to associate with a particular class.



    One particularly valuable use of static methods is found in the factory design pattern. Here, you need a place for logic that will determine what object to actually create (and where) for return to a client.



    My guess is your performance concerns are not valid. Certainly, tho, if one would normally have an instance of the class available, probably not wise overdoing the static methods. I would really need more information on this business facade layer implementation...

  • There is no performance issue. The relevant issues are things like inheritance (as Adam pointed out) and remoting. Static methods do not inherit, nor can they get remoted if you may need to use them in a distributed system. However, they are still perfectly reasonable, if not prefered, when you are creating simple libraries of functions.

  • Udi, I know, that your knowledge of soa is good, but i do not think, that exposing some method as static is a move towards soa. You would have to change more, than only few method. But certainly you know it, so nothing more needs to be said here :)

  • Radim,



    Kudos ! You've done it ! You've managed to push me over the edge to finally ( FINALLY ) write a post on migrating to SOA.



    I'll post a link here too later.

  • I agree with the statement that static methods are great for function libraries. I would even go as far to say that it becomes a non-issue if you class is sealed. Since it cannot be inherited then there is no reason not to have static methods if you really do not need to maintain state.



    I can some what see why an SOA layer can use static methods. There really is no need to inherit SOA services. Of course this makes me wonder how SOA scales into remoting and such.



    But sometimes I'm always thinking ahead, saying to myself, you know I could extend this object in the future and if I force it to this limitation now because I'm not planning on extending it but I could see management saying 2 months after the release that they would want that functionality ... well then ...



    I'm discovering maintaining API's is tricky and political business. Specially when they support line-of-business applications. :D

  • Adam,



    Your comment touched on a very important, specific point. "management saying 2 months after the release that they would want that functionality ". They want functionality. They don't care about objects, inheritance, remoting, etc.



    At the most basic level, adding functionality means adding another method to a given service - or adding a new service with that method. Then, use the new functionality in client code.



    I don't see this as having much to do with extending objects, inheritence, etc. Its about the business. Of course, when it comes to implementing the functionality, use all the tools and methods that OO gives you - I mean, why not ?



    Finally, SOA doesn't scale by remoting - whatever that means. SOA scales by either scaling up the server a given service is running on ( adding RAM, more CPUs, etc ), or by scaling out to more servers. Because of the stateless nature of a service, you don't have state affinity issues, so its that much easier.



    Finally ( and this time I mean it ), SOA is ALL about line-of-business. Yes, it's sometimes tricky, but hey, that's why we get paid the big bucks.

Comments have been disabled for this content.