Jason Salas' WebLog

I'd love to comment, except all I get is a blank page.

It works here, but it's power-point-ish and I didn't make it past the third slide. I don't know that I've ever seen a PowerPoint presentation that was worth posting online without audio.

Hi Shannon,

You should try the other slides...the good stuff kicks in after the 5th slide...some interesting architectural approaches used.

I find it insulting when people post their presentation outline like this. PowerPoint slides are rarely more than headlines for sections of a talk. If this were actually "a presentation", then the person who gave this did nothing more than read these words, right? Well, I'm willing to bet that he said a lot more than what is posted there.
I see no difference than this and someone scanning and posting a handful of 3x5 notecards they listed the key points of their speech on and claiming they posted their speech online.
The outline you linked to does look like it could be an interesting one-page document if it were a single Word.doc or html page and wasn't confined to bullet points and the over-sized "see jane run" paradigm.
PowerPoint is fine when a presenter is speaking to a room full of people and wants them to see his notes in big bold letters in order to reinforce the ideas, but that just doesn't carry over into any other area for me. "Dick and Jane" books only had a few big words on each page but they at least had illustrations.


Darren: The page is IE only, other browser get a blank white page. That may be the problem you're having.

The most interesting thing about OOP is that it allows for a high degree of re-use. The most interesting thing about most OOP code is that it is never re-used.

Jason did a good job putting this together. I really like reading this kind of stuff…

I could be critical, perhaps, of 2 of the design patterns covered, however...

** Single Responsibility Principal **

I don’t like the limitation of 1 responsibility per object. I view objects as a collection of cohesive responsibilities. Moreover, an object can have hundreds of responsibilities as long they are cohesive, and we don’t have overriding reasons to decouple them. I believe following this principal can lead to an anti-pattern (whose name escapes me! I think – “Ghost”) which refers to systems made up of 100s of tiny objects which, while flexible (in a pick & choose way), do not provide any type of easy-to-consume façade.

Now, as far as you example goes… I would agree that the serialization of the object should not be a responsibility of the customer. Not because a customer object shouldn’t know how to serialize itself, but because by decoupling this responsibility we could address serialization in a generic way that could benefit all our business classes (not just Customer).

You know what, though? Some of my differences may be about semantics… I think the “packages” you describe are the “façade” that wraps together your single-responsibilty classes… So I think you have built into your process a solution to the anti-pattern I describe above… certainly, I can see some advantages.


** Open-Closed Principle **

I don’t really agree with the use of inheritance as it was demonstrated in the “Open-Close Principal – Refactored”. That is, I don’t agree with the reasoning cited for promoting Customer to a base class.

I would suggest that “fear of breaking the original class” is almost never a good reason to introduce inheritance.

Perhaps, an intermediate developer working on an unfamiliar, and very mature system – might have reason to make such a move. I think the question to ask is, “if I knew about Loyalty points when I first designed this system, would I have made customer a base class?” If the answer is no --- then you should not refactor it in this way to support your new requirements.

What happens when you have a new requirement for a “Preferred” customer? Do we now have classes like: Customer, LoyaltySchemeCustomer, PreferredCustomer, and PreferredLoyaltySchemeCustomer?

Now, don’t get me wrong – this set of classes might be completely appropriate – for example, if the responsibilities of a “preferred” class were so fat they really needed to be separated.

However, I would suggest here that fear of breaking the original class has resulted in an inheritance scheme which may not be appropriate – and may have resulted in a less adaptable and more error-prone system.

To summarize, I just think that inheritance is often an over-used “hammer” – I would think twice about introducing it, unless an original design (based on current knowledge) would have used it as well.

Just my 2 cents... enjoyed the document.

I enjoyed the document. Refactoring is one thing that is beginning to interest me. It seems to help make code cleaner and more maintainable.

Some of these comments here seem to be criticisms of PowerPoint rather than the material itself. I had no problem at all following the content and the examples, and can't see why you would need someone to actually stand up and talk about the slides. They look pretty self-explanatory to me.

If you look at the UML tutorials on the same site you'll see very few bullet points and lots of diagrams and sample code. I suspect Jason's avoided using UML here because he doesn't think a lot of .NET developers will know it - not that they need to understand design principles or refactoring.

The OCL tutorial and UML for Customers is good stuff :-) Never seen anything like that before. The advanced stuff like Test-driven Analysis & Design is a new idea, too, I think.

I agree. I found these very useful.