Textual User Interface
- typically character-based and rely on text characters for communication
- possesses a textual interface where users interact with the system by typing text commands
- user needs to understand and input specific commands or sequences of text to perform tasks
Graphical User Interface
- interaction is more visual and intuitive, with graphical elements such as icons, buttons, windows, and menus- user can generate events through keyboard, mouse, etc.- the main event loop dispatches events by calling appropriate event handling methods (event handlers)- program consists of initialisation code and event handlers
Event in GUIS
a user-initiated action, such as a mouse click or keyboard input, which triggers a specific response or function within the graphical user interface
Main Event Loop
a continuous program structure that waits for and dispatches user input events, updating the graphical interface and executing corresponding functions to provide a responsive and interactive user experience
Event Handlers
functions or routines that are programmed to respond to specific user-initiated events, such as mouse clicks or keyboard inputs, by executing predetermined actions or processes within the graphical user interface
Listeners
an object or function that is programmed to detect and respond to specific events triggered by user interactions with graphical components, such as buttons or text fields
to handle events, a listener must implement the relevant listener interface(s) and must be registered with the component
Different Components of GUIs
frames - the top-level containers in a GUI, serving as the main application window that holds other components
panels - containers used to organize and group other components within a GUI, helping to structure the layout
labels - used to display text or images, providing descriptive information in the GUI
buttons - interactive elements that users can click to trigger predefined actions or functions in the application
- check boxes - allow users to make binary choices (selected or unselected) by toggling a checkbox
text fields - areas where users can input and edit single lines of text, such as entering names or numbers
text areas - larger input areas that allow users to enter and edit multiple lines of text, suitable for longer pieces of information or messages
Handling Button Events
- Set up a button. E.g., JButton myButton = new JButton(“Click Me”);
- Create an ActionListener. E.g.,ActionListener myActionListener = new ActionListener() { @Override public void actionPerformed(ActionEvent e) { // Code executed when button is clicked }};
- Attach ActionListener to the Button.E.g., myButton.addActionListener(myActionListener);
Replacing functionality at runtime through GUI
Can make use of checkboxes, using a switch statement based on the values of the these checkboxes to decide which of the methods will be called.
Suppose you have a generator that takes all of the outputs of a method and does something with them. If we would like to have the possibility of choosing what to do them in real-time based on GUI user-inputs, what could be some solutions?
- List:- let the generator (printer of method returns) return a list of all generated objects, and the client code can then process that list independently of the generator- however, enough memory will be needed to store the entire result and generation and processing won’t be able to take place concurrently
- Iterator:- offer the computation as an iterator, doing the client-part of the computation outside the generator so the core of the computation resides inside the iterator- however, harder to do for recursive computations, and can only supply functionality that handles each computed item
- Template Method Pattern:- generator algorithm is the template method- process algorithm is hook method, either abstract or with default implementation- client class subclasses the generator and overrides process with desired functionality- this can insert several steps in different places in generator, but client code can only be used with a specific generator
- Strategy Design Pattern:- specify the method void process(String s) in an abstract class or interface- implement it by overriding process() in a subclass- pass an object of this subclass to the generator (known as dependency injection DI)- this makes client code less coupled to generator, but there is more overhead
- Callbacks:- provide one or more methods as parrameter to the computation- this should provide ideal decoupling, and allows the client to define the processing to be done in the callback method
Observer Design Pattern
behavioural design pattern where an object, known as the subject, maintains a list of dependents, called observers, that are notified of any changes in the subject’s state
Components of Observer Design Pattern
- Subject:- maintains a list of observers- provides methods to add and remove observers- provides a method to notify observers of changes in its state- could also be an abstract class/interface
- Observer:- an interface/ abstract class with an update method that is meant to respond to a change in the subject
- Concrete Subject:- has functionality of subject but with any additional, specific properties
- ConcreteObserver:- implements the observer interface- registers with a concrete subject to receive notifications- responds to updates initiated by the subject
Code Example for Observer Design Pattern
// Subject interfaceinterface Subject { void registerObserver(Observer observer); void removeObserver(Observer observer); void notifyObservers();}// Observer interfaceinterface Observer { void update(String message);}// Concrete subjectclass ConcreteSubject implements Subject { private List observers = new ArrayList<>(); private String state; public void setState(String newState) { this.state = newState; notifyObservers(); } @Override public void registerObserver(Observer observer) { observers.add(observer); } @Override public void removeObserver(Observer observer) { observers.remove(observer); } @Override public void notifyObservers() { for (Observer observer : observers) { observer.update(state); } }}// Concrete observerclass ConcreteObserver implements Observer { private String name; public ConcreteObserver(String name) { this.name = name; } @Override public void update(String message) { System.out.println(name + “ received an update: “ + message); }}
Client Code Example for Observer Design Pattern
// Client codepublic class Client { public static void main(String[] args) { // Creating a concrete subject ConcreteSubject subject = new ConcreteSubject(); // Creating concrete observers Observer observer1 = new ConcreteObserver(“Observer 1”); Observer observer2 = new ConcreteObserver(“Observer 2”); // Registering observers with the subject subject.registerObserver(observer1); subject.registerObserver(observer2); // Updating the state of the subject, which triggers notification to observers subject.setState(“New State”); }}
Facade Design Pattern
a design pattern looking to provide a simplified and unified interface to a set of interfaces or complex subsystem by creating a single, straightforward entry point for clients
Components of Facade Design Pattern
- Facade:- main entry point for the client to access the functionalities of the subsystem(s)- provides a simplified, higher-level interface that delegates the client requests to the appropriate substystem components- may hold objects of the subsytems in order to call operations on them
- Subsystem(s):- a set of classes or interfaces that perform the actual work- facade delegates client requests to the subsystem
Code Example for Facade Design Pattern
// Subsystem componentsclass CPU { void start() { System.out.println(“CPU is starting”); } void execute() { System.out.println(“CPU is executing”); }}class Memory { void load() { System.out.println(“Memory is loading”); }}class HardDrive { void read() { System.out.println(“Hard Drive is reading”); }}// Facade classclass ComputerFacade { private CPU cpu; private Memory memory; private HardDrive hardDrive; public ComputerFacade() { this.cpu = new CPU(); this.memory = new Memory(); this.hardDrive = new HardDrive(); } // Facade method to start the computer public void startComputer() { cpu.start(); memory.load(); hardDrive.read(); cpu.execute(); System.out.println(“Computer started successfully”); }}
Client Code for Facade Design Pattern
// Client codepublic class Client { public static void main(String[] args) { // Using the ComputerFacade to start the computer ComputerFacade computerFacade = new ComputerFacade(); computerFacade.startComputer(); }}
Adapter Design Pattern
structural design pattern that allows the interface of an existing class to be used as another interfacei.e., enables classes with incompatible interfaces to work together by providing a wrapper/adapter that converts one interface into another, making the object compatible
Components of Adapter Design Pattern
- Target:- the interface that the client code expects or depends on- the target defines the specific methods or operations that the client code uses
- Adaptee:- the existing class or interface that needs to be integrated into the system- has an interface that is incompatible with the client’s expectations (target)
- Adapter:- a wrapper class that implements the Target interface- holds an instance of the Adaptee class to call methods on that it gets as an argument- delegates calls to the methods of the target interface to the corresponding methods of the adaptee- makes adaptee’s interface compatible with the target interface
Code Example for Adapter Design Pattern
// Target interfaceinterface Target { void request();}// Adaptee (existing class)class Adaptee { void specificRequest() { System.out.println(“Adaptee’s specificRequest called”); }}// Adapter class implementing the Target interfaceclass Adapter implements Target { private Adaptee adaptee; public Adapter(Adaptee adaptee) { this.adaptee = adaptee; } @Override public void request() { adaptee.specificRequest(); }}
Client Code for Adapter Design Pattern
Adaptee adaptee = new Adaptee();Target adapter = new Adapter(adaptee);adapter.request(); // calls a method of adaptee
Decorator Design Pattern
structural design pattern that allows behaviour to be added to an individual object, either statically or dynamically, without affecting the behaviour of other objects from the same classused to extend or augment the behaviour of objects in a flexible and reusable way, providing an alternative to subclassing for extending functionality
Components of Decorator Design Pattern
- Component:- the interface or abstract class that defines the common interface for all concrete components and decorators
- ConcreteComponent:- basic implementation of the component interface- represents the core functionality that decorators can extend
- Decorator:- abstract class or interface that implements the component interface- has a reference to a component and can dynamically add additional behaviour to the component
- ConcreteDecorator:- adds specific functionalities to the component it holds a reference to by overriding or extending its methods- multiple concrete decorators can be combined to create a variety of configurations
