I am gladly punting the metaphor.

Chuck

When I “forgot” something an argument, a detail, … it’s easier to read than replay the video and find the right moment.

ppt2007 it’s ok for me. I can may be done a “pack” (PPT2007 + PDF)

Why? The reason I ask is that they are done in ppt 2007 and many people are still in 2003 or earlier. Would PDFs suffice…?

Is it possible to get your powerpoint files ? (same question for NHibernate)

Thanks,

Thanks for the quick/well-reasoned reply - I’m glad we agree!

I guess the only thing that I’d probably add at this point is that refactoring is definitely your friend, so whilst it is always worth thinking about the flexibilty of your design, it’s also worth remembering that you can refactor things later on too, i.e. if (when?) you realise it’s no longer appropriate.

Incidentally, slightly more pastel colours might be better!

This is a good point (the one about the over-architecting of things, not the one about the poor color scheme…well, ok the one about the bad color scheme is actually a good point too ).

I think that its entirely possible to go too far with some of the principles of OO design that I like to follow; for me that’s why I consider them to be ‘principles’ rather than ‘laws’. I use them to *guide* my work rather than *define* it.

That said, many if not all of the Agile approaches to software project management are *heavily* dependent on the ’suppleness’ of your solution design being able to change locally without affecting your solution globally. This is, after all, how one can actually get started coding before perfectly knowing every little detail of every little requirement beforehand.

I believe very strongly that when new req’ments surface (or existing ones are futher refined/clarified) in subesquent iterations, its the ability of your existing software to adapt to these in a very flexible manner that really enables the Agile approaches to work in the first place. Given this, its *generally* better to err on the side of over-flexibility rather than under-flexibility but I think you are 100% correct that this (like nearly all other design choices) is not without its downside if taken too far.

I once had a conversation with another of our developers where we were discussing this very issue (increasing complexity in the codebase to support future predicted changes) and I think that what this comes down to for me is that in any project there are those areas of the req’ments and spec that you feel are pretty solid (lower chance of a need to change) and those areas that you are less certain of (higher chance of a need to change) and that you focus in on 100% (well, as close as you can come to that) uncoupled code in those areas where you are less certain your design is ‘right’ and have some freedom to get less ‘perfect’ with your design in areas that you feel more ‘certain’ about the stability of the req’ments (and thus the ‘correctness’ of your code).

In times past, developers would tend to solve this “I just don’t know yet” problem by developing complex configuration subsystems that would let the code be ‘comtrolled’ by outside config files, a database, or whatever. I think to some degree, the intense focus on loosely-coupled systems represents another (and probably better) way to achieve the same kind of flexibility with a bit less effort than some massively-configurable business rules engine for example.

One of the very important Agile principles that supports this whole ‘not knowing everything before starting’ is the notion of delaying every decision in the system until the ‘last-responsible-moment’ and a lot of this complexity in the OO design is intended to support just that kind of capability.

In the upcoming series, we will definitely have the opportunity to watch me struggle thru exactly that very kind of challenge as I design and implement the solution, making constant trade-offs about what level of abstraction does or doesn’t make sense in different contexts.

I guess the comments I get will tell me if my choices are the same ones others would make

Just curious, but based on the discussion of the class design stuff at the end of the screencast, where do you tend to draw the line when it comes to SRP, IoC, LSP etc? In other words, do you think there’s such a thing as too much, as lots of interfaces and dependency injection results in too much complexity, which results in a different maintenance issue?

Oh, you’re right… The colour scheme on the new website is pretty scary! (still better than most stuff on myspace tho)