We have developed one batch apex functionality along with some complex operations on custom object - Comp_Invest_DOC_process__c. Now user asking us to develop exact same functionality on another new custom object with same fields(they said, nothing is different as of now, but may be some changes has come on newly created functionality).

I think creating same functionality on another custom object and rewriting the same code again, it will tends to duplication of code and not easy in maintenance. can anybody suggest some design I have to follow in future to avoid such a situations.

1 Answer 1


There is no support for composition or inheritance of SObjects.

Record types can sometimes be used instead: all possible fields are added to the SObject and subsets are presented (via different layouts) depending on the record type. All instances of the SObject have the same label, with the "Record Type" field presenting the different type names. But if this suits your needs it is very much a core platform feature.

Agreed that duplicating the code is a maintenance problem. If you do this, then you can use dynamic SOQL in your test class to avoid having to duplicate the tests for each SObject. You can cut and paste the .object files that the Force.com IDE makes available for each SObject to reduce copying errors. If there are only a few different SObjects I would take this approach.

You could move your complex logic to triggers and use methods such as SObject.get to access the data to keep the code independent of concrete SObjects. The shared code would be put into Apex classes and then the triggers for each new SObject type would delegate to those classes (so sharing the logic). But triggers are not a one for one replacement for formulas and can be hard to get right. I would only consider this approach if there were many different SObjects.

You must log in to answer this question.

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