Interface hierarchy design for separate domains

Posted by jerzi on Programmers See other posts from Programmers or by jerzi
Published on 2014-05-05T10:09:14Z Indexed on 2014/06/06 15:41 UTC
Read the original article Hit count: 161

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 ...?

© Programmers or respective owner

Related posts about php

Related posts about object-oriented