0

I have multiple classes that have the same properties to be exposed. Is it normal to create a base class, which will expose those properties, to be used with descendent classes?

By properties I consider plain

protected/public bool SomeProperty {get;set;}

but also a complex property that is being injected through constructor

public SomeBaseClass(ISomeDependency dependency)
{
    _dependency = dependency;
}

This means that this base class could be just a dumb container, nothing else.

Is this approach correct?

  • 1
    Whilst this is in some respects an abstract OO question, implementation language will have a bearing. C# for example does not support multiple inheritance so having something that abstract in a base class could be somewhat limiting. – Robbie Dee Jul 25 '18 at 9:12
  • 1
    How would you name your base class for real? If it is going to be CommonProperties, it is not the way to go. If you could include a domain specific generalization in it, like ClientNotification or ThingWeSell, it could make a lot more sense to have that base class. – Martin Maat Jul 25 '18 at 18:49
  • @MartinMaat Yes, it will have a meaningful domain name – Goran Jul 26 '18 at 10:05
  • @ This class will be inherited by some other super class, so there will be no need to inherit from two clases (C# is being used). – Goran Jul 26 '18 at 10:06
5

Yes its 'normal', whether it's correct or not is a harder question to answer.

You should use inheritance where objects are conceptually a modification of a base type. Not just because they happen to have the same property names.

eg:

class Pet
{
    public string Name {get;set;}
}

good:

class Kitten : Pet

bad :

class Employee : Pet

The danger with the second approach is that you end up with a huge long inheritance chain which becomes impossible to manage. eg

HasNameAndAddress : Pet
{
    public Address Address {get;set;}
}

Customer : NameAndAddress {}

House : HasAddressButNoName {}
  • Agreed. The key is whether two two classes that may share a common base have something conceptually in common, where you might want to treat them all generically. Like in the example above, vector<Pet*> makes sense, but it would be a mistake to add an employee to it, so it shouldn't be a subclass of Pet. – Lewis Pringle Jul 25 '18 at 13:26
0

If all your derived classes require the same properties, then consider creating a bean class (a class with no business logic which only holds information) and making your base class only contain a setter and getter with that information.

public class Bean {
    public bool SomePropertyA {get;set;}
    public bool SomePropertyB {get;set;}
    public bool SomePropertyC {get;set;}
}

public class SomeBaseClass {
    protected Bean SomeBean {get; set}
}

Alternatively you could take this a step further and keep the instance of Bean private, passing it to overridden methods:

public abstract class SomeBaseClass {
    public SomeBaseClass(Bean bean) {
        SomeBean = bean;
    }

    private Bean SomeBean {get; set}

    public void DoSomething() {
        DoSomethingInner(SomeBean);
    }

    protected abstract void DoSomethingInner(Bean beanInstance);
}

This second approach may be particularly useful if your class is being created in a factory (and therefore separating its creation from how it is being used in your program).

  • 1
    Anemic domain models have been viewed pejoratively in some quarters but the simple reality is they do occur and are on occasion useful. It is always worth considering whether you actually do have an anti-pattern on your hands when you find yourself separating the logic from the data. – Robbie Dee Jul 25 '18 at 10:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.