Should a graphical user interface implement Propertychangelistener or it's objects?

Question

I was learning about design patterns and i came across a line where a domain object has to update it's view using observer design pattern.

In the book , Applying UML and design pattern, It says Let the gui object simply apear as an object which implement Propertychangelistener.

So my question is that is it a GUI that implements Propertychangelistener or shoud an object that resides in gui , that object should implement Propertychangelistener.

More concrete example: In the picture below i have different shapes. All of them has also a source in domain. Suppose coordinates of a shape change in the domain.

Sould a shape get notification or a main gui(GuiWindow)? This is a little bit confusing and there is also no example in book.

Answer 1

It depends entirely on how cluttered your UI object is and the type of work that needs to be done in the listener.

God objects

are bad. Don't use them. A UI object which implements many listeners and handles many diverse aspects of its controls can get bulky and what may initially be a single-responsibility class may become some grotesque god object doing many different things. In this case, the answer is no. Clearly you need to extend some of the functionality to utility classes in that case. Create a namespace or package for the express purpose of containing listeners and create a class for each handler until your god class turns into something of a demigod class at least.

That said, if you're handling a single property listener and the UI class is reasonably self-contained, nobody will frown at you for extending a simple interface for a simple listener.

God methods

are bad. Specifically listener methods performing many many complex operations. Even if the class which contains it is simple, I would create my own PropertyChangeListener implementation to deal with an action involving anything more complicated than opening a window or updating a button label.

If you find that this method requires many instances contained in your UI class, don't be afraid to pass the necessary instances to its constructor. If you wind up with many tedious low-level statements, consider creating helper classes which can simplify these calls into one single static method call. If you need to perform complex actions such as connecting to a database and performing a query, try to put dao operations into its own classes, and the listener would only need to call them.

Even with these considerations, should your method end up complicated and bulky, it makes an excellent candidate to be put into its own implementation and broken up into submethod calls. This allows you to free up your UI class, and it remains very much a single-responsibility class.

If you have any further questions, just ask in the comment section, and I'll respond as soon as I can.