Thanks guys. This is all pretty deep for me as I am almost completely self taught when it comes to this type of thing. I think the reason why I am leaning towards the inheritance approach is that a lot of the variables are referenced from many different methods. If these methods where dispersed across many different classes I think this could make things a little too complex. The sub class can refer to variables in the the super class as if they where in the sub class so very few syntax changes would be required.

Here is some additional info on how this class behaves. This is a forecasting app.

The constructor in this class does a lot of work. Traversing hierarchies, building hierarchies, query opps, does calculations, and sets some defaults. This is probably around 30% of the code in the class. I'm thinking I could store all of the variables, initial functions, utility type functions, and wrapper classes in the super class.

Then in the sub class I could add all of the methods that reference the variables with some type of user action from the page; saves, actions, etc. This way these functions could access the variables in the super class with no syntax changes and should be quite easy to re-architect. It will also reduce the size of each class and theoretically I think I would be able to split the code 50/50 between the two classes.

I must admit this probably isn't the way inheritance was specifically designed to be used but I think it may work best in my case. Thoughts?

I think in this case I'd favor using extension classes over inheritance.  I only like to use inheritance when I see myself re-using the super class for multiple objects.  A great example is the super class I wrote for dependent picklists.  It uses a super class that can work with a sub class that sets the table name to use, and has the ability to add filters to the query and such.  I use it for multiple dependent picklists so I am okay with it being a super class.

For a case management system I wrote where I in my noobish ways wrote my own custom controller for (never again, always use standard when you can), I started running out of space and wanted to clear this intense class up.  My method there was to use extension classes to add new features, and if they needed to communicate backwards I stored a reference to the controller from the constructor.  Then whenever you need to open something to an extension you make a public getter object.  Example below:

<apex:page controller="ExampleController" extensions="FeatureExtension">
<apex:form id="inputForm">
<apex:outputText value="{!widget1}"/><br/>
<apex:outputText value="{!widget2}"/><br/><br/>

<apex:commandButton value="change in controller" action="{!changeWidget}" rerender="inputForm"/>

<br/>

<apex:commandButton value="change in extension" action="{!changeWidget2}" rerender="inputForm"/>

</apex:form>
</apex:page>



public class ExampleController {
public ExampleController() {
this.widget1 = 'Initialized in controller';
}


private FeatureExtension featureExtension;

public void setFeatureExtension(FeatureExtension e) {
this.featureExtension = e;
}

public String widget1 { get; set; }
public void changeWidget() {
this.widget1 = this.featureExtension.widget2 = 'Changed from controller';
}

}


public class FeatureExtension {
public FeatureExtension(ExampleController controller) {
this.controller = controller;
this.controller.setFeatureExtension(this);
this.widget2 = this.controller.widget1;
}

private ExampleController controller;

public String widget2 { get; set; }

public void changeWidget2() {
this.controller.widget1 = this.widget2 = 'Changed from extension class';
}

}

Although after drafting that entire thing up I could see a good use for a super class here that handles the storage of the extensions in the main controller, but thats another post entirely.

-Richard

Thanks Richard,

I think if I was building something from scratch I may use this approach. I simply fear that there will be way too many syntax, getter, and setter changes required.

The reason I like the inheritance/extends approach, while not conventional, is that it will be dead simple to implement. Probably less than 10 minutes. Simply copy and paste a few methods from the super class to sub class.

Very true, my goal was to getting away from my main controller so I took this approach and slowly phased that controller out.  In your case you have to have a custom controller and are pretty much stuck with it.

-Richard

Great discussion, thanks for starting it Jason.

First I want to clarify a suspicion by garyb, there is no limit around the depth of an inheritance structure. I myself have a project that utilizes 3 levels and know there is no documented limit so if you hit one there is something we need to fix :)   There is a limit, however, with trigger execution depth common only in use of the term "depth" but aside from that it's completely unrelated.

Interfaces and composition are better in many ways as the "has a" relationship is argubaly less brittle than the "is a" relationship between two classes.   The more intimate one is with the code the less important that brittleness becomes, IMHO.  Take the mix-in pattern we applied to Visualforce controller extension as an example of this. An approach which you may also look to leverage as this is supported with custom controllers too, not just standard.

I know I sent you down this path with my tweet in reaction to hitting this limit (without knowing your use case) but garyb has presented the alternative I might suggest as well - break up the page into components, each with their own fraction of the controller. In this case you would probably want to break up the current controller into the pure model elements (shape) and then partition the methods into component controller actions.

The one thing most of these design patterns have in common is the logical breaking up of code into smaller, more succinct units. How you combine them is in some ways dependent on style but also a matter of practicality and requirements.

One more thing you could do pretty easily is to take the "inner" out of your inner classes. ;-)