That isn't an inherent issue of composition though. You could say {...students(ajaxDb), ...teachers(ajaxDb)} to create an object that can handle both stude

That isn't an inherent issue of composition though. You could say {...students(ajaxDb), ...teachers(ajaxDb)} to create an object that can handle both students and teachers. Or you could say public class StudentsAndTeachers extends Students implements IStudents, ITeachers { private _teachers; public constructor(Database db, Teachers teachers) { super(db); _teachers = teachers; } public getTeacher(TeacherId teacherId) { return _teachers.getTeacher(teacherId); } } new StudentsAndTeachers(ajaxDb, new Teachers(ajaxDb)); It seems clear that the features of the language define what is verbose and what isn't verbose. Even the inheritance in the language that encourages inheritance is more verbose than the composition in the neutral language. (More likely, you wouldn't write this, but every example that is colloquial in inheritance is non-colloquial in composition. The composition oriented solution can be used cleanly with strong guarantees provided to its users; whereas all inheritance oriented solutions are so tacky and hard to use that you will demand a framework with dependency injection which half your team won't be able to understand and will have to treat as magical incantations.)