When to use statics

jmls schrieb:
Are there any "rules" about when to have a static method ? Properties I've pretty much got sussed (at least for *my* needs!).
If you need to have more that one instance of an object, does that mean I shouldn't use statics ?

I'd say that's a clear yes! The static members (properties and methods) belong to the class and so to all objects of that class. There is no differentiation on the object level.

So, I guess the question is - when do _you_ use a static, and what determines the choice ?

If I only need a single instance (like framework functionality) and I need little control over the lifecyle (I do not need to actually control when the static "object" get's loaded and it lives until the end of the session) then I use statics.

Many bit's of a framework infrastructure can be implemented by classes with only static members (let's call them static classes).

Business logic (things like Business Entities) and UI elements are usually non static. You never know at design time if you don't need more than one instance later. Sometimes I have a few static members (mostly properties) in these classes as well. That can also be used for a sort of inner class communication, let's say counting the number of instances of a certain class.

For example, I have a document class , and there is a method in this class to remove all outstanding documents for a particular customer.

If that would be a method of a business entity it would be non-static. As a library function accepting the customer reference as an input parameter, I'd consider coding it staticly. I guess I'd need to know more about the context to make a good decision which way to go for that purpose.

If you'd be using that library function at various places and many times a static would also be a great plus because you wouldn't have to load and unload the object over and over again (no need to NEW it and DELETE OBJECT it just for a single call).

jmls wrote:
So, I guess the question is - when do _you_ use a static, and what determines the choice ?

I've also found static constructs useful at a 'meta' level, when I need to know something about a class before (or during) instantiation.

For instance, I allow Business Entities instances (so I can use the BE as a cache) to be shared among consumers. These BE's implement ISharedBusinessEntity. In the BusinessEntity class, I define a static temp-table which I use as a registry. All Business Entities are instantiated via the static GetBusinessEntity() method.

class BusinessEntity implements IBusinessEntity:
  def static private temp-table ttSharedBE no-undo
    field Instance as P.L.Object  /* always of type IBusinessEntity */
    field BEName as char.
  method static public IBusinessEntity GetBusinessEntity (pcBEName as char):
    /* look in ttSharedBE for running instance. If it exists, use it etc */
  end method.
  constructor BusinessEntity():
    if type-of(this-object, ISharedBusinessEntity) then
      RegisterSharedBE().
  end constructor.
  method protected void RegisterSharedBE():
    /* Add this-object to ttSharedBE */
  end method.

Of course, this same functionality can also be implemented using the Singleton pattern. And that could use statics or just walk the session object pool.So a follow-on question is: which is better. That lead me to this comment, which makes a number of good points (though the question is about C#, the answer is pretty generic); basically, it depends, and the larger your codebase, the more wary you should be in using static members.

http://stackoverflow.com/questions/731763/should-c-methods-that-can-be-static-be-static/731925#731925

Elsewhere, a point was made that you can pass and store singletons around as class instances. I think that ties back to the size-of-codebase issue above, since in a larger application, you may have a manager of singletons with some generic code to manipulate them. This would not be feassible (or maybe not even possible) using static members.

That's not to say Singletons don't have their own detractors ...

-- peter

pjudge schrieb:
class BusinessEntity implements IBusinessEntity:

  def static private temp-table ttSharedBE no-undo

    field Instance as P.L.Object  /* always of type IBusinessEntity */

    field BEName as char.

That reminds me that I wanted ot ask if specialized object types as temp-table columns is already on the road map (10.2B is close). I mean the ability to have an IBusinessEntity field in a temp-table and not just an P.L.O. and a convention saying it's always of type IBusinessEntity. OO is all about strong typing, so why not in a TT?

mikefe wrote:
That reminds me that I wanted ot ask if specialized object types as temp-table columns is already on the road map (10.2B is close). I mean the ability to have an IBusinessEntity field in a temp-table and not just an P.L.O. and a convention saying it's always of type IBusinessEntity. OO is all about strong typing, so why not in a TT?

Hi Mike,

  Yes, it is on our roadmap to allow user-defined types (not just PLO) as temp-table columns.  Of course we can't commit to any release/timeframe at this point.

     -Martha

heh. Seeing as it has been three years since this post, I was wondering if we were any further down the road

This is a fascinating video on how statics (and global states in general) are a real testability problem:

http://www.youtube.com/watch?v=wEhu57pih5w&feature=relmfu