The appearance pattern of Java design pattern __java

The appearance mode (façade pattern) involves some of the subsystems ' classes. A subsystem is a group of classes that are closely related to providing a series of related features (functions). For example, an account class, address class, and CreditCard class are interconnected and become part of a subsystem that provides characteristics of an online customer.

In a real-world application system, a subsystem may consist of many classes. The customers of the subsystem need to interact with some classes in the subsystem for their needs. Direct interaction between client and subsystem classes can result in a high degree of coupling between client objects and subsystems (Figure1). Any modification to an interface similar to a class in a subsystem can have an impact on all customer classes that depend on it.

Figure1:client interaction with subsystem Classes before applying the façade pattern

Appearance patterns (façade pattern) are well suited in the above situations. The façade pattern provides a higher level and simpler interface for the subsystem, which reduces the complexity and dependency of the subsystem. This makes subsystems easier to use and manage.

Appearance is a class that provides a simple interface for subsystems and customers. When the right look is applied, the customer no longer interacts directly with the class in the subsystem, but with the appearance. The appearance assumes responsibility for interacting with classes in the subsystem. In fact, the appearance is the interface between the subsystem and the customer, so that the appearance pattern reduces the coupling between the subsystem and the customer (Figure2).

Figure2:client interaction with subsystem Classes after applying the façade pattern

We can see from the Figure2 that the skin object isolates the client and subsystem objects, thus reducing the coupling. When a class in a subsystem changes, the client is not affected as before.

Although the customer uses a simple interface provided by the skin, the client can directly access the underlying interface in the subsystem when it is needed, depending on whether the appearance does not exist. In this case, the dependency/coupling between them is the same as the original.

Example:

Let's build an application:

(1) Accept customer details (account, address and credit card information)

(2) Verify the information entered

(3) Save the entered information to the appropriate file.

This application has three classes: account, address, and CreditCard. Each class has its own method of validating and saving data.

Listing1:accountclass

public class Account { String FirstName; String LastName; Final String account_data_file = "AccountData.txt"; Public account (String fname, String lname) { FirstName = fname; LastName = lname; } public Boolean isValid () { /* Let ' s go with simpler validation Here to keep the example simpler. */ ... ... } public Boolean Save () { Fileutil futil = new Fileutil (); String dataline = getlastname () + "," + getfirstname (); Return Futil.writetofile (Account_data_file, Dataline,true, true); } Public String Getfirstname () { return firstName; } Public String Getlastname () { return lastName; } }

Listing2:address Class

public class Address { String address; String City; String State; Final String address_data_file = "Address.txt"; Public address (string add, String Cty, string st) { address = add; City = Cty; state = st; } public Boolean isValid () { /* The Address validation algorithm Could be complex in Real-world Applications. Let ' s go with simpler validation Here to keep the example simpler. */ if (GetState (). Trim (). Length () < 2) return false; return true; } public Boolean Save () { Fileutil futil = new Fileutil (); String dataline = getaddress () + "," + getcity () + "," + getState (); Return Futil.writetofile (Address_data_file, Dataline,true, true); } Public String getaddress () { return address; } Public String getcity () { return to City; } Public String getState () { return state; } }

Listing3:creditcard Class

public class CreditCard { String Cardtype; String Cardnumber; String cardexpdate; Final String cc_data_file = "CC.txt"; Public CreditCard (String cctype, String ccnumber, String ccexpdate) { Cardtype = Cctype; Cardnumber = Ccnumber; Cardexpdate = ccexpdate; } public Boolean isValid () { /* Let ' s go with simpler validation Here to keep the example simpler. */ if (Getcardtype (). Equals (Accountmanager.visa)) { Return (Getcardnumber (). Trim (). Length () = 16); } if (Getcardtype (). Equals (Accountmanager.discover)) { Return (Getcardnumber (). Trim (). Length () = 15); } if (Getcardtype (). Equals (Accountmanager.master)) { Return (Getcardnumber (). Trim (). Length () = 16); } return false; } public Boolean Save () { Fileutil futil = new Fileutil (); String dataline = Getcardtype () +, "" + getcardnumber () + "," + getcardexpdate (); Return Futil.writetofile (Cc_data_file, Dataline, True, true); } Public String Getcardtype () { return cardtype; } Public String Getcardnumber () { return cardnumber; } Public String getcardexpdate () { return cardexpdate; } }

Figure3:subsystem Classes to provide the necessary functionality to Validate and Save the Customer Data

Let's build a customer Accountmanager that provides user interface for user input data.

Listing4:client Accountmanager Class

public class Accountmanager extends JFrame { public static final String newline = "\ n"; public static final String Validate_save = "VALIDATE & SAVE"; ... ... Public Accountmanager () { Super ("Façade pattern-example"); Cmbcardtype = new JComboBox (); Cmbcardtype.additem (Accountmanager.visa); Cmbcardtype.additem (Accountmanager.master); Cmbcardtype.additem (Accountmanager.discover); ... ... Create buttons JButton Validatesavebutton = new JButton (accountmanager.validate_save); ... ... } Public String Getfirstname () { return Txtfirstname.gettext (); } ... ... }//end of Class Accountmanager

When the customer Accountmanage running, the user interface displayed is as follows:

Figure4:user Interface to Enter the Customer Data

To verify and save the input data, the customer Accountmanager needs to:

(1) Establish account, address and CreditCard objects.

(2) Validating the input data with these objects

(3) Use these objects to save the input data.

The following is an interactive sequence diagram between objects:

