Interface hierarchy design for separate domains
- by jerzi
There are businesses and people. People could be liked and businesses could be commented on:
class Like
class Comment
class Person implements iLikeTarget
class Business implements iCommentTarget
Likes and comments are performed by a user(person) so they are authored:
class Like implements iAuthored
class Comment implements iAuthored
People's like could also be used in their history:
class history
class Like implements iAuthored, iHistoryTarget
Now, a smart developer comes and says each history is attached to a user so history should be authored:
interface iHistoryTarget extends iAuthored
so it could be removed from class Like:
class Person implements iLikeTarget
class Business implements iCommentTarget
class Like implements iHistoryTarget
class Comment implements iAuthored
class history
interface iHistoryTarget extends iAuthored
Here, another smart guy comes with a question: How could I capture the Authored fact in Like and Comment classes? He may knows nothing about history concept in the project.
By scalling these kind of functionallities, interfaces may goes to their encapsulated types which cause more type strength, on the other hand explicitness suffered and also code end users will face much pain to process.
So here is the question:
Should I encapsulate those dependant types to their parent types (interface hierarchies) or not or explicitly repeat each type for every single level of my type system or ...?
