# Using composition instead of inheritance

I have been using Entity Framework 6, AutoMapper, ASP.NET Web Api and hit a few problems along the way, each time it was recommended that I could change my code from Inheritance to use composition design instead. After the last problem, and since the software is in early stages, I thought I would try the composition method and see how it panned out. Now I know that composition can mean that you write out methods multiple times, unlike inheritance, but I understand the tradeoffs and I think it's fine, but I wonder if I have missed something here.

I have an EntityBaseService which was trying to deal with an object sometimes needing validation. Using inheritance I would have:

public interface IEntityBaseService<TEntity>
where TEntity : class, IEntityBase
{

}

public abstract class EntityBaseService<T> : IEntityBaseService<T>
where T : class, IEntityBase
{
protected IDataContext _context;
protected IValidator<T> _validator = null;

protected EntityBaseService(IDataContext context)
{
_context = context;
}

protected EntityBaseService(IDataContext context, IValidator<T> validator)
: this(context)
{
_validator = validator;
}

{
return await _context.Set<T>().ToListAsync();
}

{
return _context.Set<T>().Where(e => e.Id == id).FirstOrDefaultAsync();
}

{
if (_validator == null) throw new MissingFieldException("Validator does not exist for class " + t.GetType().ToString() + ". override method if no validation needed");
return _validator.ValidateAsync(t);
}

{
var results = await ValidateAsync(t);

if (!results.IsValid) {
throw new ValidationException(results.Errors);
}

if (_context.GetState(t) == EntityState.Detached)
{
}

return await _context.SaveChangesAsync();
}

public virtual async Task<int> UpdateAsync(T updated)
{
var results = await ValidateAsync(updated);

if (!results.IsValid)
{
throw new ValidationException(results.Errors);
}

if (_context.GetState(updated) == EntityState.Detached)
{
_context.SetState(updated, EntityState.Modified);
}

return await _context.SaveChangesAsync();
}

{
_context.SetState(t, EntityState.Deleted);

return _context.SaveChangesAsync();
}
}


And then another class, would inherit from this service, like so, with its own interface:

public interface IAttachmentService : IEntityBaseService<Attachment>
{
}

public class AttachmentService : EntityBaseService<Attachment>, IAttachmentService
{
public AttachmentService(IDataContext context, AttachmentValidator validator) : base(context, validator) { }

{
return await _context.Attachments
.Where(e => e.Id == id)
.Select(e => e.Data)
.FirstOrDefaultAsync();
}

}


As I said, a lot of methods I were overwriting (unlike this example). Trying composition, I have easily separated the logic of requiring validation and not, since I have now created a ValidationService, which can be added to an object that needs it:

public interface IEntityBaseService<T> where T : class, IEntityBase
{
IDataContext Context { get; }

}

public class EntityBaseService<T> where T : class, IEntityBase
{
protected IDataContext _context;

public IDataContext Context
{
get
{
return _context;
}
}

protected EntityBaseService(IDataContext context)
{
_context = context;
}

{
return await _context.Set<T>().ToListAsync();
}

{
return _context.Set<T>().Where(e => e.Id == id).FirstOrDefaultAsync();
}

{
if (_context.GetState(entity) == EntityState.Detached)
{
}

return await _context.SaveChangesAsync();
}

public virtual async Task<int> UpdateAsync(T entity)
{
if (_context.GetState(entity) == EntityState.Detached)
{
_context.SetState(entity, EntityState.Modified);
}

return await _context.SaveChangesAsync();
}

{
_context.SetState(entity, EntityState.Deleted);

return _context.SaveChangesAsync();
}
}


Validation Service, now separated:

public interface IValidationService<T> where T : class, IEntityBase
{

}