Figure5:how a Client Would normally interact (directly) with subsystem Classes to Validate and Save the Customer Data

Applying a skin pattern in this example is a good design that lowers the coupling between the customer and subsystem components (address, account, and CreditCard). With the appearance pattern, let's define a visual class Customerfacade (Figure6 and Listing5). It provides a high-level, simple interface for subsystems composed of customer data processing classes (address, account, and CreditCard).

Customerfacade Address:string City:string State:string Cardtype:string Cardnumber:string Cardexpdate:string Fname:string Lname:string Setaddress (inaddress:string) Setcity (incity:string) SetState (instate:string) Setcardtype (incardtype:string) Setcardnumber (incardnumber:string) Setcardexpdate (incardexpdate:string) Setfname (infname:string) Setlname (inlname:string) Savecustomerdata ()

Figure6:facade Class to is Used by the Client in the revised

Listing5:customerfacade Class

public class Customerfacade { Private String address; Private String City; Private String State; Private String Cardtype; Private String Cardnumber; Private String cardexpdate; Private String fname; Private String lname; public void setaddress (String inaddress) { address = inaddress; } public void setcity (String incity) { City = incity; } public void SetState (String instate) { state = instate; } public void Setfname (String infname) { fname = InfName; } public void Setlname (String inlname) { LName = Inlname; } public void Setcardtype (String incardtype) { Cardtype = Incardtype; } public void Setcardnumber (String incardnumber) { Cardnumber = Incardnumber; } public void Setcardexpdate (String incardexpdate) { Cardexpdate = incardexpdate; } public Boolean savecustomerdata () { Address objaddress; Account Objaccount; CreditCard Objcreditcard; /* The client is transparent from the following Set of subsystem related operations. */ Boolean validdata = true; String errormessage = ""; Objaccount = new Account (fname, lname); if (objaccount.isvalid () = = False) { ValidData = false; errormessage = "Invalid firstname/lastname"; } objaddress = new Address (address, city, state); if (objaddress.isvalid () = = False) { ValidData = false; errormessage = "Invalid address/city/state"; } Objcreditcard = new CreditCard (Cardtype, Cardnumber, cardexpdate); if (objcreditcard.isvalid () = = False) { ValidData = false; errormessage = "Invalid CreditCard Info"; } if (!validdata) { System.out.println (errormessage); return false; } if (Objaddress.save () && objaccount.save () && objcreditcard.save ()) { return true; } else { return false; } } }

The Customerfacade class provides services at the business level in the form of a Savecustomdata method. Instead of interacting directly with each component of the subsystem, customer Accountmanager uses a higher-level, simpler interface (FIGURE7) that is provided by the Customfacade object to validate and store customer data.

Figure7:class association with the Fa?ade Class.

In the new design, to validate and save customer data, customers need to:

(1) Establishing or acquiring an instance of the Customfacade of the Appearance object.

(2) Pass data to Customfacade instance to verify and save.

(3) Invoke the Savecustomdata method on the Customfacade instance.

Customfacade handles the details of creating the necessary objects in the subsystem and invoking the appropriate validation on those objects, and methods of saving customer data. Customers no longer need direct access to objects in any subsystem.

Figure8 shows the new design of the message Flow diagram:

Figure 22.8:in The revised design, Clients interact with the Fa?ade Instance and Interface with the subsystem

Important NOTE:

The following are considerations for applying a skin pattern:

(1) There is no need to add additional functionality when designing the appearance.

(2) Do not return the components in the subsystem to the customer from the appearance method. For example: There is one of the following methods:

CreditCard Getcreditcard ()

Will report the details of the subsystem to the customer. Applications do not get the most benefit from the application of the skin pattern.

(3) The purpose of the application appearance is to provide a high-level interface. Therefore, the appearance method is best suited to provide a specific high-level business service rather than a separate business execution at the bottom level.

The above is a more comprehensive example, in addition, in order to deepen understanding we continue to learn the following content.

Related roles:

1. Appearance (façade) Role: A method that a client can invoke for this role. This role is aware of the functions and responsibilities of the subsystems involved.

2. Subsystem role: You can have one or more subsystems at the same time. Each subsystem is not a separate class, but rather a collection of classes. Each subsystem can be called directly by the client or by the appearance role.

Applicable situation:

1. Provide a simple interface for complex subsystems;

2. There is a large dependency between the client program and the implementation part of the abstract class;

3. When building a hierarchical subsystem, the appearance pattern defines the entry points for each layer in the subsystem.

Simple implementation of the appearance pattern:

Code:

Camara.java

package façade;

public class Camara {public
	void Turnon ()
	{
		System.out.println () ("Open camera.") ");
	}
	
	public void turnoff ()
	{
		System.out.println ("Turn off the camera.) ");
	}
}

Light.java

package façade;

The public class Light {public
	void Turnon ()
	{
		System.out.println () is turned on. ");
	}
	
	public void turnoff ()
	{
		System.out.println ("Turn off the light.") ");
	}
}

Sensor.java

package façade;

The public class Sensor {public
	void activate ()
	{
		System.out.println () (")" opens the sensor. ");
	}
	
	public void Deactivate ()
	{
		System.out.println () closes the sensor. ");
	}
}

Myfacade.java

package façade;

public class Myfacade {
	private static Camara C1, C2;
	private static Light L1, L2, L3;
	private static Sensor s;
	
	Static
	{
		C1 = new Camara ();
		C2 = new Camara ();
		L1 = new Light ();
		L2 = new Light ();
		L3 = new