Divinas wrote:Also something you should keep in mind is granularity: how complex should one component be, and how specific, and how generic: which brings you to two camps: the very small, very reusable components, that create huge dependency chains, or the bloated component that takes care of only one thing and can't really be reused anywhere.
You can actually get away with the small reusable components when you're doing general application development (not games).
If you use Dependency Injection, you can have a IoC container wire up all the dependencies for you. So when you say "I need a
Foo that depends on Bar and Baz", you just do something like Resolver.Resolve<Foo>() and it gives you a Foo that's all wired up.
Of course, in games this isn't always feasible because DI isn't cheap to do. Most application development can get away with it though.
Real example: I'm developing a web application in ASP.NET MVC3 and I set Ninject up as my dependency resolver. In my controllers
(stuff that passes data from the domain model to the view) I just tell them that I need something like an IEmailService, IAccountService,
etc in my constructors and it resolves them for me. Then I can happily just use the methods defined in the interfaces and have a fairly
loosely coupled system.
Everything is defined in terms of interfaces which say what functionality is required and it's extremely easy to swap out for a new component.
If my IAccountService maps to MyAccountService and I need to have it map to TheirAccountService, then I can just change one line of code in
my dependency resolver wiring code and it propagates through the whole system.
Of course, that's not really applicable for games because DI is fairly expensive compared to just calling new.