11

I have a big Apex controller of a visual force page ,2500 lines of code, so i m wondering how can i separate implemented features in different module according to the topic.

DealRowEdit(Apex controller) will be splitted in PricingConvertion, ProductSelection modules.

I´m thinking to create a different class for each feature: 1 class "PricingConvertion" 2 class "ProductSelection" and then in DealRowEdit controller to call methods of the helper classes.

Am i right?

Do you have some reference to a force.com best practice to design modular programming? I haven´t found something about this.

Thanks in adavantage for any advice

1
  • 2
    You are right to break a big class up into several smaller (hopefully) more cohesive and testable classes. Applied to controllers, I've heard the term "thin controller" used for this. I'll be interested to see if there are any good Force.com specific references; otherwise the general body of knowledge about object orient programming applies to Apex.
    – Keith C
    Commented Aug 28, 2014 at 9:48

2 Answers 2

6

I instruct all my developers to design their Apex Classes using APEX SOC (Seperation of Conerns)

Excellent Engineer Articles Here:

https://developer.salesforce.com/page/Apex_Enterprise_Patterns_-_Separation_of_Concerns

1
  • 2
    Andy Fawcett, who wrote that article (who is a contributor here), also did a DF talk last year which can be found here: youtu.be/qlq46AEAlLI
    – pchittum
    Commented Sep 3, 2014 at 13:43
4

I attended this session at Dreamforce 2013 around how to use patterns such as Singleton, Strategy, sDecorator and Bulk State Transition. Coming from a Java background and being a disciple of the Gang of Four for a long time, having such equivalent Apex patterns was what I was wanted to have to segregate my controllers and triggers logically. The example code for these patterns is available here

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .