Should these concerns be separated into separate objects?
Posted
by
Lewis Bassett
on Programmers
See other posts from Programmers
or by Lewis Bassett
Published on 2012-05-10T06:56:00Z
Indexed on
2012/06/11
4:46 UTC
Read the original article
Hit count: 395
I have objects which implement the interface BroadcastInterface
, which represents a message that is to be broadcast to all users of a particular group. It has a setter and getter method for the Subject
and Body
properties, and an addRecipientRole()
method, which takes a given role and finds the contact token (e.g., an email address) for each user in the role and stores it. It then has a getContactTokens()
method.
BroadcastInterface
objects are passed to an object that implements BroadcasterInterface
. These objects are responsible for broadcasting a passed BroadcastInterface
object. For example, an EmailBroadcaster
implementation of the BroadcasterInterface
will take EmailBroadcast
objects and use the mailer services to email them out.
Now, depending on what BroadcasterInterface
implementation is used to broadcast, a different implementation of BroadcastInterface
is used by client code. The Single Responsibility Principle seems to suggest that I should have a separate BroadcastFactory
object, for creating BroadcastInterface
objects, depending on what BroadcasterInterface
implementation is used, as creating the BroadcastInterface
object is a different responsibility to broadcasting them.
But the class used for creating BroadcastInterface
objects depends on what implementation of BroadcasterInterface
is used to broadcast them. I think, because the knowledge of what method is used to send the broadcasts should only be configured once, the BroadcasterInterface
object should be responsible for providing new BroadcastInterface
objects.
Does the responsibility of “creating and broadcasting objects that implement the BroadcastInterface
interface” violate the Single Responsibility Principle?
(Because the contact token for sending the broadcast out to the users will differ depending on the way it is broadcasted, I need different broadcast classes—though client code will not be able to tell the difference.)
© Programmers or respective owner