A utility that has utility

Most code bases contain utility classes that get used when written but over time get forgotten about because their scope is too narrow. But a utility I keep coming back to in my code is this:

public class SobUtil {
    // Get the id values from a list of objects
    public static List<Id> getIds(List<SObject> sobs) {
        List<Id> ids = new List<Id>();
        for (SObject sob : sobs) {
            ids.add(sob.Id);
        }
        return ids;
    }
    // Get the id values from a specific field in a list of objects
    public static List<Id> getIds(List<SObject> sobs, SObjectField field) {
        List<Id> ids = new List<Id>();
        for (SObject sob : sobs) {
            Id theId = (Id) sob.get(field);
            if (theId != null) {
                ids.add(theId);
            }
        }
        return ids;
    }
}

There is nothing complicated here. The value is that frequently Apex code is dealing with lists of objects not single objects to keep the number of SOQL calls down. So situations where a list of id values need to be extracted are common and the utility class makes such code cleaner.

For example:

// Read the child objects for a collection of parent objects
Parent__c[] parents = ...;
Child__c[] children = [select ChildField1__c, ChildField2__c, ... from Child__c where Parent__c in :SobUtil.getIds(parents)];

Or the reverse relationship (note the expression “Child__c.Parent__c” evaluates to the field metadata type SObjectField rather than a data value; this technique provides compile-time checking that using strings to identify fields does not):

// Read the parent objects for a collection of child objects
Child__c[] children = ...;
Parent__c[] parents = [select ParentField1__c, ParentField2__c, ... from Parent__c where Id in :SobUtil.getIds(children, Child__c.Parent__c)];

Or a common situation in unit tests where to assert the changes made by a trigger the objects have to be re-read:

// Re-read a set of objects
Object__c[] objects = ...;
Object__c[] actuals = [select ObjectField1__c, ObjectField2__c, ... from Object__c where Id in :SobUtil.getIds(objects)];

But remember that where graphs of objects are involved the first port of call is SOQL relationship queries. Connecting parents and children together programmatically only makes sense in certain circumstances such as in a wizard where the list of objects selected in one page are used to query the list of objects presented in a later page.

Advertisements

2 thoughts on “A utility that has utility

  1. Pingback: Tweets that mention A utility that has utility « Force 201 – Force.com Development -- Topsy.com

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s