Classes and Subclasses or alternative.

[Sm1tje]

Hi all,

I have the following 'issue': I want to create / update / retrieve BP relationships. My idea is to create a superclass with all general data for a relationship like Partner 1 & 2, type of relationship (employer-employee, husband-wife etc.). So far so good, but now it comes. All relationships have different attributes (created in CRM with Easy Enhancement Workbench, comparable to customer includes).

Does it make sense to create a subclass per relationship type, because based on that different logic has to be processed. Or put all these attributes, whether they belong to relationship type A, or B, in the same superclass?

Normally I would say the second option is better / more logical and put them all in ONE (super)class, but since every relationship is a specialization of the superclass due to all the different attributes, it would also make sense to create a new subclass for every relationship type. I actually want to avoid, using IF statement within the class (IF relationship A, ELSEIF relationship B, etc.), because when creating a new relationship type, I would have to change the superclass over and over again.

Thanks,

Micky.

[matt]

> because when creating a new relationship type, I would have to change the superclass over and over again.

That's your answer. Changing the superclass over and over would seem like a bad thing!

The other solution would be to use an interface instead of subclassing.

[Sm1tje]

So what you're saying is create a new subclass for every new relationship type and use that, right?

The alternative would be to use an interface. Can you elaborate on that, because it sounds like an interesting option.

Thanks.

Micky.

[narin_nandivada3]

Hi Micky,

Create and interface with skeleton that you decided for SUBCLASS and inherit that interface and implement

as in the way in the inherited subclass.

Good luck

Narin

[matt]

As I understand it, you've got common methods, but the implementations are all different. Define the common methods in an interface, and implement those methods in the different classes.

Interfaces are good for relating classes that have something in common, but are not strictly heirarchical. Subclassing works best where you can say "subclass A 'is a' class B". E.g. billing document (subclass) "is a" document (superclass). if your relationships follow this "is a" concept, then use subclassing.

matt

[Sm1tje]

Hi Matt,

thanks againg for the reply. Just to make sure you understand it, this is the case.

I want to create a superclass with all standard attributes for a BP relationship like start- and end date, Business partner 1 and Business partner 2 (BP that have a relationship).

Next I want to create a subclass / or interface (or even both?), but I'm not quite sure which one would be the better option.

So what I can do is create a new subclass per relationship type (like Is parent of, is married to, is working at etc.). Depending on the subclass the processing is done, so every subclass will have general methods inherited from the superclass, and specific methods per relationship. Or would it be better to create ONE subclass for all relationships and use an interface in which the specific methods are defined?

When I look at it, then I can use the 'analogy': Subclass B (relationship X) is a Relationship (Superclass). This is true for every subclass which indeed is a relationship of a certain type. Hope this makes sense.

Kind regards,

Micky.

[matt]

If you've general methods, then subclassing.

There is a school of thought, however, that all public methods should be implementations of an interface - this is known as coding to an interface. It can, give more flexibility, at the expense of greater complexity.