SObject Domain chain methods

[geezeuz]

Hello and thank you for the time and effort you've given to the community.

I'm doing some testing using fflib_SObjects to understand the best way to inherit and use super class methods.

In my scenario I would like to filter records using getRecordsWithBlankFieldValues and then use getStringFieldValues to get some field values.

public class Contacts extends fflib_SObjects {
     public Contacts(List<Contact> records){
         super(records, Contacts.SObjectType);
     }
}

I would like to do something like:

Contacts contacts = new Contacts(new List<Contact>{
    new Contact(Email='[email protected]'),
    new Contact(Email='[email protected]', AccountId='001000000000000')
});

Set<String> emails = contacts
    .getRecordsWithBlankFieldValues(Contact.AccountId)
    .getStringFieldValues(Contact.Email);

My current approach to do something like this is to create a method on the Contacts class to return a new instance of Contacts with the List<SObject> result of getRecordsWithBlankFieldValues but I'm not sure if is better to handle that from within fflib_SObjects.

any thoughts?

[wimvelzeboer]

Hi @hernandezjesus

Both methods getRecordsWithBlankFieldValues and getStringFieldValues are not intended to be used publicly, but should be encapsulated in a public getter and selector method.

The domain would look something like:

public class Contacts extends fflib_SObjects implements IContacts
{
    public Contacts(List<Contact> records)
    {
        super(records, Contacts.SObjectType);
    }

    public IContacts selectWithoutAccount()
    {
        return new Contacts(getRecordsWithBlankFieldValues(Schema.Contact.AccountId);
    }

    public Set<String> getEmail()
    {
        return getStringFieldValues(Schema.Contact.Email);
    }
    ...
}

You would call this logic via:

Contacts contacts = new Contacts(new List<Contact>
{
    new Contact(Email='[email protected]'),
    new Contact(Email='[email protected]', AccountId='001000000000000')
});

Set<String> emails = 
    contacts
        .selectWithoutAccount()
        .getEmail();

Notice that in this example the reference to the actual field names are encapsulated in the domain, not in this logic. In this manner only the domain knows about the field names, which makes refactoring a lot easier if you ever need to rename the field.