public class ValidationService<T> where T : class, IEntityBase
{
private EntityBaseService<T> _service;
private IValidator<T> _validator = null;

public ValidationService(EntityBaseService<T> service, IValidator<T> validator)
{
_service = service;
_validator = validator;
}

{
if (_validator == null) throw new MissingFieldException("Validator does not exist for class " + t.GetType().ToString() + ". override method if no validation needed");
return _validator.ValidateAsync(t);
}

{
var results = await ValidateAsync(t);

if (!results.IsValid)
{
throw new ValidationException(results.Errors);
}

}

public virtual async Task<int> UpdateAsync(T updated)
{
var results = await ValidateAsync(updated);

if (!results.IsValid)
{
throw new ValidationException(results.Errors);
}

return await _service.UpdateAsync(updated);
}
}


Now a service that "CAN" implement the methods I need, with the logic I require for that object can look like this:

public interface IAttachmentService
{

}

public class AttachmentService : IAttachmentService
{
private IEntityBaseService<Attachment> _service;
private IValidationService<Attachment> _validation;

public AttachmentService(IEntityBaseService<Attachment> service, IValidationService<Attachment> validation) {
_service = service;
_validation = validation;
}

{
return _service.GetAsync(id);
}

{
// custom code
return _service.Attachments.Where(e => e.Number > id).FirstOrDefaultAsync();
}

{
}

{
return _validation.UpdateAsync(entity);
}

{
return _service.DeleteAsync(entity);
}

}


Now is this right? I believe it is, but the inheritance part of my brain is saying that I need to somehow not have to create GetAsync, AddAsync, UpdateAsync etc in each object, but without doing so means that I cannot customize a function easily, without writing an override. Plus this all seems easily testable now, as I can test each service independently using a testing framework.

• I think that what's confusing you and smelling bad to me is that your AttachmentService is wrapping all the method calls from two classes that have different goals. Your class is composed of parts, and those parts do what they need to do. You can make those into public properties (or { get; private set; } if you prefer) and remove all the wrapping methods. – Magus Apr 16 '15 at 19:04
• Not sure i understand u? Isnt composition all about including classes in other classes? Can u give me example of how u would do it so i can understand more? – Gillardo Apr 16 '15 at 20:06
• It is about including instances of classes in other classes, but it isn't about duplicating the methods of children. I've answered with a simple demonstration. – Magus Apr 16 '15 at 20:43

One simple thing you could do to make things simpler and less repetitive, while staying more in line with the idea of composition is this:

public class AttachmentService
{
public IEntityBaseService<Attachment> EntityService { get; private set; }
public IValidationService<Attachment> ValidationService {get; private set; }

public AttachmentService(IEntityBaseService<Attachment> entityService, IValidationService<Attachment> validationService)
{
EntityService = entityService;
ValidationService = validationService;
}
}


What this means is that AttachmentService is now truly a composite. You don't need to create methods to wrap the parts' methods, because the parts' methods can be called directly. (Instead of attachmentService.GetAsync(3), you would now call attachmentService.EntityService.GetAsync(3), because the attachment service has no need to know what methods it's parts contain, just that it has parts)

Composition is not really about duplicating methods; done correctly, it results in far less code, and far simpler classes, because each class does only what it needs to do, and can be substituted for other implementations if needed.

• Its a fine line, and takes some discipline to keep the chaining from devolving into chaos, but I think you're right in this case. – RubberDuck Apr 16 '15 at 22:13
• @RubberDuck: Agreed. To clarify for the OP, if there is repetitive chaining at the next level up, I'd create methods on that level to do those simple chains. The only methods that really belong in this class are interactions between the two services or operations an AttachmentService itself can do - whatever those may be. – Magus Apr 16 '15 at 22:24
• Thanks for the example but a question. If i do not add an actual method for addasync which calls the validationservice.addasync method then i cannot force validation when an attachment is added because someone could use the entitybaseservice.addasync instead? – Gillardo Apr 17 '15 at 5:29
• @user2736022: Then what you have is a major design issue. Your services, which presumably do different things, appear to do the same thing. If they are not meant to both be used that way, they should not both provide that ability. You should read up on SOLID; the Wikipedia article does a very good job of explaining it, and it should help you considerably. – Magus Apr 17 '15 at 14:54
• Think your right, i have taken this too far. I think each service should of actually inherited from EntityBaseService, and ValidationService should be passed into each service that requires it. Thanks – Gillardo Apr 17 '15 at 15:32