Program output good and bad programming practices

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: on"; if ( e.isAltDown() ) // Middle mouse button += " with center mouse button"; // Left mouse button += " with left mouse button"; 59 60 61 62 63 } setTitle( s ); repaint(); } } // set the title bar of the window Set the Frame's title bar. Program Output Good and bad programming practices with AWT Separate user interface logic from "business logic" or model AWT 1.1 "listeners" designed for this purpose; inner classes facilitate it further Separation.java example illustrates this approach: class BusinessLogic knows nothing about UI; class Separation keeps track of all UI details and talks to BusinessLogic through its public interface. How is this design loosely coupled? How does it support reuse? How does it support legacy code? Also note use of inner classes for all "listeners" nested within Separation Contrast code of badidea1.java: look at code in actionPerformed: badidea2.java improves on things by using adapters, but ... Why is the cascaded if above a bad idea? public void actionPerformed(ActionEvent e) { Object source = e.getSource(); if (source == b1) System.out.println("Button 1 pressed"); else if (source == b2) System.out.println("Button 2 pressed"); else System.out.println("Something else"); }...
View Full Document

This note was uploaded on 08/06/2008 for the course CSE 432 taught by Professor Blank during the Fall '08 term at Lehigh University .

Ask a homework question - tutors are online