Content |
|
|
What is the 'Abstract Window Toolkit'?When thinking about Java one must remember that Java was designed so that programs developed using it would work identically on any computer with a Java system, irrespective of hardware and operating system. This means that the Java programmer must never be allowed to communicate directly with the computer's operating system, or with the 'real' user interface; this would make the program platform-dependent. All user interface actions are mediated by the AWT (or Swing) classes. The Java program creates and manipulates AWT objects, and these objects manipulate the 'real' user interface. The way this is done should be of no concern to the Java programmer; it is automatic. This is the origin of the word 'abstract' in AWT. In the same way that an abstract class provides a specification, but not implementation, and abstract window specifies how a screen window should behave, but does not define how it does this. The figure below illustrates how a Java program use AWT (or Swing classes) that hide, from the Java programmer, the actual interface elements on whichever computer system the Java program is being executed on.
For example, to the AWT a screen window that has a border and can be manipulated by the user with a mouse is abstracted as the 'Frame' class. It is just a rectangle with given size and position, which receives events (more of which later). The Frame can contain other objects. The exact appearance of a Frame on the user's computer will depend on the type of computer and the operating system it uses. The action the user has to take to close the window will vary from one system to another. This scheme provides platform independence by separating the 'abstract' concepts of the graphical user interface from their concrete implementation on a given system. Technically the 'real' user interface element that the user sees is called the 'peer' of the abstract element the Java program manipulates.
|
