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 <[email protected]> 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


Reply via email to