Java Basics

Commentary: Why learn GUI programming?

All "normal" programs are GUI based, so this question seems peculiar. It's raised because some Java textbooks are written without any GUI coverage, and others cover it only as a marginal or optional topic. I'll try to address why some authors avoid it, and why GUIs should be taught from relatively early.

Adaptations. The biggest problem is that many textbooks are simply adaptations of an author's earlier C++, C, or Pascal books. These authors are no longer active programmers, so have never actually written GUI programs beyond simple textbook samples, and GUI programming requires a little experience before you feel comfortable.

No motivation to change. Publishers have no motivation to innovate, and don't want to make changes to the tried-and-true (tired-and-true) formulas of the past. Here are some of the objections I've heard from instructors who didn't want to teach GUIs.

Invalid objection: It's too hard

Based on my experience with students it simply doesn't seem to be true that it's too hard. I've taught it to very beginning Java students, and they've managed fairly well with it. However, I believe that delaying it until they know more about methods is probably better so that there is less "magic" involved. Although there is a lot of infrastructure behind everything that is done in the GUI, giving the students good templates to follow allows them to program without being bothered by the many questions that might trouble a more experienced programmer.

Far from being seen as hard, students are very eager to learn it because it allows them to build real programs - programs that they can show their family and friends.

Invalid objection: It isn't related to "normal" programming

Every "normal" program has a user interface, so it certainly is "normal". It's hard to imagine a student level program that shouldn't have a GUI interface.

When programs become larger, the percentage of the code that is related to the GUI becomes smaller and the portion of code related to the logic becomes larger. In a large project, only a few programmers may work on the GUI, so there is plenty of large-project programming that doesn't involve writing GUIs.

Also, a number of programs have no GUI interface. Java programs running on a server support web pages, but produce HTML to display to the user, and don't involve writing a Java GUI. There are other "faceless" programs. For example, I once wrote a Java program that ran every day automatically, read information from various pages on the Internet and sent me an analysis every day by email. No GUI interface was necessary.

Weak objection: Covering GUIs means leaving something else out

There are a fixed number hours in a programming course, and adding something means removing something else. So what should be removed? There are a few obvious candidates.

Eliminate/delay console I/O. One of the first candidates for elimination is console I/O. This is less of a problem since the introduction of the relatively simple Java 5 Scanner class, but coverage of even this should be delayed until file I/O is covered, which itself should be delayed until the JFileChooser Dialog is covered.

GUI as inheritance example. A major issue in teaching Object-Oriented Programming is teaching inheritance. There are nice intuitive analogies to inheritance with examples like the relationship between animal phyla, but these all suffer from the difficulty of turning these into code. The standard bank account or employee examples are OK, but suffer from not furnishing any really convincing programming opportunities. Teaching inheritance is hard because there aren't simple problems that can use it.

Altho inheritance is very important to understand, it isn't used that often. One of the few places where it is used to great advantage is in GUIs. The GUI system can and should be used as a real, not contrived, example of inheritance.

Interfaces. Far more important than inheritance are interfaces. Again, it is hard to create small, real, examples of interface usage that can be related to real student programs at a fairly early stage. GUI programming, primarily in the form of ActionListener, is a good model for interfaces at an early stage.

And more. In addition to providing real demonstrations of inheritance and interfaces, GUIs demonstrate other OOP concepts such as inner classes, method overriding, constructors, and constructor chaining. later it can provide a good motivation for threads.

Mostly changing, not adding. To a large extent teaching GUI programming doesn't have to mean leaving something out, but rather redirecting coverage of OOP topics to practical GUI examples.

The conversion of textbooks to early GUI will probably have to wait for a new generation of authors who grew up with GUIs.