How to encapsulate additional fields?

Question

I have around 200 classes. 5% of them are unique, 95% of them have properties

int CantonID
int EntityID
int MunicipalityID
// other fields

and around 70% of these 95% have

    int CantonID
    int EntityID
    int MunicipalityID
    int Year
    int Month
    //other fields

(other 30% of these 95% don't have year and month properties).

So what is best solution to approach this? My idea was:

these 5% of unique should be independent
remaining 95% will inherit BaseClass that have fields:

int CantonID
int EntityID
int MunicipalityID

but I am not sure what to do with Year and Month. I can't add them to BaseClass because 30% of them will inherit properties that they should not have, but I don't know how to encapsulate them. I was reading about builder design pattern, but I'm not 100% sure it is for this situation.

Piglet · Answer 1 · 2022-09-01T09:11:48.520

3

You don't need a common base class.

class A
{
  public int CantonID {get; set;}
  public int EntityID {get; set;}
  public int MunicipalityID {get; set;}
}

class B : A
{
  public int Year {get; set;}
  public int Month {get; set;}
}

B inherits all the members of A and adds Year and Month

edited Sep 01 '22 at 09:11

answered Sep 01 '22 at 09:00

Piglet

27,501
3
20
43

so class C will inherit A, and class D will inherit B? – Lube Sep 01 '22 at 09:10
what is class C and D? A and B solve your 30/70 problem. so your 200 classes will derive from the respective class A or B – Piglet Sep 01 '22 at 09:11
Class C will have fields from A plus some other unique fields, and Class D will have fields from A plus fields from B and plus other unique fields – Lube Sep 01 '22 at 09:13
if you have more stuff that is only common to subsets of your classes you'll need to add interfaces. – Piglet Sep 01 '22 at 09:15
I am not sure how you meant to do it via interface – Lube Sep 01 '22 at 09:51

score 1 · Answer 2 · answered Sep 01 '22 at 11:05

but I don't know how to encapsulate them

OOP and specifically encapsulation is about behavior, not "properties". Trying to apply these concepts to "properties" will always be strange and foreign to OOP.

Your api (i.e. your classes and method signatures) should instead deal with what these things do, instead of what they consist of. Since you say you have 200 classes full of properties, I'm not sure what you're modeling. What is the behavior that these things are supposed to support?

If you have that, create classes/method that specifically support that, regardless of properties. I know that may be completely different to what you're used to. I leave this here, just to note that there are other ways to think about this.

They are models that accept data from front, and then insert/update this data into db via handler. It's pretty big database (lot of tables), and these properties represent columns in tables. — Lube, Sep 01 '22 at 12:05

score 0 · Answer 3 · answered Sep 01 '22 at 09:16

As an alternative to inheritance, we can use composition:

class A
{
    public int CantonID { get; set; }
    public int EntityID { get; set; }
    public int MunicipalityID { get; set; }
}

class B
{
    private A _a;

    public B(A a)
    {
        _a = a;
    }

    public int Year { get; set; }
    public int Month { get; set; }
}

Read more about design principle prefer composition over inheritance

How to encapsulate additional fields?

3 Answers3