The reason this fails is because the class is still has references to code in other classes. The process is tedious but by reincorporating the code that the compilation is complaining about you can get the class to recompile. You then go back and start taking/commenting out one section of code at a time and recompiling each step of the way so that the references get re-stablished.
I am sure this works !!!
First of all your code doesn't compile now. That explains a lot.
Secondly, in my opinion messing with polymorphism in static classes (wholly static as you said) is not a good design at all. I don't see any good reason (although there might be some) driven by design needs to do try to access static method with super
. But question is still interesting, so let's move on.
Third thing is, you use super
keyword to reference private member. It shouldn't be possible at all. Private is private. If it compiled somehow, that was certainly a bug.
Answering to point 1:
As I said, I can't see any reason to inherit from static class. Actually It's not even an inheritance, you can access public members of any other static class anyway like listed below. Moreover, it's not permitted now - when I tried to compile your code (and many of it's variations :) I get the Variable does not exist: this
error from line -1 (valuable clue!). Not surprisingly, the code like this works fine, and it doesn't grant any access to other private members:
public virtual class Fact_BaseFactory
{
public static void populateFieldNameToTypeMap(String objectName) { ... }
}
public class Fact_Account extends Fact_BaseFactory
{
static
{
Fact_BaseFactory.populateFieldNameToTypeMap('Account');
}
}
According to second question:
A)
This idea seems to be the way to go, I would just create some public method In the helper class and reuse the code within your factories. Not sure what you mean with violating DRY here.
B)
Composition instead of inheritance is good design in general based on my experience and it's also recommended by Head First "Design Patterns" book. I would stick to the A anyway, but it's a good question to ask on codereview.stackexchange.com
Best Answer
Yes, you are missing something. The
Apex Developer Guide
lays it out succinctly (emphasis mine):When you set
recordId = someVariable
you are setting it at theSuperClass
level. Paste this simple analogous script inExecute Anonymous
to demonstrate how extending a class works when manipulating member variables and methods (note that classes are virtual by default in that environment):So in your implementation, you can actually drop the override entirely. For example, you could implement it as follows: