So now in the image the remnants from the old DelayScheduler have been cleaned up by making it abstract with several methods becoming "subclassResponsibility". Would it be a reasonable practice to group these in a protocol "subclass responsibility" to make it easier to determine what is needed for concrete subclasses? Or maybe append "subclass responsibility" to the original protocol of such methods? cheers -ben
On 19 Mar 2015, at 14:44, Ben Coman <btc@openInWorld.com> wrote:
So now in the image the remnants from the old DelayScheduler have been cleaned up by making it abstract with several methods becoming "subclassResponsibility".
Would it be a reasonable practice to group these in a protocol "subclass responsibility" to make it easier to determine what is needed for concrete subclasses? Or maybe append "subclass responsibility" to the original protocol of such methods?
no, normally this is not done⦠sometimes I wish we would have tags on methods instead of protocols. Then we could do both. Marcus
No. I wouldn't do that. You could list them in the implementation section of the class comment.
On 19 Mar 2015, at 14:44, Ben Coman <btc@openinworld.com> wrote:
So now in the image the remnants from the old DelayScheduler have been cleaned up by making it abstract with several methods becoming "subclassResponsibility".
Would it be a reasonable practice to group these in a protocol "subclass responsibility" to make it easier to determine what is needed for concrete subclasses? Or maybe append "subclass responsibility" to the original protocol of such methods?
cheers -ben
participants (3)
-
Ben Coman -
Marcus Denker -
Sven Van Caekenberghe