Re: Please recommend a book
bobw...@mixnym.net wrote:
markspace said:
Some of this is just "time," like I mentioned before. Java has a BIG
API and you won't learn it well by just reading one thing. Getting a
few basic books and looking at how they do it will give you some ideas.
In other words, there's "patterns" here that work, and some that don't.
Ok.
Also, the API is spread out. It's been improved incrementally for 17
odd years, and similar things are not all together. In general to read
user input you want the System, not Console. Console is recent and just
contains some extensions to the basic I/O that people were asking for.
System.in is the workhorse. Wrap that in a BufferedReader and read from
that.
Whaa?!?
BufferReader reader = new BufferedReader(new InputStreamReader(System.in));
"To wrap" is one of the fundamental operations of computer programming.
Time and just plowing through will get you there after a while. The
important bit is to do it.
Well, to a point. You have got to gain a conversational fluency with the
terminology of computer programming. Otherwise "plowing through" risks seeing
the farm from the horse's viewpoint rather than the farmer's.
I'm realizing this isn't going to be like learning another procedural or
scripting language. I usually can write something meaningful in a new one of
those the same day.
Java is a disciplined language, but actually is a procedural language.
Are you familiar with other compiled languages?
Java gives you building blocks, mostly through its API as the language itself
is reasonably spare.
You might want to wiki around for object-oriented thinking, but it can be
simply summarized for Java purposes as type thinking.
You construct types that interact, at best via the interface declarations with
no client knowledge of how a service implementation fulfills its promises.
You send and receive sensible types through those interfaces.
In this Java is pretty much like a lot of remote-programming protocols.
So get used to thinking of types that foment instances, and all with attributes
and behaviors.
Attributes are the 'T getX()' and 'setX(T x)' methods.
Behaviors are all the other methods.
Expressing attributes as getters and setters makes them annoying enough to
keep you from programming giant data-transfer types. That would be an
antipattern.
Generics are just base types and assertions about their relationships.
'Set<T>' means that you have a set each item of which is of type 'T'.
You can use generics for your own type, let's say an invoker of 'Invocable'
things.
public interface Invocable
{
/** Invoke this thing. */
void invoke();
}
/**
* Invoker of an {@code Invocable}.
* @param <T> base type to invoke.
*/
public class Invoker<T extends Invocable>
{
/**
* Invoke a base-type thing.
* @param invocable T proxied {@code Invocable}.
*/
public void invoke(T invocable)
{
invocable.invoke();
}
}
'<T extends Invocable>' asserts that 'T' defines an 'invoke()' method.
--
Lew