ISBN Classes

[stahta01]

After reading this thread Book Program - Help Needed

I decided that designing classes to support ISBN would be a good learning experience for me in another try on learning OOP and C++.

Object Methods that make sense to me.
isValid Checks for valid ISBN mainly tests the last letter
isIsbn13 Checks if ISBN13 or ISBN10 return true for ISBN13

Operators that make sense to me
!=, ==, <, >, <=, or >=

Class name ISBN or Isbn which makes more since to the C++ world?

Support function that make sense to me.
checksum
checksum10
checksum13

Class properties
book_number // ISBN without the checksum
check_letter // The last letter of ISBN which should be the checksum
format_id // Somehow represents where the dashes should be in the ISBN

I decided to have getters for the three values book_number, check_letter, and format_id. But, not what to name them; and to wait on making setter because I am NOT sure it they will be needed except for the format_id property which I think will need a setter.
(I am also thinking about an toString method instead of format_id property.)
I can NOT think of anything more right now.
Maybe a test main function before doing more work.

Tim S.

[jiggunjer]

It seems regex might be used to validate the isbn. Is it going to be a string? Also what's this checksum stuff about?

[jimblumberg]

Also what's this checksum stuff about?

From the WIKI page the last digit is a checksum.

Jim

[vart]

It would be nice to have possibility to search for code entered on some site like ISBN 9781430242338 | Pro C# 5.0 and the .NET 4.5 Framework (Expert's Voice in .NET)
and display found information in readable format

[Elysia]

Object Methods that make sense to me.
isValid Checks for valid ISBN mainly tests the last letter

This doesn't make sense to me. You shouldn't be able to construct an instance of Isbn that's invalid. Although I would consider having a static method called IsValid in the class to be an acceptable design decision. Possible also a free function called IsValidIsbn(string).

isIsbn13 Checks if ISBN13 or ISBN10 return true for ISBN13

Operators that make sense to me
!=, ==, <, >, <=, or >=

Seems feasible, I guess.

Class name ISBN or Isbn which makes more since to the C++ world?

I'd really say that's developer preference, but in this case, the former might be a little troublesome as it's all capital (might collide with macros).

Support function that make sense to me.
checksum
checksum10
checksum13

I'm not sure why there are three checksum functions? I would expect to just have one. Either it's an ISBN-10 or ISBN-13, so it doesn't really make sense to expose different functions, does it? I can understand if they're private and the class choosing which one to call depending on the type of the ISBN, though.

Class properties
book_number // ISBN without the checksum
check_letter // The last letter of ISBN which should be the checksum
format_id // Somehow represents where the dashes should be in the ISBN

I decided to have getters for the three values book_number, check_letter, and format_id. But, not what to name them;

Seems like useful functions. Not sure what format_id is for, though. I imagine it's something distinguishing between ISBN-10 and ISBN-13?
Why would names be a problem? Wouldn't GetBookNumber, GetCheckLetter, GetFormatId suffice?

and to wait on making setter because I am NOT sure it they will be needed except for the format_id property which I think will need a setter.

I usually avoid setters since it makes it more difficult to ensure that all data is consistent. One can usually get away with initializing using the constructor and then ensuring the object is immutable (you can delay initialization with boost:ptional; a feature that, sadly, while scheduled for incorporation into the standard was pulled at the last minute). I'm not sure setting these properties makes sense. What is the purpose of the class? To wrap an existing ISBN or allow the creation of a new one? If it's the later, then perhaps having a constructor that takes these properties and fills in the check_letter might make sense.

(I am also thinking about an toString method instead of format_id property.)

Overload operator << for printing. That's the C++ way instead of toString which Java has only because it lacks operator overloading, I figure.

[stahta01]

I was going to use toString instead of the format ID.
It may NOT be obvious to people who does NOT read a lot or know more about ISBNs; but, the location of the dashes are NOT random or the same for all ISBNs.
I am hoping to find a list of ISBNs formats for the dashes; but, it appears to be set by each Book Publisher.
So, I am planing on using something like toString with a format type string to add back at least one of the dashes.

Tim S.

[jimblumberg]

I am hoping to find a list of ISBNs formats for the dashes; but, it appears to be set by each Book Publisher.

