How to extend the `Set` class

apexclassinheritance

Is there any way I can extend the Set class? I have numerous places in code where if I a set has no items, I want to add all the items in another set, but if it does have items, I want to retain only the items in the other set.

This seemed like a good use case for extending the Set class, but Apex complains about the lack of < following the extending of the set and the declaration of a Set argument in the following code:

public with sharing class CoreSet extends Set {
    public Boolean retainAllIfPopulated(Set other) {
        return this.size() > 0 ? this.retainAll(other)
                               : this.addAll(other);
    }
}

Is it possible to extend the built-in Set class?

Best Answer

No, it is not possible to extend a class if it is not abstract or virtual. Unlike in Java in Apex all classes are final by default. But you can use "composition (over inheritance)" and write something like this:

public with sharing class SomeClass {
    private Set<Object> objs;

    public SomeClass(Set<Object> objs) {
        this.objs = objs;
    }

    public Boolean retainAllIfPopulated(Set<Object> other) {
        return objs.size() > 0 ? objs.retainAll(other)
                               : objs.addAll(other);
    }
}

Part 1

Correct. You cannot "automatically" enforce field level security or profile permissions with "with sharing," as this would make code much more difficult to debug because of failures. This is noted in Using the with sharing or without sharing Keywords, under the second note.
Correct. This means that if do not specify "with sharing" or "without sharing" for the inner class, it behaves according to the calling class mode, or "without sharing" if called directly, except as noted in the first section of the link provided above.
Partially correct. If you run a class that has no sharing in Execute Anonymous, or in Chatter, it is treated as "with sharing." In all other cases, it is treated as "without sharing." For most cases, this is not significant, but you should be aware of this feature.
Correct. Extensions are basically a rewrite of the original class plus additional code, so they behave like the original class, including its sharing mode.
Correct. Calling a function in a class will use the sharing mode of that class, unless it is undefined, in which case the mode stays the same.

Part 2

Correct, as per 4 above.
Correct, as per 5 above.
Correct, as per 5 above.
Correct, as per 4 above.
Incorrect, as per 3 above. Because A has "with sharing", C will have "with sharing" when called from A.
Partially correct, or incorrect, depending on the exact definition of A. If A is "public with sharing class A extends C", then it is "with sharing," or if it is "public class A extends C", then it falls under item 3 from part 1 (that is, "without sharing unless executed from executeAnonymous").

With Sharing

This is when you're trying to perform an update as the user. If user X cannot edit record Y, then an error will occur. If user X cannot see record Y, they cannot query that record. Use this mode when for pages that should respect sharing settings, or any other time you might want to enforce the rules.

For example, a page that edits opportunities should probably enforce sharing to make sure that users can't modify other users' sales data without the appropriate sharing in place. For Visualforce pages, this is true approximately 99% of the time. Some Visualforce pages might be able to circumvent sharing, for example, to show data that the user wouldn't normally. A page that can tell users that a possible duplicate lead exists (without exposing who works the lead, or specific details) would not want to use "with sharing" in a private data model.

Without Sharing

This is when you're trying to perform an update that should not fail ordinarily. For example, a logging system is designed to write certain non-fatal messages to a logging object. The user doesn't have any right to edit the logging files normally (OWD is private, and the logging records are owned by a system administrator), but the logging files need to be queried and updated accordingly (to save space, etc). Using "with sharing" would make this code impossible, but by placing that code in a "without sharing" class, the code can make logs on behalf of the user even though that user has no access to the object normally. As another example, users can't see others leads, but the system needs to flag potential duplicates and notify someone that there is a duplicate. "Without sharing" makes this code possible.

[SalesForce] Maximum stack depth reached: 1001

I am confused as to what you are really trying to accomplish with this structure. You don't need to create any logic for the actual order of execution (which, correct me if I am wrong, it appears you are trying to do here). Triggers have a very specific order of execution. It will actually run through your trigger several times to hit before and after logic.

Wouldn't it be much easier to do something like:

trigger OpportunityTrigger on Opportunity (after insert, after update, before delete) {
    if(Trigger.isAfter && Trigger.isInsert){
        OpportunityHandler.createScheduleLines(Trigger.newMap);
    }

    if(Trigger.isAfter && Trigger.isUpdate){
        OpportunityHandler.adjustScheduleLines(Trigger.newMap, Trigger.oldMap);
    }

    if(Trigger.isBefore && Trigger.isDelete){
        OpportunityHandler.removeScheduleLines(Trigger.oldMap);
    }

}

public class OpportunityHandler{

    public static void createScheduleLines(Map<Id, Opportunity> newMap) {
        // logic
    }

    public static void adjustScheduleLines(Map<Id, Opportunity> newMap, Map<Id, Opportunity> oldMap) {
        // logic
    }

    public static void removeScheduleLines(Map<Id, Opportunity> oldMap) {
        // logic
    }

}

Let Salesforce worry about the order they are executed.

Best Answer

Related Solutions

[SalesForce] SFDC: Understanding With Sharing, Without Sharing & Unspecified Sharing Classes

Part 1

Part 2

With Sharing

Without Sharing

[SalesForce] Maximum stack depth reached: 1001

Related Topic