0

In our application (C#), the facade is used as the core's API - the facade will be used by the App itself to do stuff with the core. Knowing that, here are my questions:

  1. Assuming one of my core objects, which the facade wraps, has a recursive bit in it? For example, the facade provides a 'GetX' from a tree, and each node needs to GetX from its subtree. Should this node use the facade's 'GetX'?
  2. Should the facade expose core objects to the application? E.g., the user wants to build a tree, add nodes, print the tree, calculate things on it etc. Should the application use the tree object or should it ask the facade to create it, save it, pring it etc.?

Thanks.

Nir Alfasi
  • 53,191
  • 11
  • 86
  • 129
Noich
  • 14,631
  • 15
  • 62
  • 90

3 Answers3

1

A facade is an object that provides a simplified interface to a larger body of code.

Therefore, keep it simple.

  1. No. Encapsulate the Facade within itself. I assume you have a private implementation for retrieving the tree, use this internally, exposing only the public method which returns the populated object (see point 2).

  2. No. The facade should do everything, otherwise there is little point creating it. You might want to create a DTO that can be used within the facade methods, but you should not expose the core objects.

ChrisBint
  • 12,773
  • 6
  • 40
  • 62
  • 2. HeadFirst mentions that the facade simplifies but still leaves the inner details accessible to users. Won't I get a C-like code if I have to do everything by the facade? E.G: Create tree, add node, get the tree print, translate the tree to XML etc.? If I'm exposing the tree anyway (by creating it), shouldn't the user be able to use its functionality? – Noich Aug 16 '12 at 06:25
  • 1
    Well. You probably do not need a facade if you want access to the details. – jgauffin Aug 16 '12 at 13:37
  • Just quoting. I was thinking that we should wrap our core so that it won't be coupled with our application layer (we might have to provide that core to other apps too). What I had in mind was that we should have some API that will provide functionalities such as 'get tree' and will return a tree that the application can work with. Can you please explain what is wrong in this notion? – Noich Aug 19 '12 at 05:35
1

Concerning question 1: As others have said; No. Instead, consider using a separate interface for this operation (the interface segregation principle may be applicable here?), and access the operations on that interface via the Facade first. Upon recursion, the inner interface can be used again directly. This might provide some separation of concerns, while also making it easier to change the implementation later if necessary.

It sounds to me as if the recursion itself is an implementation-detail, and not something the facade needs to know anything about. Similarly, the facade is something that the implementing algorithm does not need to know about (ie, dont recur via the facade).

Concerning question 2: How about defining interfaces for this as well? E.g. ITree, ITreeNode, etc, and include operations on the Facade to work with these. Now make the implementation implement these interfaces, thus providing the objects needed outside the facade without exposing the core objects.

Kjartan
  • 18,591
  • 15
  • 71
  • 96
0

A facade usually wraps your core and give access to a specific set of function.

  1. you might want to do that for consistency but if there is another easier way that preserve the abstraction provided by the facade it would be better.

  2. No none of your core code should be exposed ( that would defy the purpose of the facade there) If you want to add some functionality, then add a function to your facade that will call the core functions inside your facade.

MimiEAM
  • 2,505
  • 1
  • 26
  • 28