The course has been run several times using the following structure:
anyway, the question is, what do people here think of the course structure? I'm aware that we don't get started on OO until day 2, but I can't really think of a good way of introducing it within day 2 where they need to get to grips with the anguage fundamentals. Any thoughts on how early OO can be introduced and ways of using it without clouding the need to learn about floats, loops and operators ?
Day 3 is there because it is a way of pulling together all the concepts into a real piece of software that they can see doing something, it would be nice if people could develop the sort of thing they were interested in (app, applet, servlet etc) but the resources are simply not there so I choose to stick to a stand alone app and cover a little GUI stuff.
Howdy -- I like to teach things iteratively, so maybe if you kept your day one topics but did them only *partly* (rather than doing each topic such as "conditionals" to death at that point), then you could get them to the point where they can *do* something pretty quickly, then jump into OO on day one. Do the same thing with OO -- don't do it to death at that early point, then iteratively at some point in the course come back around and go into more details on your day one stuff and the OO stuff that would have been covered in Day two. So I guess I'm saying you can bring day two OO stuff into day one, if you do your first pass at those topics without giving them The Full Treatment.
Our editor has a saying about this... "What's the minimum threshold they have to reach to be able to be creative?" So, as long as they can use an if and a for loop and basic variable declarations for an int, they can make things happen, and then giving them some basic OO early on at a very simple level...
So I guess my main point would be that teaching the topics iiteratively, over the length of the whole course, can be a good way to get them doing interesting things very early, while still giving you the chance to come back around to fill in the gaps. When you don't teach iteratively, there's always a chance that you get behind and some of the important stuff is left out--I'd rather leave out some of the additional pieces of the topics I DO cover, then leave out some topics completely.
Hi, Though Kathy is too modest to say so, her book with Bert Bates (Head First Java) could give you some ideas on how to introduce O-O quickly, allow the students to start developing some apps quickly, and spark additional excitment about Java (beyond whatever they come in with). [ September 07, 2004: Message edited by: Barbara Norway ]
posted 14 years ago
Thanks for the input, much appreciated. Oh how I love to teach Java to scientists; typical problems are...
Comments like... "..oh, this would be soooo much easier in C" "..can I install an IDE, I'm bored of using the command line already" "..well, when I do this in fortran..." "..why are we coding basic GUI's without a GUI tool?"
Problem is a lot of these guys are either a) out to confuse you or try and make Java look inadequate compared to whatever bizarre language they have been using for the past 15 years or b) they are used to using visual development environments, stuff like VB etc and they aren't prepared to see the benefit of actually learning basic Java instead of getting an IDE to skim over the details. Although I am considering using NetBeans or something this time instead of just javac
SCJP 1.4, www.gsi3d.org.uk
posted 14 years ago
Wow, can I identify with that. Except mine say "I could write that system in two days in FileMaker." NOT. [ September 09, 2004: Message edited by: Barbara Norway ]