💃 Powerful weaponry for devs 🕺

Good morning, Salesforce Nerds!

Now, this is a story all about how my life got flipped-turned upside down. ⏬ 

I’d like to take a minute ⌚️ - just sit right there.

💃 ChaCha 🕺will tell you all about developing dynamic software.

On Salesforce, of course 😉 

Agenda for today includes

• Powerful weaponry for Salesforce devs

• Daily Principle

• All the Memes

Powerful weaponry for Salesforce devs

Today we will discuss -

💃 Dynamic Apex🕺

💃 Simple diagrams 🕺

💃 Show me some code! 🕺

Job Board | 💃 Click Here 🕺

Socials | 💃 Linkedin | Instagram | Twitter!🕺

⚡️ Dynamic Apex

Let’s first level-set on what we mean by “Dynamic” Apex. 🎚️

I’ll let you Google Dynamic Programming Languages and sift through the official definitions on your own time. 👀 

A lot of what you might find won’t apply here. ❌ 

From the perspective of Apex, what we’re talking about is the ability to write code that is generically typed. ✅ 

This allows devs to write generic code that can be reused across any SObject type. 🤯 

Here’s how: 👇️ 

We’re all familiar with SObject’s, right …

Standard or custom objects that store our record data in Salesforce

But, did you know that in the 🌏️ world of Apex - SObject is also something called a superclass?

And specific SObject’s like Account, Contact, Opportunity, That_Stupid_Custom_Object__c, etc. are all subclasses of SObject! 💥 

It’s a classic inheritance model 😃 

🔖 Superclass: Class from which many subclasses can be created. AKA parent class, base class.

🔖 Subclass: Class derived from the superclass. It inherits the properties of the superclass and also contains attributes of its own.

📊 Simple Diagrams:

Just peep this diagram as an example: 👀 

☑️ The Vehicle superclass sits at the top as the most generic type. It has basic Vehicle properties like color, wheels, doors, etc.

☑️ The Car subclass inherits all of the same properties from Vehicle (color, wheels, doors, etc.) and contains some specific properties like trunk, backseat, etc..

☑️ The Truck subclass also inherits all of the same properties from Vehicle and contains some specific properties like Bed, Tailgate, etc..

☑️ The Motorcycle class also inherits … well, you get it. 😅 

The same concept applies to writing Apex against standard and custom objects!

That means this diagram ☝️ can be modified to look like this 👇️ 

To an Salesforce engineer, this means that there is code we can write against the SObject superclass that will work across all subclasses. 🔥 

Just checkin’ in … This is a deeeeeep rabbit hole 🐰

Believe me, we’re just scratching the surface here. Imma save some of the more juicy bits for later, mkay? 👍️ 

💻️ Show me some code!

So, let’s see a quick example with a super common use case:

🎀 Requirement:

When an Account field is changed, cascade this to the related Contacts inside an existing Trigger handler method.

Basic stuff. Here’s some super-simple Apex to do just that with the phone number.

This ☝️ code loops over the records in the trigger variable, checks if the phone number was updated. If so, add it to a List for later processing. 📏 

We can imagine the same kind of code existing across other SObject types, too. I’ve seen it many times.

This works well on a small 🤏 scale, but what about enterprise systems? Or ISV’s? 🤔 

Knowing what we know now, we can leverage “Dynamic” Apex to refactor this (and other similar code) to use a more generic method like this against the SObject superclass:

This ☝️ code takes a Set of SObjectField tokens as a parameter. Then It loops over the records in the trigger variable. For each record, it starts looping over the passed in tokens to check if the field value changed or not with the .get() method.

Now, we’re able to refactor that first code to this:

This code ☝️ passes in a Set instance containing the Account.Phone token to the generic getModifiedRecords() method and stores the result in a List<Account>

Daily Principle

and now....Your Daily Memes