立面图案结合观察者模式

Question

I got an assignment to find out exactly what the facade pattern is. I have googled and found out it is meant to shield a client from a very complex system by making an "interface". So I have a few questions, I have seen in multiple examples is they make an C# interface for the complex system, but I have also seen a few that used A class as the "Interface" (as seen here ). I can only make sense of it if it is a base class that simplifies a lot of different complex method calls to different classes as in (the bank example seen here )

1. So my first question is if I am correct that you would implement the "interface" as a class?

2. My other question then is, could you use facade pattern together with the observer pattern. The facade class would observe on all subjects and then control what methods in different classes should be called, depending on the subject?

---

Edit: As requsted I tried to make an example project with a facade for a observer pattern and here is the result:

public class Facade
{

    private Dictionary<ISubject, List<IObserver>> Subjects { get; set; }

    public Facade()
    {
        Subjects = new Dictionary<ISubject, List<IObserver>>();
    }

    public void AddObserverToSubject(ISubject sub,IObserver obs)
    {
        if (Subjects.ContainsKey(sub))
            Subjects[sub].Add(obs);
        else
        {
            List<IObserver> observers = new List<IObserver>();
            observers.Add(obs);
            Subjects.Add(sub, observers);
        }
        obs.Subject = sub;
    }

    public void DeleteObserverFromSubject(IObserver obs,ISubject subject)
    {
        Subjects[subject].Remove(obs);
    }
    public void Notify(ISubject subject)
    {
        foreach (var observer in Subjects[subject])
        {
            observer.Update();
        }

    }
}

public interface ISubject
{
    Facade Observers { get; set; }
    int GetState();
    void SetState(int state);
}

public interface IObserver
{
    ISubject Subject { get; set; }
    void Update();
    string Mood { get; }
}

So every observer will update their mood depending on what is going on with the subject.

I have made two implementations of IObserver and ISubject but I will only show one of each here.

public class TeacherObserver : IObserver
{
    public ISubject Subject { get; set; }
    private int _currentSalery = 500;
    public string Mood { get; private set; }
    public TeacherObserver()
    {
        Mood = "Happy";
    }


    public void Update()
    {
        var newSalery = Subject.GetState();
        if (_currentSalery < newSalery)
        {
            Mood = "Happy";
        }
        else
        {
            Mood = "Sad";
        }
        _currentSalery = newSalery;
    }
}

public class SalerySubject :ISubject
{
    public Facade Observers { get; set; }
    private int _salery;
    public int GetState()
    {
        return _salery;
    }

    public void SetState(int state)
    {
        _salery = state;
        Observers.Notify(this);
    }
}

So one thing I like about this is that the subject doesn't have to know about all the observers that is bound to it(this will be handled by the facade class now). But seeing from the clients view it is pretty much the same calls he would have to make:

class Program
{
    static void Main(string[] args)
    {
        Facade.Facade observer = new Facade.Facade();
        ISubject salery = new SalerySubject();
        IObserver teacher = new TeacherObserver();
        salery.Observers = observer;
        observer.AddObserverToSubject(salery,teacher);
        Console.WriteLine("Teacher is " + teacher.Mood);
        salery.SetState(100);
        Console.WriteLine("Teacher salery just went down. The teacher is now " + teacher.Mood);
    }
}

3. Which leads me to thinking that it doesn't really make sense to do it with a facade, as the whole point of the facade is to make it easier for the client right? (or hide information) or am I wrong?

Answer 1

I got an assignment to find out exactly what the facade pattern is

Facade is just yet another wrapper.
It wraps some entity, usually to hide some details from client.

if I am correct that you would implement the "interface" as a class?

Interface is a contract.

To implement this contract, you need a class (since we're talking about design patterns, I'm omitting structures discussion). In other words, you can't implement facade using interface only, because you need a class, where implementation logic will be placed, but interface could help you to make your components loosely coupled.

Actually, to use interface or not to use is unrelated to particular pattern.

could you use facade pattern together with the observer pattern

In theory - yes, you can. In practice - it depends.

Answer 2

I think the term 'interface' is used in different meanings. You have the general term of 'interface for something' to access it and you have the concret term 'c# interface definition' as part of that language. So i think, in your quote

to shield a client from a very complex system by making an "interface"

the first general meaning is used. And the question is how to build it:

1.So my first question is if I am correct that you would implement the "interface" as a class?

I would use both. First, i would create an c# interface to define the contract, then build a base class as reference implementation. If you use only a base class, then all other possible classes have to inherit from this and they get the implementation details only because they wanted the contract. If the other possible classes can use your interface, they only have to implement it, that means they have to provide the methods in the interface definition and have no link to each other.

2.My other question then is, could you use facade pattern together with the observer pattern. The facade class would observe on all subjects and then control what methods in different classes should be called, depending on the subject?

Yes you can, but then the observing behaviour with all it's classes is 'part' of the facade. If that is what you want, ok.

3.Which leads me to thinking that it doesn't really make sense to do it with a facade, as the whole point of the facade is to make it easier for the client right? (or hide information) or am I wrong?

I think it does make sense to have a facade for the purpose it is defined for, to interface the complex system behind it. Only if there is nothing then the observing behaviour, then there is no complexity to hide.

So may i suggest a little redesign like this:

I would implement ISubject with an event, because it doesn't need to know who is observing, it will simply notify:

public interface ISubject
{
    event EventHandler OnNotify;
}

and then create a second interface to give access to a salary:

