Static and recursion

Absolutely not.

Thanks Mike.

Just as an aside, when do you decide to use a static method / class instead of a standard method in a class ?

At the moment I am leaning towards:

if the method does not read / write any class properties, nor call any other method in any other class that require some state to be stored, then it can be a static method.

jmls wrote:
Thanks Mike.
Just as an aside, when do you decide to use a static method / class instead of a standard method in a class ?
At the moment I am leaning towards:
if the method does not read / write any class properties, nor call any other method in any other class that require some state to be stored, then it can be a static method.

Another way to look at it: static syntax is some sort of pseudo-syntax (such as: util.debug:LogMessage()). Obviously you cannot store state (except for state that is global to the session) since you have not instantiated a class and don't want to or need to.

In general I do see 3 use cases for statics:

1. that only have static members (methods and properties and internal variables).

Those classes usually contain API code or common infrastructure code. Very common to a session super procedure.

2. singleton implementation

If you want to ensure that there is only a single instance of an object running in a session (like a main menu form of common infrastructure components).

3. location of instances by various arguments.

A sample for this is the static method FromForm in the Infragistics UltraToolbarsManager.

Infragistics.Win.UltraWinToolbars.UltraToolbarsManager:FromForm (oForm) will return the reference to a toolbars manager (if any) that's related to the referenced Form. As the UltraToolbarsManager is no Controls it cannot be located using the public Controls collection of the Form.

I'm sure there are many others, but hey it's weekend...

While agreeing with the other two, Julian, I would suggest a little change of focus in your statement.  I.e., it shouldn't in terms of "can I get away with this being static", but "is there a good reason why this should be static".  If you have a class with two methods out of twenty that meet your criteria, but which don't have any particular reason to be static, then don't make them static ... all it will do is to confuse the next person dealing with the class.  Partition your functionality into static things and everything else.

I have to say that is what I do: I may have two classes for an object: One for all the static methods, and one for everything else. I really don't like the mix'n'match approach in a single class.

Well, there also shouldn't be two classes for the same object, either.  You should have a one to one map between a "responsibility" and a class.  It is fine to have some service classes to support an entity class and the service class might be static, but you want all of the behavior of the entity itself encapsulated in the class for the entity.

So, if I have a method to remove an orderline (for example) and this method takes one parameter (OrderLineGUID) and returns a true or false .

Now, there may be several part of the application that would require this functionality. Previously, I would have to create an orderline object, then call this method, then delete the object. Turning the method into a static would remove the need to create and destroy.

how would you go about this ?

So, if I have a method to remove an orderline (for example) and this method

takes one parameter (OrderLineGUID) and returns a true or false .

Now, there may be several part of the application that would require this

functionality. Previously, I would have to create an orderline object, then

call this method, then delete the object.

This is the way I'd go. If you did this via a static method, you'd have to fetch the data each time, and since an orderline is typically part of an order, you may find yourself having to fetch that too etc. I'd prefer to have the data as a unit.

Turning the method into a static

would remove the need to create and destroy.

Is this a big deal - the continual creation and destruction? (I mean, sure, on a psychic level maybe but in code?

-- peter

It is all about encapsulating responsibility.  Yes, pre-OO you could simple delete an order line anywhere you wanted ... but, was that actually a good idea?  Might there not be fields in the order which were impacted by that deletion?  Might your actions not be different if it were the last remaining line in the order?  Or, perhaps that order line was already shipped or on a picking slip in the warehouse?  I.e., these things have to be done in a controlled way in context.

So, seems to me that you need an Order with a property connecting it to a collection containing order lines.  Generally, I would say that it was preferrable for the Order to have AddLine and DeleteLine methods because it is the Order that needs to supervise that it is OK to delete and make any required updates in itself.  If you grab the line and then say DeleleYourself, it means that the OrderLine needs to run methods in the Order to say "I'm leaving now", which is backwards, I think.

Come to the PUG Challenge and you can here me talk about the different patterns for managing this kind of relationship.  There will be a white paper and even some code somewhere in here too.

You are right - it isn't a good idea. That's why now we use the orderline object. Well, technically, we use the order object which "passes on" the method to the orderline object within the order.

I am just trying to work out when to use a static or not. What's the point of statics if OO dictates that everything must be in an object ?

I can see the Order passing on a "get yourself ready to be deleted" method, but I can't see the order line deleting itself.

To me, statics are primarily for utilities, i.e., the same kind of thing one might put in a Session Super that was going to be there all the time.  It is not something that one would use typically for individual instance objects except for special circumstances, e.g., GetNextAvailableID might be a static method of an instance class because what it is really doing is encapsulating the get next sequence, but needs to be shared by all instances.