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.