I had kind of heard of the rumors that ABC was going to sweep the Emmy awards, but I didn't pay much attention to it because the show that was gaining them all (Desperate House Wives), doesn't really appeal to me. However, tonight I watched Lost (the season premiere, greetings to Sanchez for getting me hooked on it), then after that I watched the season premiere of Invasion. Lost was tons better, but probably because last season ended on a cliff hanger. Invasion has potential as well. Lost may just be enough to hold my attention until 24 premieres in January.
24 may just be the only show that Fox hasn't screwed up yet.... Simpsons is hardly worth watching and Family Guy just isn't funny. I can watch the old episodes on Adult Swim and laugh, but the new episodes just don't do it for me.... American Dad on the other hand seems to be getting funnier lately.
Lately my time at work has been somewhat consumed by analyzing one of the other guy's designs and commenting on them. Much of the time 'discussion' breaks out about various design elements. This afternoon was consumed by the discussion of making a Report object an actual object over making a Report interface. My argument was, why make a class when you don't need a class, his argument was... why not make a class? We seem to have different views, his view is if you're going to go oO, go oO all the way. My view is pick the appropriate tool for the job and I am somewhat offended that my utilitarian view is attributed to my apparent lack of oO design experience.... pfft. Maybe, but I doubt it. I think its more driven by my inert lazyness and hatred of reinventing the wheel. So for my own reference, I've come upon ten good reasons to use oO (written from the perspective of a PERL guy, so take it with a grain of salt!)
-
Design is large, or is likely to become large
-
When data is aggregated into obvious structures, especially if there's a lot of data in each aggregate
-
When types of data form a natural hierarchy that lets us use inheritance.
-
When operations on data varies on data type
-
When it's likely you'll have to add data types later
-
When interactions between data is best shown by operators
-
When implementation of components is likely to change, especially in the same program
-
When the system design is already object-oriented
-
When huge numbers of clients use your code
-
When you have a piece of data on which many different operations are applied
Does his report thing fit in one of these rules? Unfortunately, it probably fits in all of these rules. At work, I've been introduced to the 80% rule. If your implementation works, you automatically get 80%. Thus, far in my life I've been following the 80-20 rule, meaning the 20% of time that I'm right, its vital, but the 80% I'm wrong, its trivial. So does this instance fall into the 80 or the 20? I'll let you decide that one.