Yes the placement of the dashes vary by publisher the size of the publisher number. But I wouldn't get too worried about the dashes because they are only there for us humans. When searching for books you usually don't use any dashes.
From this link:

When printed, the ISBN is always preceded by the letters “ISBN”.
Note: In countries where the Latin alphabet is not used, an abbreviation in the characters of the local script may be used in addition to the Latin letters “ISBN”.

The ISBN is divided into five elements, three of them of variable length;
the first and last elements are of fixed length.

The elements must each be separated clearly by hyphens or spaces when displayed in human readable form:
ISBN 978-0-571-08989-5
or
ISBN 978 0 571 08989 5

Note: The use of hyphens or spaces has no lexical significance and is purely to enhance readability.

The number of digits in the second, third, and fourth elements of the ISBN (registration group element, registrant element, publication element) varies. The length of the registration group element and of the registrant element is relative to the anticipated publishing output of the registration group or registrant. When these elements are short in length it indicates that the output of the registration group or the registrant (or both) is expected to be a large number of publications.

I would recommend that you have a field for each part of this number: EAN, Group, Publisher, Title, and Check digit. ThI am hoping to find a list of ISBNs formats for the dashes; but, it appears to be set by each Book Publisher.en when you print the number use the dashes to separate the fields if so desired.

I'm not sure why there are three checksum functions?

I can understand two checksum functions, one for 13 digit numbers and one for 10 digit numbers since there are slight differences between the two. But I agree that they should probably be private functions, not public.

Jim

[phantomotap]

isValid Checks for valid ISBN mainly tests the last letter

O_o

I agree with Elysia regarding the construction of invalid objects.

You don't need a public `isValid` if you ensure the state can't become invalid.

isIsbn13 Checks if ISBN13 or ISBN10 return true for ISBN13

I think the check for the format is the wrong approach.

You should internally convert ISBN-10 format codes to ISBN-13 format codes.

You can then allow formatting as ISBN-10 for sake of presentation.

Support function that make sense to me.

You should use whatever support functions you find necessary, but you might wish to roll the generation for the digit into some utility allowing clients to pass either the required 9 or 12 digits.

I am hoping to find a list of ISBNs formats for the dashes; but, it appears to be set by each Book Publisher.

Nope. The standard is set by ISO and developed by International ISBN Agency and associated partners.

You can see the important bits at the standards site.

Let's look at a fragment of the XML tables.

<Group>
<Prefix>978-0</Prefix>
<Agency>English language</Agency>
<Rules>
<Rule>
<Range>0000000-1999999</Range>
<Length>2</Length>
</Rule>
<Rule>
<Range>2000000-6999999</Range>
<Length>3</Length>
</Rule>
<Rule>
<Range>7000000-8499999</Range>
<Length>4</Length>
</Rule>
<Rule>
<Range>8500000-8999999</Range>
<Length>5</Length>
</Rule>
<Rule>
<Range>9000000-9499999</Range>
<Length>6</Length>
</Rule>
<Rule>
<Range>9500000-9999999</Range>
<Length>7</Length>
</Rule>
</Rules>
</Group>

The book "The C++ Programming Language" has the ISBN-13 `9780321563842` for the current version.

We know the first grouping is fixed: "978-" or "979-".

We use the prefix to determine the second group.

<Prefix>978-0</Prefix>

The next digit, the "0" digit, matches the prefix in the standard fragment shown. (What a coincidence!) The grouping "978-0-" is thus known.

We need to return to the standard fragment for the next group.

<Rule>
<Range>2000000-6999999</Range>
<Length>3</Length>
</Rule>

The next digit(s), the "3" alone here is sufficient, to determine the next grouping. The grouping "978-0-321" is now known.

We know the last digit is a group. The grouping "978-0-321-?-2" is now known.

The remaining digits must then make the fourth group. The standard grouping is "978-0-321-56384-2" is for the chosen book.

I'd recommend the methods `std::string stringify()` and `std::string hyphenate()`, with your chosen names, to present the two standard displayed forms.

*shrug*

I just got done, relatively speaking, with ISBN formats because I wanted to attach lookup and pretty printing to a scanner.

Soma