Skip to content

Virtual vs. Abstract vs. Interface #2

@kw12301

Description

@kw12301

I'd love to learn more about why, when , and how to use these classes.

I am struggling with how to properly put all of these things together into a cohesive application.

The example I would think would be applicable for something like this would be the product2 object.

In our org, we have this object as well as the following that could all be considered a 'product'

  • Product2 (Salesforce Product)
  • Channel_Partner_Product_Catalog__c (Channel Partner Product)
  • HQ_Module__c (Any product published by our development team for use in Sales Operations. Comes from external License Manager with unique external Id)

These three items feed:

  • Pricebook Entries
  • Opportunity Line Items
    -Quote line Items
    -Contract Line Items
    -Order Items
    -TierModule__c (a custom object we have as an overlay on pricebooks for deploying tier based pricing strategy).

Even though they are all distinct objects, they are all really representing the same thing; a single product.

I think that some combination of these three classes can help me to streamline the management of all of this, but I keep getting lost in the details every time I try to begin to outline it.

Is this the right way to think about virtual vs. abstract vs. interface?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions