facade_pattern

---

Facade

The facade pattern is a software design pattern commonly used with object-oriented programming. The name is by analogy to an architectural facade. A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can; make a software library easier to use, understand and test, since the facade has convenient methods for common tasks; reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system; wrap a poorly designed collection of APIs with a single well-designed API (as per task needs).

I commonly uses a sql view to create a facade. For example; when I create a table I will create a view even if it does nothing other than select directly from the table!

    -- table
    create table [<schema>_secure].[<data_name>] (
        [id]                 [int] identity(1,1) not null,
        [<many_data_columns>] [<type>],
        [created]            [datetime] not null,
        [created_by]         [nvarchar](785) not null,
        constraint [pk_<schema>_secure_<data_name>] primary key ([id]),
        constraint [df_<schema>_secure_<data_name>_created] default (current_timestamp),
        constraint [df_<schema>_secure_<data_name>_created_by] default (current_user)
    );
    go

    -- facade
    create view [<schema>].[list_<data_name>] as
        select   [<data_column_1>] as [<data_name_1>],
                 [<data_column_n>] as [<data_name_n>],
        from     [<schema>_secure].[<data_name>];                  
    go

    -- setter
    create <method> [<schema>].[set_<data_name>] @<parameters> <type>
    as
        <merge into [<schema>_secure].[<data_name>]>;
    go

    -- getter
    create <method> [<schema>].[get_<data_name>] @<parameters> <type> <output>
    as
        <find and return record>;
    go

The first thing you'll notice is that I've used the view to hide the "system" columns (primary key, auditing) from the business component. They typically do not need these. Obviously if there is a reason for the business user to see the primary key I can include it.

You will also notice that the table itself is in a _secure schema where it is not even accessible by the business user or application! By exposing only the facade to future applications I have allowed the implementation to vary according to future needs (performance, adaptation, extensibility) without breaking any business applications! The getter and setter methods are not exactly facades, but they fill much of the same purpose by providing the ability to access the data which can be modified if the underlying implementation needs to change, and act as interfaces to the implementation. This practice is generally referred to that of programming to an interface rather than an implementation.

In the future, should the implementation need to change, perhaps due to normalization or performance enhancements, the view and the two methods can be refactored to provide the same result to the business application, allowing change without breaking the system. This concept of encapsulation of both the accessor methods and the implementation is a core feature of object oriented design and is easy to implement, if that is your objective.

Should the implementation change in the future, the view will actually move from being merely a facade to (potentially) becoming an adapter pattern. A column might, for example, change from an [nvarchar](15) to a [bigint] for reasons necessary to the management or representation of the data. The view can be changed to cast that value to [nvarchar](15), providing the business application the same results with no changes required. If the table is normalized into multiple tables the view and getter|setter methods join them together, again providing a consistent interface to the business application by allowing the implementation to vary separately from the interface.

---

---

Reference

• bridge pattern - bridges the public to the secure schema.

  The bridge pattern is a design pattern used in software engineering which is meant to "decouple an abstraction from its implementation so that the two can vary independently". The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. It is similar to the Decorator pattern - allows objects with incompatible interfaces to work together by wrapping its own interface around that of an already existing objects. In computer programming, the adapter pattern (often referred to as the wrapper pattern or simply a wrapper - an alternative naming shared with the Adapter pattern according to the GoF Design Patterns book) is a design pattern that translates one interface for a class into a compatible interface.[1] An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms.