Global Methods in Global Class — The “Everyone Can Use It” Superpower

Views (6)

HardikPatel523

230

Like(0)

Report

Ever written the same utility method in 5 different classes…

and then fixed a bug in only 3 of them? 🤦‍♂️

Yeah… welcome to the club.

Or worse — you know a method should be reusable, but you're like:

“Where do I even put this so everyone can use it?”

That’s exactly where Global methods in the Global class step in like a superhero 🦸

Problem

In real enterprise systems (hello D365FO 👋), things scale fast:

50+ forms
100+ classes
10+ developers
And 1 shared nightmare: duplicate logic

Now imagine a tax calculation rule change:

Old GST logic used in 12 places
New rule introduced
You fix 5
Miss 7

Congratulations, you just created inconsistent financial data.

If logic is reusable and common, it should live in one central place, duplicating it is basically planting future bugs.

Conceptually

A Global class is like a public toolbox.

And Global methods are tools inside it that:

Anyone can use
From anywhere
Without creating an object

Basically:

“Hey system, I need this function — just give it to me!”

Real-Life Analogy (You’ll Remember This)

Think of this like UPI payment system 💸

You don’t build your own payment gateway every time
You use a central trusted system

Now imagine:

Every shop had its own payment logic
Some accept ₹100 as ₹10
Some double-charge

Yeah… that’s your system without Global methods

What goes into Global class?

Utility methods
Shared calculations
Common formatting
Validation logic (generic)

What should NOT go there?

Module-specific business logic
Complex workflows

Example (Real Pain Point — Pricing + Discounts + Tax)

Scenario:

You are building a system where final price =

Base price
Discount (based on customer tier)
Tax (region-based)
Rounding rules

And guess what?

This logic is used in:

Sales Order
Purchase Order
Invoice
Reports
APIs

❌ The “We’ll Fix It Later” Approach:

Every developer writes their own version:

price = basePrice - (basePrice * discount / 100);
price = price + (price * tax / 100);
price = round(price, 0.01);

Looks fine… until:

One place uses 2 decimal rounding
Another uses 3
One forgets discount
One applies tax before discount

Now your finance team is calling.

✅ The “Senior Developer Sleeps Peacefully” Approach:

Put it in Global class:

[ExtensionOf(classStr(Global))]
public final static class SysGlobalCls_Extension
{
    public static real calculateFinalAmount(
		    real _basePrice, 
		    real _discountPct, 
		    real _taxPct)
    {
        real discountedPrice  = _basePrice - (_basePrice * _discountPct / 100);
        real taxedPrice       = discountedPrice + (discountedPrice * _taxPct / 100);

        return round(taxedPrice, 0.01);
    }
}

Usage Everywhere:

finalAmount = calculateFinalAmount(1000, 10, 18);

Now when rule changes:

“Tax should apply BEFORE discount”
You update ONE method.

Not 12 files. Not 3 hours. Not your mental health.

Caution / Mistakes

❌ Don’t do this:

Dumping everything into Global class
Adding business-specific logic
Making it a “God class”

✅ Golden Rule:

👉 If it’s generic + reusable + stateless → Global

👉 If it’s business logic → keep it in module

Reality Check

Junior Developer: “Let me just copy this pricing logic… works fine.”
Senior Developer: “This will break in 6 places later. Put it in Global.”
Architect: “Should this be Global or a pricing engine service?”

Final Thoughts

Duplicate logic = hidden bugs
Global methods = centralized control
Fix once → reflect everywhere
Keep it clean, not overloaded

Bad developers copy logic. Good developers reuse it. Great developers make it impossible to mess up.

Community site session details