Simple appearance Mode

Recently, the data center charging system has been restructured. Although two design modes have been used, it still feels strange. I always feel that there is a problem with the appearance. I know that I tried the experiment for one night yesterday, I found out where I was wrong. Now I will introduce what I think is correct.

What is the appearance.

Simply put, It is a group of excuses used to connect the client and implement complex functions to prevent coupling between the client and the subsystem, as a result, the customer program will change as the subsystem changes, so we use the excuse of appearance pattern to implement it.

Why?

You may encounter such a problem during programming. For example, for the simplest login, we will first query the card number. If the card number passes, we will query the password, the two items pass to access the permission. Therefore, we will call two methods in the client code. When we register the two methods, we also need to determine whether the two items exist, this method needs to be called twice, but it does not seem to be a lot of. What if there are three methods and combinations of the four methods, so we will think of encapsulating these methods into a method, so the appearance model came into being.

Next let's take a look at what it looks like if you don't need it. For example, for a Login Demo, we need two methods to determine the user name and password.

Then let's see what it looks like.

The Code is as follows:

Method

'Verify whether the user has the public function isexist (byval user as entity. userinfo) as Boolean dim iuser as idal. iuser dim factory as new factory. dataaccess dim mylist as new list (of entity. userinfo) 'Call the factory method to create an interface iuser = factory. createuser () 'calls an excuse method. The returned value is mylist = iuser for the list generic set. queryuserinfo (User) If mylist. count = 0 then msgbox ("username input error") return false else return true end if end Function

'Verify that the password is correct. Public Function confirmpwd (byval user as entity. userinfo) as Boolean dim iuser as idal. iuser dim factory as new factory. dataaccess' uses the abstract factory + reflection to call an interface method iuser = factory. createuser () dim mylist as new list (of entity. userinfo) 'query the password Based on the login user name and return it to list mylist = iuser. queryuserinfo (User) 'If the user name is correct if mylist. count = 1 then' if the password is correct if mylist. first. pwd = user. PWD then return true' error else msgbox ("Incorrect password") end if end Function

Appearance Layer

''' <Summary> ''' login appearance ''' </Summary> ''' <Param name = "user"> input user name and password </param>' ''<returns> Boolean </returns> ''' <remarks> </remarks> Public Function login (byval user as entity. userinfo) as Boolean dim confirsponl as new BLL. loginbll dim flag as Boolean 'Method of querying user name flag = confir1_l. isexist (User) 'password query method flag = confirsponl. confirmpwd (User) return flag end Function

Client

Dim euser as new entity. userinfo 'instance the new userinfo, which is used to pass the object of layer B 'to the input parameter euser. username = txtusername. text. trim' passes the user name to the username euser at the Entity layer. pwd = txtpwd. text. trim' passes the password to the object Layer pwd' to call the appearance layer and determine whether to log on to dim loginui as new facade. userfac if loginui. login (euser) = true then msgbox ("Login successful") else exit sub end if

In the end, the appearance seems to me an excuse. In order to reuse it, in order to make the maintenance of our client easier interface, maybe it makes the business logic more complex and the program execution is a little slower, but it cannot conceal the benefits it brings to us, that is, the simplicity of the Code.

Simple appearance Mode