Conrad Weisert [Conrad Weisert] - Object-Oriented Computation in C++ and Java: A Practical Guide to Design Patterns for Object-Oriented Computing

This Appendix does not include exercises for which the answer is found on the companion Website www.dorsethouse.com/books/ooc.html, noted throughout the book. Nor does it answer questions that depend on unsettled controversies. Further insights from the author and from readers also may appear from time to time on the Website www.idinews.com.

1.4-1 C has no primitive data type for text data. The programmer was encouraged to think of a text data item as an array of single characters. On the other hand, PL/I, COBOL, and BASIC supported character strings as built-in types. An inexperienced programmer learning C or Java as his or her first language, therefore, tends to merge the notions of strings and arrays and might not recognize any use or need for text data as elementary data items.

1.4-3 The number of states is fixed or nearly so. Over the lifetime of an application, it is unlikely that more than one or two new states will be added, if any. Therefore, we can assign a permanent code to each state. On the other hand, the number of cities is unlimited. Not only dont we have a complete list of the ones that exist now, but also new ones are created regularly. Therefore, the list of possible values required for a discrete data item doesnt exist for cities.

1.6-1 The size of a numeric data item limits the range but doesnt define it. For example, a pension calculation might support a persons age in years up to 120. That would require three decimal digits, but 999 wouldnt be a valid value. In binary representation, that age would fit in 7 bits.

That tradition began when punched cards were a common storage or input medium, and positions (columns) were severely limited.

explore some of them in detail.

1.6-4 One of XMLs design goals was XML Documents must be human-legible, even though those documents are always computer-resident. That means that all data fields have to be charactersno 16- or 32-bit integers, no IEEE-standard floating-point numbers, no Boolean values. Thus, the natural internal and efficient representations of most numeric data in OOP cant be stored in an XML record.

That doesnt mean, of course, that we have to choose an external representation in XML, although thats usually the natural choice. But whatever character representation an XML record contains, its format, structure, and attributes will be visible to every user.

XML, therefore, is not only unsupportive of numeric objects and many other application domain data types, but seriously undermines the object paradigm. Programmers working on combined OOP/XML applications will have to negotiate sensible compromises.

1.6-5 First, we need to make the data private, most likely by changing the struct to a class. Then we must either

provide public accessor functions to retrieve the required date components

make the output stream insertion operator a friend of the Date class

1.6-8 Private internal representation is completely independent of the language or cultural environment. Any required internationalization, therefore, will be limited to stream I-O functionsfor example, operator>> or conversion routines such as toString()and will have no effect at all on client code that manipulates objects.

2.2-1 In Java, theres slightly more excuse for that style of programming than in C++. Because of the additional overhead Java imposes upon objects, manipulating primitive built-in types in Java is faster than manipulating objects. Java implementations should continue to improve in the future, so that difference is likely to become less significant.

In any object-oriented language, to ignore the object paradigm is to give up type safety, units-integrity, and future flexibility. Such programs will contain more bugs and will be more difficult to understand.

2.2-2 This unfortunately common technique undermines the object paradigm. The accessor functions are just surrogates for the floating-point numbers that a programmer would use in a non-object-oriented language. If the client program is aware of the unit of measure and other properties of the internal representation, then whats the benefit of object-orientation? In OOP, programmers dont think of the value of an object as something distinct from the object itself.

The practice is more common in Java than in C++ because Java doesnt support overloaded operators and many Java programmers are reluctant to use named functions instead.

A class for which the client is expected to extract and replace the member data using getters and setters is called a quasi class.

2.4-1 The compiler would try to instantiate the template for a*b even if there were no defined multiplication operator for b*a. In theory, the compiler might then recursively try to instantiate the template for b*a and so on, but we hope most compilers would detect the circularity and issue a meaningful diagnostic message.

for a discussion of the YAGNI (You Arent Going to Need It) principle.

2.4-4 C++ code relies on the comma operator, which Java doesnt support. In Java, wed code the last line as

: (t = power(x, n/2)) * t; // Even power

The embedded assignment will be done before the final multiplication. You couldnt depend on that technique, however, in C++, because the language doesnt require a left-to-right order of operand evaluation in expressions.

2.4-5 The function would still work if we removed the second base case (n==l), but a costly additional recursion would occur for this trivial but common situation.

2.4-6 The sequence of values of n is 35, 34, 17, 16, 8, 4, 2, 1, so n35 would require seven multiplications. Thats good, but a custom-tailored version could compute x35 in five multiplications by multiplying x5 (3 multiplications) by x7 (one more if you saved x2). Customizing for a particular constant integer exponent would rarely be worth the impact on program maintainability. Decomposing the exponent into prime factors (35 = 5 * 7) will suggest the opportunity, if one exists.

2.5-1 Although we could define the remaining names, such as x.lessThanOrEqual(y), they are even clumsier than the basic three. The client program can just apply the not operator !x.greaterThan(y). Most programmers would find the latter more readable.

2.5-2 The equals function inherited from Object doesnt return the result we need; it returns a reference to Object. Before the program can use that result, it must explicitly cast the reference to the desired type. Dozens of such casts would generate clutter and unnecessary repetition of knowledge that would impair code readability and maintainability. We still need to support the inherited version, however, to comply with a widespread Java convention.

The compareTo method of the Comparable interface provides a clumsy way of comparing two objects. Unlike our three comparison functions, it returns a three-way (-, 0, +) primitive result that the program then has to test. However, youll want to support the compareTo method if you expect to use various generic standard library classesthey may invoke it to compare two objects of an unknown (Comparable) class.

2.6-1 The most important advantage of the explicit table approach lies in the simplicity of testing. Assuming correct values in the table, if the function computes the right result for one argument value, it will compute the right result for all legitimate values. With the switch case approach, youd have to test the function for every possible value.