Bookmarked, to think about it. And thanks!

I'm in UML classes right now (I know, bad student, no cookie).

It's kinda interesting -- instructor hates both waterfall development and the procedural approach. I think that spiral/iterative development is cool, but that the procedural approach is nowhere as inherently flawed as he states.

Question about abstraction. Given this example:

object employee{
property name is a textstring;
property age is an integer;
property numberofPets is an integer;
property isBald is a boolean;
}

He contends that this is a bad abstraction and that numberofPets and isBald should be removed. I think that it's entirely dependent on the application that's being modelled. He also says that name and age are too general, and should be replaced by lastName, firstName and dateofBirth. Again, I think it's way too problem domain-dependent to be a useful question, but also if you change name to lastName and firstName you don't end up with anything that much more unique than before, and who cares? If you can't guarantee uniqueness, why bother leaning vaguely in that direction?

Plus, I don't think HR apps should have age, period. So there.

I think that (depending on the app, as you say) there should be a collection of pets. I don't have a problem with isBald. lastName is way way way WAY too culturally-specific. You're going to run into a lot of problems if you change the modeling in that way.

You're going to run into a lot of problems if you change the modeling in that way.

Good point! I wish I'd thought of that when I was getting in his face. A coworker of mine whose name is lastname firstname someothername and who goes by a dim of firstname sure had a huge problem getting her ID card and other paperwork making any sense.

Well, age depends on both the current date and the date of birth. i.e. it will become more error-full as time goes on.

Also, from a database design standpoint you'd want first and last names in separate fields, just to avoid problems of trying to parse them into separate fields down the road. Is that similar to what he's getting at?

Yip. I go by my second name, and I took to filling out forms as if that were my first name, because otherwise everybody calls me "Ann". (I moved my maiden name up into the middle spot.)

My company has tons of people whose name is Chan Wu, but everybody calls them Charlie. Not to mention all the Indian developers who say "My name is Lotsasyllables Sudhar , but you can't pronounce Lotsasyllables, so call me Sudhar."

His point about the age was that it wasn't unique enough. There's no such thing as unique enough! DoB is more rarely duplicated, but it still will be. So no primary keyness there.

from a database design standpoint you'd want first and last names in separate fields

Absolutely. But this is just an object model -- its relationship to the actual storage is outside of the scope of the class. We're just going as far as conceptual design.

The idea of shifting something to make it "more unique" without making it actually unique is odd, especially under the guise of furthering abstraction.

OH, he thinks the DOB is a unique identifier? He is on teh crack.

There's a REASON most databases let you generate unique IDs. They're really rare in the domain space, and NO, SSN isn't.

If I have my Tivo connected to the cable box and tv, but not to either a phone line or a broadband connection for a few weeks, what happens?

You won't get program schedule updates, so you'll have to set things to record manually.