In the Mike vs George debate I’d side with Mike. I’d disagree with static classes being more easy to maintain. A clean OO class architecture will always win out on the maintainability debate mostly because of potential class hiearchies coupled with good ol’ polymorphism.

That said I am a fan of static classes, but would usually use them in utility classes or architectures that subscribe to factory patterns e.g. If I were using an enum as you have above I might’ve declared it as static in a utility class.

Thread safety is really the only issue to review when using static methods. Assuming the static method is not dependent on any globally scoped objects, then either approach is fine.

There are a couple of reasons I would use static methods over the object-oriented approach: maintenance and performance.

If a lot of people will be editing the code over time (maintenance) and some of them are not professional programmers, it is sometimes best not to introduce object-oriented concepts if they are not needed. This really depends on the skill set of those maintaing the code.

On the performance side, creating an object has a cost associated with it, both in terms of creation, and later when it has to be garbage-collected by the system. So I tend to avoid creating temporary objects if I can avoid it. This is just a habit after years of tuning server-side Java code, and may not be relevant for Apex.

It keeps the signatures of the methods clean, but they can only be called when the class has been instantiated.

Would love to hear your thoughts on static vs. instantiated in this case.

Thanks for all the great comments everyone!

MyObjectClass process = new MyObjectClass(Trigger.new, Trigger.old);

//switch or if statement block
process.OnBeforeInsert();
process.OnAfterInsert();
process.OnBeforeUpdate();
process.OnAfterInsert();

Microsoft really killed their Win32 API with too many macros/structs/enums. .NET corrected this mistake.

Being a long time Java programmer, I have one question for you. Is there any reason you are performing the logic in a constructor versus a public static method in the class? This is the approach I typically use, no need for enums or multiple classes. For example:

if(Trigger.isInsert && Trigger.isBefore){
MyObjectClass.beforeInsert(Trigger.new, Trigger.old);
}
else if (Trigger.isAfter && Trigger.isInsert ){
MyObjectClass.afterInsert(Trigger.new, Trigger.old);
}
…

In the MyObjectClass you just define the methods as static so they can be called without an object instance:

public class MyObjectClass {

public static void beforeInsert(MyObject__c[] myObjects, MyObject__c[] myOldObjects) {
…
}

pubilc static void afterInsert(MyObject__c[] myObjects, MyObject__c[] myOldObjects) {
…
}

There are two pieces of data: operation and type. Operation would be an enum for the DML operation, Type could be before or after. Type could be an enum. Or you could just use the isBefore boolean.

Trigger.Operation enum and Trigger.Type enum (or the current Trigger.isBefore)

Or you could flatten everything into Trigger.Action, an enum that would combine the two values to “Before Insert” and “After Insert”, etc.

Sounds like we need an idea.

Another thing that helps readability is to just set transaction state in the constructor then call an Invoke() method on the trigger to do the actual work.

Otherwise the lvalue stuff from the constructor just looks like dead code.

MyObjectClass process = new MyObjectClass(Trigger.new, Trigger.old, triggerAction.beforeInsert);
process.Invoke(); // or alternatively process.Execute();

Of course, this all begs the question “Does Apex require an lvalue when calling new?” (I don’t know).

Would be even nicer to use a fluent expression like this:
new MyObjectClass(Trigger.new, Trigger.old, triggerAction.beforeInsert).Invoke();

In this case, I’m not sure that the second way is much of an improvement. You still have if isupdate/isbefore blocks in both the trigger and the implementation class. Why not move the invocation of the someBeforeInsertMethod-type methods to the trigger? Then your implementation class is cleaner. Just 4 methods sans big ugly if blocks.

I’ve also used the Command pattern with some success. Doing things the “right” way (here comes the rant) is still troublesome in force.com because creating classes, interfaces, etc. in the IDE is slow and laborious, roundtrip saves are slow and there are no namespaces/packages like Java, .NET, etc. If force.com wants to be considered a serious platform, they have to fix these things. Until then, I’ll prefer to write non-trivial apps on a different platform.