CodeGuru content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
| Bruce Eckel’s Thinking in Java | Contents | Prev | Next |
Like
my previous book
Thinking
in C++
,
this book has come to be structured around the process of teaching the
language. In particular, my motivation is to create something that provides me
with a way to teach the language in my own seminars. When I think of a chapter
in the book, I think in terms of what makes a good lesson during a seminar. My
goal is to get bite-sized pieces that can be taught in a reasonable amount of
time, followed by exercises that are feasible to accomplish in a classroom
situation.
my previous book
Thinking
in C++
,
this book has come to be structured around the process of teaching the
language. In particular, my motivation is to create something that provides me
with a way to teach the language in my own seminars. When I think of a chapter
in the book, I think in terms of what makes a good lesson during a seminar. My
goal is to get bite-sized pieces that can be taught in a reasonable amount of
time, followed by exercises that are feasible to accomplish in a classroom
situation.
My
goals in this book are to:
goals in this book are to:
- Present
the material one simple step at a time so that you can easily digest each
concept before moving on. - Use
examples that are as simple and short as possible. This sometimes prevents me
from tackling “real world” problems, but I’ve found that
beginners are usually happier when they can understand every detail of an
example rather than being impressed by the scope of the problem it solves.
Also, there’s a severe limit to the amount of code that can be absorbed
in a classroom situation. For this I will no doubt receive criticism for using
“toy examples,” but I’m willing to accept that in favor of
producing something pedagogically useful. - Carefully
sequence the presentation of features so that you aren’t seeing something
that you haven’t been exposed to. Of course, this isn’t always
possible; in those situations, a brief introductory description is given. - Give
you what I think is important for you to understand about the language, rather
than everything I know. I believe there is an information importance hierarchy,
and that there are some facts that 95 percent of programmers will never need to
know and just confuses people and adds to their perception of the complexity of
the language. To take an example from C, if you memorize the operator
precedence table (I never did), you can write clever code. But if you need to
think about it, it will also confuse the reader/maintainer of that code. So
forget about precedence, and use parentheses when things aren’t clear. - Keep
each section focused enough so that the lecture time – and the time
between exercise periods – is small. Not only does this keep the
audience’s minds more active and involved during a hands-on seminar, but
it gives the reader a greater sense of accomplishment. - Provide
you with a solid foundation so that you can understand the issues well enough
to move on to more difficult coursework and books.
