10

In practical terms it means using an custom (immutable) class over a string or some other primitive type.

Examples:

  1. Publishing: International Standard Book Number.
  2. Finance: International Securities Identification Number.

Advantages:

  1. Can ensure the format of an identifier.
  2. Becomes a first-class member of the model.

Disadvantages:

  1. Adds persistence friction (e.g. Entity Framework).
  2. More code.
Den
  • 4,827
  • 2
  • 32
  • 48
  • _Should you use a custom class?_ Sure. _Should you use them as IDs?_ Absolutely Not :) An ID with a business meaning would cause troubles along the way. – Songo Aug 21 '15 at 12:25
  • 2
    @Songo To me that's an argument that the IDs should have *value semantics*, but primitive types aren't the only types with value semantics, so that doesn't necessarily rule out classes imo. Feel free to post a competing answer though since I forgot to make that point. – Ixrec Aug 21 '15 at 12:29
  • 1
    An old question of mine touched on the subject with different opinions: http://programmers.stackexchange.com/questions/281827/should-we-define-types-for-everything I went with creating the types and continue to do so. – Ziv Sep 01 '15 at 08:26

2 Answers2

7

I would say go for it. I would argue that the advantages outweigh the disadvantages in this case. The extra code is likely to be pretty minimal and the persistence issue can be solved pretty easily be providing some sort of converter between your new Class and the type the database expects (I've never used Entity Framework but I know this is relatively painless in Hibernate).

One of the advantages you can get by defining your own class is that the compiler can ensure that any methods which want an ISBN or an ISIN will know at compile time if you try and pass in the wrong value. It will also be much harder to accidentally overwrite that field in your entity. We can avoid common errors like this entirely:

book.setAuthor(otherBook.getAuthorName());
book.setIsbn(otherBook.getAuthorName());
book.setPrice(otherBook.getPrice())

If ISBN is a class rather than a primitive type then the above code won't even compile, saving a lot of debugging time later.

Matt Watson
  • 171
  • 1
  • 6
6

If you can give the class enough useful functionality to justify the added complexity of not being a string, then do it. For identifiers like ISBN and ISIN, I suspect this is not the case.

For an identifier class to be useful, I'd expect it to look something like this:

class ISIN {
    fromCUSIP()
    fromRawISINString()
    toString(ISIN::FormatType)
    getExchange()
    getCountryCode()
    getLastFourDigits()
    getWhateverCode()
    ...
}

If instead it looks more like this:

class ISIN {
    getString()
    setString()
}

Then I'd ditch the class entirely, use regular strings everywhere, and make sure I consistently use "isin" in all the relevant variable names.

Note that in some languages, adding a new type has almost no "added complexity" in typical programs, in which case you'd be encouraged to create the new type even if it had no functionality at all. But this is not the case for most traditional OOP languages like C++.

Ixrec
  • 27,621
  • 15
  • 80
  • 87