Ebook: Fundamentals of OOP and Data Structures in Java

After reading the first three chapters, I had to conclude that the book was too dated to use. Here are some of its problems:

(1) The book and previous reviewers speak of code that can be downloaded from the publisher's web site; the publisher no longer makes such downloads available.

(2) With respect to software design methodologies, the author embraces "design by contract" which was championed by Bertrand Meyer in 1997 in "Object-Oriented Software Construction." This approach has pretty much been left by the wayside, with "patterns" being the currently touted approach. The author also adheres to a design methodology which rigidly classifies object messages as being either commands (methods that change the internal state of the object) or queries (methods that report back on the object's internal state). When it was time to implement stacks, this rigid adherence put him in a quandry. Traditionally "popping" a stack results in both situtations: the topmost value is returned by the pop (like a query) and the internal state of the stack is changed (like a command). To adhere to the command/query dichotomy, the author made popping a two-process. "Pop" changes the internal state of the stack, storing the topmost element in an internal field and reducing the size of the stack by one. However in order to restrict popping to "command" status, the topmost value is not reported back to the invoking code. Instead the user has to issue a subsequent "query" requesting the value of the topmost element. This implementation is oblivious to the impact that such a two-step process would have in a threaded environment. If thread_2 issues a pop command after thread_1 pops, but prior to thread_1 querying for the topmost value, the topmost element would be lost forever.

(3) The author makes use of Java classes that have since been deprecated. For instance he uses the Vector class, which has been more or less replaced by ArrayList.

(4) The author's convention for naming methods isn't in line with the current, prevailing conventions. For "commands" he uses various action words followed by a noun which describes the field being impacted by the command. For "queries" he restricts the name to a noun or noun phrase which describes the field value that's being returned. However it is now more common to see "commands" named "setField()" and "queries" named "getField()". Many IDE's automatically create method names utilizing the "set" and "get" naming convention.

For these reasons, I can no longer recommend the book.