How would you slice out the concerns in this object, and what would you name the resulting objects?

task.cs

public class Task : ActiveRecord
{
  public string Name { get; set; }
  public int AssignedTo_UserId { get; set; }
  public DateTime DueOn { get; set; }
  
  public Task()
  {
    DueOn = DateTime.Now.AddDays(1);
  }

  override void AfterInsert()
  {
    Email.Send(AssignedTo_UserId, "New Task", "You have been assigned a new task");
  }
}

Since I live in the land of java, I would make Task an abstract class with the regular task-y stuff defined and then make some of the methods have to be defined in the child class. I don't know if I'd force an AfterInsert to be defined in every sub class, but perhaps I'd define an abstract "notifyOnCompletion" function that would have to be defined. I generally don't like going beyond one layer of subclass but you might define an intermediate subclass that overrides the notifyOnCompletion and does the email and then all tasks that need to email on completing just inherit from the intermediate class? It gets fuzzy because this is all abstract and not a clearly defined problem space.

But once you start getting into multiple levels of inheritance you start running into the "composition vs inheritance" argument. I don't think it's too far of a stretch to have Task -> EmailNotifierTask -> YourConcreteTaskThatRequiresEmailNotification, but anything beyond that and it might be time to rethink.

Thanks for the comments!

I would ordinarily balk at the very mention of inheritance and yell "COMPOSITION!" very loudly in your face. But oddly, I'm not completely sickened by what you say. But my concern, which is always my concern when dealing with re-use through inheritance, is what happens when our domain evolves such that we end up in a position of wanting multiple inheritance? That is, we have TaskConcernA : Task, and TaskConcernB : Task and now we want TaskConcernAB : Task. Inheritance is not a flexible way to slice and combine behaviors.

That's when you start writing in Scala and use traits :D

http://www.scala-lang.org/node/126