Facade combined with an observer pattern

I have a task to find out what a facade template is. I found googled and found out that it is designed to protect the client from a very complex system by creating an “interface”. So I have a few questions that I saw in a few examples: they create a C # interface for a complex system, but I also saw a few that used class A as the “interface” (as seen here ). I can only understand this if it is a base class that simplifies many different calls to complex methods for different classes, as in (example in the bank here )

  • So, my first question is: are you implementing the “interface” correctly as a class?

  • Then my other question is: can you use the facade template along with the observer template. The facade class will be observed in all subjects, and then control which methods in different classes should be called, depending on the subject?


Edit: as required to prove, I tried to create an example project with a facade for the observer template, 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; } } 

Therefore, each observer will update his mood, depending on what is happening with the object.

I made two implementations of IObserver and ISubject, but I will show only one of them.

 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 that I like about this is that the subject does not need to know about all the observers that are attached to it (now this will be handled by the facade class). But, seeing the eyes of customers, these are almost the same calls that he should have made:

 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); } } 
  1. What makes me think that there really is no point in doing this with the facade, since the whole point of the facade is to make it easier for the client? (or hide information), or am I wrong?
+5
source share
4 answers

I think the term "interface" is used in different meanings. You have the general term “interface for something” to access it, and you have the understandable term “C # interface definition” as part of this language. So what I think in your quote

to protect the client from a very complex system by creating an “interface”

the first common value is used. And the question is how to build it:

1. So, my first question is: are you implementing the “interface” correctly as a class?

I would use both. First, I would create a C # interface to define a contract, and then build a base class as a reference implementation. If you use only the base class, then all other possible classes should inherit from this, and they receive implementation details only because they want a contract. If other possible classes can use your interface, they only need to implement it, that is, they must provide methods in the definition of the interface and have no connection with each other.

2. My other question then, could you use the facade template along with the observer template. The facade class will be observed at all and then control which methods in different classes should be dependent on the object?

Yes, you can, but then observational behavior with all its classes is a “part” of the facade. If this is what you want, good.

3. Why does it make me think that there really is no point in doing this with the facade, since the whole point of the facade is to make it easier for the client? (or hide information), or am I wrong?

I think it makes sense to have a facade for the purpose for which it is defined, in order to link a complex system behind it. Only if there is nothing but observational behavior, then there is no difficulty to hide.

So, I can offer a small redesign as follows:

I would execute an ISubject with the event, because it does not need to know who is watching, it will just notify:

 public interface ISubject { event EventHandler OnNotify; } 

and then create a second interface for salary access:

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

IObserver may contain an ISubject :

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

Now let's get specific. The SalerySubject class implements the ISalerySubject interface, so when the salon changes, 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 TeacherObserver class implements the IObserver interface and binds its Update method to the ISubject event:

 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. You might want to keep a list of watchers, but this is usually not stored on the facade. Perhaps your system is much more complex, so there is a good reason for the façade anyway.

+2
source

I have a task to find out what a facade template is.

The facade is another shell.
It wraps some kind of object, usually to hide some details from the client.

if I'm right, what would you implement an “interface” as a class?

An interface is a contract.

To implement this contract, you need a class (since we are talking about design patterns, I am missing a discussion of the structure). In other words, you cannot implement a facade using only the interface, because you need a class where the implementation logic will be implemented, but the interface can help you easily link your components.

Actually, to use the interface or not to use is not related to a specific template.

Can I use the facade template with the observer template

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

+2
source

The facade template is a structural design template. https://sourcemaking.com/design_patterns/facade

The façade acts to separate the underlying logic of the application (or model) from the user interface. It serves to separate problems and helps simplify the use of basic class structures.

The facade itself is an abstract class, which sets out the methods that can be implemented for this interface, and how these methods are connected to the basic structures of the model classes. A concrete implementation is the actual creation of base classes of models, objects and the use of these object instances to run the program. All the time, the processes of the basic logic of the program are called only through the facade and have no relation to the end user.

enter image description here

The observer pattern is a pattern of behavior. https://sourcemaking.com/design_patterns/observer

The observer pattern associates an object with all its dependencies. Thus, with any changes in the object, all related dependencies will also be affected by this change. This is one of the patterns used in MVC applications. The model / object supports all business logic; this is transmitted to the controller / supervisor. The controller then updates and maintains the views based on the changes made by the user to the object.

The controller / observer separates the problems from the programming logic from the user, since the facade separates them from the user. The controller / observer is inseparable from the model and view. It depends on access as acting as an interpreter of laymans between them, analyzing the logic of the model in the user interface, and vice versa.

enter image description here


Honestly, I did not follow you very well. I think you mix the idea of ​​collections with design templates.

Mixing the logic of the two, in my opinion, would be dirty programming logic using any template. Although design patterns may be fuzzy, this is, in particular, an example of how I cannot (head to toe) think of a useful application. If there are useful examples, I'm sure someone will work.

+1
source

Yes, I agree with your understanding of the facade. The goal of the facade is to provide a new and simplified interface (or access point or gateway) to a complex system. Or a unified interface to hide several subsystems.

Now I will answer your questions one by one -

So, my first question is that I'm right, what are you "interface" as a class?

When we use the "interface" in the context of the facade, it refers to the API , passing the value of the interaction point or contact point. The façade acts as a point of contact between the client and the complex system.

Now, how to implement the facade? Of course, you can use the C # interface to define the functions, events, properties that the facade will expose to the client. The actual wrapper will be the class implementing this interface .

Even if the complex system you are hiding is static, wrapping the static system in a class implements the interface will be useful when doing unit tests.

Then my other question is: can you use the facade template along with the observer template. The facade class will be observed in all subjects and then control which methods in different classes should be called, depending on the object?

In terms of cleanliness with a satellite, a facade should only define new APIs for an existing wrapped subsystem API.

If the system you are hiding needs a subscriber-subscriber model, you will have to implement an observer pattern on your facade, wrapping the subscriber-subscriber calls of the subsystem.

However, do not add more responsibilities or logic to the facade than you need in the name of simplicity, think of it as a fairly simple lawyer or facilitator for the subsystem, nothing more. He should not become the all-knowing "divine" object.

This makes me think that there really is no point in doing this with the facade, since the whole point of the facade should make it easier for the client? (or hide information), or am I wrong?

In your example, all this logic should not be in the facade. I agree that this will make it easier for the client, but it is not built on top of the wrapped subsystem, as an additional service that the facade offers. So do it from the facade to a separate class, the client can use this class to make his life easy.

If there is something on the facade that, in your opinion, can be removed from the facade without exposing the subsystem, then this thing needs to be removed from the facade.

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

+1
source

Source: https://habr.com/ru/post/1236787/


All Articles