I have an entity (say E1) and some attributes associated with it. A similar entity (E2) say it has all the same attributes as the E1 but the only difference is the editing nature. The E1 is not editable and will not have any setters for its attribute. On the other hand, E2 is editable and will have setters. This kind editable nature is there because these both are a similar entities, as i said earlier, and the edit nature is restricted for E1 because we populate that types and are needed use case. As of now we have no plans of opening edit nature for E1.
I have a series of questions how should i proceed through.
- Should i write a class for E1 and then extend the E1 for E2 adding the editing functionality? (this will follow the Open-Close principle and Liskov's principle too)
- In case in future we provide the edit name only of E1 should i move the set name method to E1 from E2 (this breaks the open-close principle)
- If i follow an approach where E2 is the parent and E1 being its child and restricting the edit nature, it breaks the Liskov's principle.
- In case i take into Interface segregation principle and write a base class for both E1 and E2, and make them extend that base class. Then i write an interface for editable nature and make E2 extend the nature. This would go with the SOLID but think of the future case where the name is alone editable, how should i handle that? Write another interface for that functionality and keep implementing that?
I have no idea how to proceed further. Can someone throw light on how to handle such cases?
P.S. I am new to development