> I would be über-pissed to trace thru code like this only to find all of these wrapper classes.
Why? I think this code is better; to demonstrate why, I'll deconstruct the first example -- names.
Names aren't strings. Names are multi-component entities comprised of strings with rather complex internationalization rules regarding composition.
To properly represent a name, you need the set of fields that compose the name, along with a 'full name' (historically in x.500 and LDAP this is called the 'commonName') that is pre-composed according to the users preference.
Some of the individual components you'll need if you wish to compose names:
- Surname [may be more than one]
- Middle name [may be more than one]
- Given name [may be more than one]
- Prefix (title, etc) [may be more than one]
- Suffix (IIrd, etc) [may be more than one]
- Nick name
The rules for composition can be complicated, so you'll want to centralize them somewhere. Also, you may not want to build a super-complex name class now, but later you might need to start sending out e-mails with "Mr. Psuedonym" at the top.
So how do you handle this?
CREATE A CLASS.
Names aren't strings. Most things aren't strings, though they may be represented as strings. Create a class now and make it easy to extend types later.
Treating everything as strings and ints throws away more than just the type system -- it throws away much of the code maintenance value of OO!
That's just names. His example also uses file paths, and file paths are actually quite similar to names; they're composed of multiple components, they have very specific rules regarding composition and normalization, and unlike names, you can easily introduce security issues by incorrectly handling file paths (eg, failure to correctly normalize a path before applying security checks).
This is why we create File classes that handle normalization/composition/decomposition of path names. As a side effect, it also helps constrain the types of your method calls.
Personally, I'm "über-pissed" when I trace through code that uses raw "string & int programming" and does not properly leverage types. It makes for messy code that does not properly take advantage of OO encapsulation and is difficult to read, difficult to type-check, is difficult to maintain, and even more difficult to build on.
Why? I think this code is better; to demonstrate why, I'll deconstruct the first example -- names.
Names aren't strings. Names are multi-component entities comprised of strings with rather complex internationalization rules regarding composition.
To properly represent a name, you need the set of fields that compose the name, along with a 'full name' (historically in x.500 and LDAP this is called the 'commonName') that is pre-composed according to the users preference.
Some of the individual components you'll need if you wish to compose names:
- Surname [may be more than one]
- Middle name [may be more than one]
- Given name [may be more than one]
- Prefix (title, etc) [may be more than one]
- Suffix (IIrd, etc) [may be more than one]
- Nick name
The rules for composition can be complicated, so you'll want to centralize them somewhere. Also, you may not want to build a super-complex name class now, but later you might need to start sending out e-mails with "Mr. Psuedonym" at the top.
So how do you handle this?
CREATE A CLASS.
Names aren't strings. Most things aren't strings, though they may be represented as strings. Create a class now and make it easy to extend types later.
Treating everything as strings and ints throws away more than just the type system -- it throws away much of the code maintenance value of OO!
That's just names. His example also uses file paths, and file paths are actually quite similar to names; they're composed of multiple components, they have very specific rules regarding composition and normalization, and unlike names, you can easily introduce security issues by incorrectly handling file paths (eg, failure to correctly normalize a path before applying security checks).
This is why we create File classes that handle normalization/composition/decomposition of path names. As a side effect, it also helps constrain the types of your method calls.
Personally, I'm "über-pissed" when I trace through code that uses raw "string & int programming" and does not properly leverage types. It makes for messy code that does not properly take advantage of OO encapsulation and is difficult to read, difficult to type-check, is difficult to maintain, and even more difficult to build on.