GeeCON Prague 2014*
The moose likes Beginning Java and the fly likes Just Java Chapter-6: Why not cover all static data/methods/blocks/classes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Just Java Chapter-6: Why not cover all static data/methods/blocks/classes" Watch "Just Java Chapter-6: Why not cover all static data/methods/blocks/classes" New topic
Author

Just Java Chapter-6: Why not cover all static data/methods/blocks/classes

Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
On Page 114 of the sample chapter-6, I saw that Static Blocks and Static Classes will be discussed in other chapters... I just would like to know where they will be in the later chapters? I can guess that Static Classes would be in Chapter-12(Nested classes), but I can't find into which chapter Static Blocks topic can be fitted... Could you clarify a bit the reason(if there is) why you didn't try to cover all static data, static methods, static blocks and static classes into chapter-6, which is titiled as Static, Final and Enumeration Types?

If there is no particular reasons, it doesn't matter... I just would like to get to know about your writing style and technique... Thanks a lot...


Co-author of SCMAD Exam Guide, Author of JMADPlus
SCJP1.2, CCNA, SCWCD1.4, SCBCD1.3, SCMAD1.0, SCJA1.0, SCJP6.0
Peter van der Linden
author
Ranch Hand

Joined: Sep 28, 2004
Posts: 46
Could you clarify a bit the reason(if there is) why you didn't try to cover all static data, static methods, static blocks and static classes into chapter-6, which is titiled as Static, Final and Enumeration Types?


Hi Ko Ko,

You raise a good point here, which is "how does a writer decide what to cover in a chapter"?

The answer is that it is a tradeoff with many competing elements. The two starting points
are that you know there is some amount of material relating to topic A that you want to cover.
And you know that readers cannot tolerate a chapter longer than a certain length, no matter
how interesting you try to make it.

So those represent the boundaries for the material - one pushing to get more in, and the
other pushing to keep it smaller and more manageable.

The chapters before this one cover most of the other elements in the Java type system, so I
knew that it was time to introduce enums. However, I had not covered static or final yet.
And since enums are final static objects, that was absolutely necessary groundwork, and in fact
a logical place to put them.

However, I certainly didn't want to bring in all the other uses of static too, like static imports,
static blocks, and static classes. They are not necessary to understand enums, and they
would balloon the chapter up in size. So you make a deliberate decision to postpone that
part of static, and just deal with the things people need to understand enums.

Every writer makes this kind of tradeoff (though they all make different decisions about
what to split off and to where). One of the ways to judge a book is to look not only at
what it covers, but also at how consistently it covers it, and in what order. Whenever I look
at a new programming language book, one of the first things I look for is an explanation of
associativity (assuming the language uses associativity to parse its expressions). This is a
topic that is often poorly understood and poorly explained. But it is *essential* for a proper
understanding of how expressions are evaluated. Try it! Pick up your favorite programming
book (not just Jave book) and look for the description of associativity!

Cheers,

Peter


Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0131482114/ref=jranch-20" target="_blank" rel="nofollow">Just Java(TM) 2 (6th Edition)</a>
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
Thanks a lot for your kind explanation about the technique of technical books writers... It's very knowledgable and I hope others also will benefit from this thread...

Are the rest of Static Imports, blocks and classes dicussed in Nested Classes chapter of the book? But the new feature of Tiger, Static Imports, seems that it does not fit into any chapters in the book... Is it in chapter-8(More OOP-Extending Classes)? Or am I missing sthing?
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Ko Ko, where did you find the sample chapter? I would like to read it.


GenRocket - Experts at Building Test Data
Siripa Siangklom
Ranch Hand

Joined: Jan 26, 2004
Posts: 79
Please see this thread
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by Siripa Siangklom:
Please see this thread


Thanks Siripa. Man, I have read about static and I knew what it was and what is was used for, but never have I read such a simple plain powerful description of it like what is in chapter 6. Well done Peter!
Ko Ko Naing
Ranch Hand

Joined: Jun 08, 2002
Posts: 3178
Originally posted by Gregg Bolinger:


Thanks Siripa. Man, I have read about static and I knew what it was and what is was used for, but never have I read such a simple plain powerful description of it like what is in chapter 6. Well done Peter!


Gregg,
I also find the chapter really good... Have a look at some great portions from that chapter...

A common pitfall with static methods
A common pitfall is to reference per-object members from a static method. This
�does not compute�. A static method isn�t invoked on an object and doesn�t have
the implicit �this� pointer to individual object data, so the compiler won�t know
which object you want. You�ll get an error message saying �Can't make static
reference to non-static variable.�

I even sometimes did such error... But the chapter reminds me again of such error... That's cool...

The following is kinda nice comment on the word "final", while Peter did a great comment on the word "static" in the previous section of this "final" section... I even discussed with Peter in this thread about the word "static"
This section looks at final, which makes something constant. Why was the word
�const� or �constant� not chosen? Because �final� can also be applied to methods,
as well as data, and the term �final� makes better sense for both.


And last but not least, I didn't know the following code is legal... Sometimes we overlook the tiny things...

Peter said that "Programmers rarely use this, because it clutters up the signature and makes the
parameter names harder to read."...

Anyway, I just would like to share the knowledge that I got from the sample chapter. At least I can taste his writing style and it's excellent... I do cheer for Peter's book to win Best Java Book of 2004 as well...
 
GeeCON Prague 2014
 
subject: Just Java Chapter-6: Why not cover all static data/methods/blocks/classes