public interface ISalerySubject: ISubject
{
    int Salery { get; set; }
}

The IObserver can hold a ISubject :

public interface IObserver
{
    ISubject Subject { get; set; }
}

Now lets get concrete. The class SalerySubject is implementing the interface ISalerySubject , so when the salery is changed the event is fired:

public class SalerySubject : ISalerySubject
{
    public event EventHandler OnNotify;

    private int salery;
    public int Salery
    {
        get { return salery; }
        set
        {
            salery = value;
            if (OnNotify != null) OnNotify(this, new EventArgs());
        }
    }

}

The class TeacherObserver is implementing the interface IObserver and it binds it's method Update to the event of ISubject :

public class TeacherObserver : IObserver
{
    private int _currentSalery = 500;
    public string Mood { get; private set; }

    public ISubject subject;
    public ISubject Subject
    {
        get { return subject; } 
        set
        {
            // Relase old event
            if (subject != null) subject.OnNotify -= Update;

            subject = value;

            // Connect new event
            if (subject != null) subject.OnNotify += Update;
        } 
    }

    public TeacherObserver()
    {
        Mood = "Happy";
    }


    public void Update(object sender, EventArgs e)
    {
        ISalerySubject SalerySubject = Subject as ISalerySubject;
        if (SalerySubject != null)
        {
            var newSalery = SalerySubject.Salery;
            if (_currentSalery < newSalery)
            {
                Mood = "Happy";
            }
            else
            {
                Mood = "Sad";
            }
            _currentSalery = newSalery;
        }
    }
}

Now you can use it:

class Program
{
    static void Main(string[] args)
    {
        ISalerySubject salery = new SalerySubject();
        TeacherObserver teacher = new TeacherObserver();
        teacher.Subject = salery;

        Console.WriteLine("Teacher is " + teacher.Mood);
        salery.Salery = 100 ;
        Console.WriteLine("Teacher salery just went down. The teacher is now " + teacher.Mood);
    }
}   

So, up to this point, there is no need for a facade. Maybe you want to keep a list of observers, but that normally is not stored in a facade. Maybe your system is far more complex, so then there is a good reason for a facade anyway.

Answer 3

The façade pattern is a structural design pattern. https://sourcemaking.com/design_patterns/facade

The façade acts to separate the underlying logic of an app (or model) from the user interface. It serves the purpose of separating concerns and assists in simplifying the use of the underlying class structures.

The façade itself is an abstract class that sets out the methods that can be implemented for that interface and how these methods connect to the underlying class structures of the model. The concrete implementation is the actual creation of the underlying model classes, into objects and using these object instances to run the program. All the while the processes of the underlying program logic is only called through the façade and is of no concern to the end user.

The observer pattern is a behavioural design pattern. https://sourcemaking.com/design_patterns/observer

The observer pattern links an object with all its dependencies. So when any change in the object is made, all the linked dependencies will also be affected by this change. It is one of the pattern used in MVC applications. The model/object maintains all the business logic; this is passed to the controller/observer. The controller then updates and maintains the views based on changes made by the user to the object.

The controller/observer separates the concerns, of the programming logic from the user, much as the façade separates it from the user. The controller/observer is inseparable from the model and view. It is reliant upon access to both to act as a layman's interpreter between the two, parsing the model logic into the user interface and vice versa.

---

To be honest, I haven't followed you example very well. I think you are confusing the idea of collections with design patterns.

Mixing the logic of the two, in my opinion, would be muddying the programming logic behind using either pattern. Although design patterns may not be clear cut, this is particular example that I cannot (off the top of my head) think of a useful application. If there are useful examples, I am sure someone will pipe up.

Answer 4

Yes, I agree with your understanding of facade - A Facade's intention is to provide a new & simplified interface (or access point or gateway) to a complex system. Or a unified interface to hide multiple sub-systems.

Now, I'll answer your questions one by one -

So my first question is if I am correct that you would implement the "interface" as a class?

When we use "interface" in context of facade, it refers to API , conveying a meaning of - point of interaction or point of contact . The facade acts as point of contact between client & complex system.

Now, how to implement the facade ? certainly you can use c# interface to define the functions, events, properties that the facade will expose to client. The actual wrapper will be a class realizing this interface .

Even if the complex system you are hiding is static, wrapping static system in a class realizing interface , will be helpful while implementing unit tests.

My other question then is, could you use facade pattern together with the observer pattern. The facade class would observe on all subjects and then control what methods in different classes should be called, depending on the subject?

From a scemantic purity point of view, a facade should only define new APIs on existing API of the wrapped sub-system.

If the system you are hiding needs a publisher-subscriber model, you would have to implement observer pattern in your facade, wrapping the publisher-subscriber calls of the sub-system.

However, don't add more responsibilities or logic to facade than needed to in the name of simplicity, think of it as a fairly simple advocate or facilitator for the sub-system, nothing more. It should not become an all-knowing "god" object.

Which leads me to thinking that it doesn't really make sense to do it with a facade, as the whole point of the facade is to make it easier for the client right? (or hide information) or am I wrong?

In your example, all this logic should not be in facade. I agree it'll make it easier for client, but its not built over the wrapped sub-system, its like an additional service the facade is offering. So take this out from facade into a separate class, the client can use that class to make its life easy.

If there is anything in a facade that you think can be taken out of facade, without exposing the sub-system, then that thing must be taken out of facade.

Hope it helps. Please write me a comment if any bit is unclear or you think I have missed any of your questions & we can take it from there.