3

Read about facade, but not quite understand the advantage to use, primarily using MVC. Could someone help me understand? Some more practical example? Excuse my ignorance!

Will Marcouiller
  • 23,773
  • 22
  • 96
  • 162
Fabiano Moura
  • 69
  • 1
  • 6
  • google "facade design pattern example" and start reading – DavidPostill Aug 20 '14 at 19:45
  • As I said, I read several articles and seen some examples, but did not understand the effectiveness of using the facade! In other words, not realized the need to use the facade. – Fabiano Moura Aug 20 '14 at 19:51
  • I don't think MVC is relevant to the question at all... – Mike B Aug 20 '14 at 19:54
  • You asked for **Some more practical example**. There are plenty of practical examples returned by the google search above. – DavidPostill Aug 20 '14 at 19:55
  • DavidPostill, i understand, but as I mentioned, I want to understand the importance of using the facade, especially with MVC. In all the examples I saw, it was not clear to me. Thank you! – Fabiano Moura Aug 20 '14 at 20:04

3 Answers3

6

The Facade Pattern is an aggregate service that provides several contextual features or services.

From Wikipedia

The facade pattern (or façade 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;

  • make the library more readable, for the same reason;

  • 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).

This being said, off the top of my head, let's say you have an accounting system for which the main form is an MDI, so you have multiple menus here and there allowing the user to access those functionalities.

In order to avoid multiple dependencies, instead of writing something like the following:

public class MainWindow : Form {
    public MainWindow(CustomerManagementPresenterFactory customerMgmt
        , SupplierManagementPresenterFactory supplierMgmt
        , InventoryManagementPresenterFactory inventoryMgmt
        , EmployeeManagementPresenterFactory employeeMgmt
        , StatementOfAccountManagementPresenterFactory statementOfAccntMgmt
        , InvoicesPastDueManagementPresenterFactory pastDueInvoicesMgmt) {
        // Work your dependencies here...
    }
}

where you clearly see that your MainWindow depends on multiple factories (or whatsoever), it is time to refactor. One question is:

  • Do I have too many dependencies passed to my MainWindow constructor?

The answer is YES, I have. Despite, my MainWindow does need all those dependencies in order to fulfill its requirements.

  • How can I refactor to reduce the number of dependencies?

One might state that the Past due invoices, Statement of accounts and the Customer management features shall be aggregated into only one service. Here comes the Facade.

public class CustomerManagement {
    public CustomerManagement(CustomerManagementPresenterFactory customerMgmt
        , StatementOfAccountManagementPresenterFactory statementOfAccntMgmt
        , InvoicesPastDueManagementPresenterFactory pastDueInvoicesMgmt) {
        // Work your dependencies here...
    }
}

So now the MainWindow constructor can look as follows.

public class MainWindow : Form {
    public MainWindow(CustomerManagement customerMgmt
        , SupplierManagementPresenterFactory supplierMgmt
        , InventoryManagementPresenterFactory inventoryMgmt
        , EmployeeManagementPresenterFactory employeeMgmt) {
        // Work your dependencies here...
    }
}

Then, depending on your business domain, the SupplierManagement could be intimately linked to your InventoryManagement, so that another aggregation could be done like so.

public class InventoryManagement {
    public InventoryManagement(InventoryManagementPresenterFactory inventoryMgmt
        , SupplierManagementPresenterFactory supplierMgmt) {
        // Work your dependencies here...
    }
}

So that you may further refactor to:

public class MainWindow : Form {
    public MainWindow(CustomerManagement customerMgmt
        , InventoryManagement inventoryMgmt
        , EmployeeManagementPresenterFactory employeeMgmt) {
        // Work your dependencies here...
    }
}

Now, as you can see, it is much simpler to understand what the MainWindow might do to serve its purpose. The idea behind is to group together what makes sense for your business domain. In another context, one might have prefered to group together the CustomerManagement, SupplierManagement and the EmployeeManagement as they have similar information to share as the Name, Address, Phone Number, Email, etc. This is primarily based on your needs. In the end, the role of the façade still holds same, to group together similar business features to add an abstraction layer and reduce complexity.

A very interesting article on the topic by Mark Seemann is Refactoring to Aggregate Services.

For more information on Design Patterns and Dependency Injection, I do recommend Mr. Seemann's book: Dependency Injection in .NET. Though the title states .NET, anyone wanting to learn about Dependency Injection and Design Patterns shall read it to grow one understanding on the topics and improve one skills. The example are easy to understand even if you're not from .NET.

Other interesting Q/A here on SO about the Façade Pattern

Disclaimer

I know your question is tagged Java and I posted C# code. This is meant for rapid answer off the top of my head. I think that though my samples are C#, you might easily understand the key point of the examples shown for the façade as they're simple, IMHO

Community
  • 1
  • 1
Will Marcouiller
  • 23,773
  • 22
  • 96
  • 162
1

Facades are meant to be wrappers around complex functionality, their primary goal is hiding complexity of an underlying system. You can think of the Facade as a layer wrapping the complex functionality and providing simpler methods to interact with.

It provides an interface to the client using which the client can access the system. This type of design pattern comes under structural pattern as this pattern adds an interface to exiting system to hide its complexities.

enter image description here

Tushar Gupta
  • 15,504
  • 1
  • 29
  • 47
  • Tushar from what I understand, the facade serves only to make calls to simpler methods. Is it? In case the facade will also present some business rule, or it is in another layer? – Fabiano Moura Aug 20 '14 at 20:19
0

MVC is more like a general way of thinking when it comes to computer design. MVC could be said in a conversation of web development or desktop applications But with the EJBs or facades it is really less general and more specific. "It used to handle all the transaction manager and persistence manager interactions." You will use something like this with JSF as the view and JPA or Hibernate. Also using EJBs gives more options of premade code.

Sometimes I think the differences between certain subjects, like facades and MVC are not always black and white or so obvious.

Rika
  • 768
  • 1
  • 5
  • 16
  • Rika really for me, the beginning was very confusing. The examples given by Will Marcouiller and Tushar Gupta were key to understanding how and when to use facade works. Especially the example that Will cited Marcouiller! Fantastic and easy to understand! – Fabiano Moura Aug 20 '14 at 21:03