.jpg)
It’s 2016 and guess who just turned 20 years old? Extreme Programming! You might not have thought it was around that long but Ron Jeffries in his “XP at 20” webpages assures us we can start counting from the year 1996. You might remember the first book on XP was published in October 1999, but Kent Beck was actually putting the ideas behind XP into practice three years before that.
2016 – 1999 + 3 = 20. So XP is 20.
In this article we will focus on one of the four values of Extreme Programming, namely simplicity. We’ll explore how far we can stretch that concept and try to apply it to one of the more recent UI design patterns, the Model-View-Presenter.
Nothing like the present
One of the thrusts of XP has always been simplicity. XP’s particular brand of simplicity is supported by the observation that developers are about as lousy at anticipating future user requirements as users are at describing their current ones. Therefore, the well-meaning attempts of developers to speculatively build features today in the hope of minimizing their context switching tomorrow, wind up costing them more time than they save. The advice from XP is to pursue simplicity through restraint – write software to the current needs of the users only, and avoid developing features that aren’t explicitly required now.
As the popularity of the simplicity value of XP has grown, the aphorism “You Ain’t Gonna Need It” or YAGNI has emerged to reinforce it. As a motto, YAGNI can stretch the simplicity objective beyond the classic forward-engineering scenario to the refactoring of existing software. The idea of “not required now” includes features that may be needed in the future (“not yet required”) but also those that had been at one time in the past (“no longer required”). YAGNI also applies to design so we ensure it also is a fit for the required features: we avoid overengineering and don’t add or keep layers of abstraction that aren’t necessary.
In object-oriented languages, this striving for simplification is a good counterbalance for patterns. Patterns enable us to develop infinitely complex technical classes and give them the illusion of meaningful purpose using a standardized domain-neutral naming. Two developers with a good understanding of patterns could both be tasked to write an ObserverVisitorFactoryFactorySingleton and both will probably write very similar code. This code can be written, moreover, without having to answer the question if such an over-engineered construct is actually needed. YAGNI has a neat role to play.
Simplifying features to patterns
If we can use YAGNI during refactoring to simplify designs so they support only the required features, is there also an opportunity to simplify our patterns to support only those features used by our designs?
Let’s take MVP. To recap briefly, MVP improves the older MVC UI pattern by dumbing down the view’s responsibilities to layout and event handling. The benefit is the separation of UI framework APIs from the presentation logic, which leads to:
- Understandability of the operations of the interface in business-oriented terms (like “add customer”) in addition to the events of the interface in API terms (like “OnClick”);
- Improved testability of the presentation logic;
- Presenter’s indirect dependency on the view implementation and, by extension, the UI framework involved.
The standard template for MVP allows us to reap all of these benefits also in Vaadin applications. If we choose the right names for the presenter methods, remove from our views as much logic as we can, keep the presenter clean of dependencies on items from the com.vaadin.ui package, and let the presenters push updates to view implementations through references typed as interfaces, these benefits can be realized. The problem we’re left with is that MVP takes a lot of work and discipline, both when developing systems anew and when refactoring. For applications containing many screens for which users have rapidly changing requirements, the extra work might make it hard to justify the investment.
But can YAGNI help us here? Can we identify parts of the pattern that we do not need in order to fit our requirements of understandability, testability, and indirect dependencies? One place we recently considered with a Vaadin customer was the area of multiplicities.
E pluribus
A part of the complexity of MVP is its support for many 1:n multiplicities. Obvious examples would be being able to place hundreds of components on one view layout, or to add hundreds of listeners to one single event. There are two cases in which the actual needs of many enterprise UIs do not exceed 1:1 multiplicity where MVP allows 1:n at the cost of increased complexity: the number of views per presenter and the number of population types per view.
The first category is the easiest to understand and implement. Instead of working with an observer-type “add listener” pattern to associate our presenter with n views, we can simplify with a setter if there is only one. With DI, the view will get its presenter autowired and then invoke something using “this” to make the presenter aware of the view(s) it needs to populate.
One example:
package com.generalbakeries.erp;
import ...;
abstract public class GeneralBakeriesPresenter
{
GeneralBakeriesDisplayable view = null;
public void setView(GeneralBakeriesDisplayable val) {
view = val;
}
abstract public void populate();
}
package com.generalbakeries.erp;
import ...;
@UIScope
@Controller
public class EmployeeListPresenter
extends GeneralBakeriesPresenter {
@Override
public void populate() {
view.display(EmployeeService.getEmployees());
}
}
package com.generalbakeries.erp;
import ...;
@UIScope
@SpringView(name = ...)
public class EmployeeListView
extends GeneralBakeriesView
implements GeneralBakeriesDisplayable {
@Autowired
EmployeeListPresenter presenter;
@PostConstruct
public void init() {
this.addComponents(...);
presenter.setView(this);
}
@Override
public void enter(ViewChangeListener.ViewChangeEvent vce) {
presenter.populate();
}
@Override
public void display(Employees emp) {
this.setContainerDataSource(cont);
}
}
The second is more nuanced and considers the asymmetry between the number of types of event data that originate in the interface and the number that originate in the server. Even simple views will support multiple components and will generate multiple events that need to be forwarded to the presenter. Simple views in business applications, on the other hand, can often be populated in one single way.
In MVP the mechanism we’re given to populate the view implementation is the view interface on which we can define as many methods as we want. If are able to simplify and reduce the number of methods to 1, then we actually no longer have a requirement to define a view-specific implementation and interface for each view. Instead, we can use one shared view interface containing one method with a parameterized type argument. Such a base interface could be simplified to the following:
package com.generalbakeries.erp;
public interface GeneralBakeriesDisplayable<T> {
void display(T dType);
}
If our UI contains a header, sidebar, footer, and a body, and the body is the container for our view navigation, and if our views are simple, a large portion of our UI could be composed of implementations of this interface. The samples below show how this would look for a view that shows a list of employee data and one that shows a single employee detail. Differences between the two are highlighted in bold:
package com.generalbakeries.erp;
import ...;
@UIScope
@SpringView(name = ...)
public class EmployeeListView
extends GeneralBakeriesView
implements GeneralBakeriesDisplayable<Employee[]> {
@Autowired
EmployeeListPresenter presenter;
@PostConstruct
public void init() {
this.addComponents(...);
presenter.setView(this);
}
@Override
public void enter(ViewChangeListener.ViewChangeEvent vce) {
presenter.populate();
}
@Override
public void display(Employee[] emp) {
...
}
}
package com.generalbakeries.erp;
import ...;
@UIScope
@SpringView(name = ...)
public class EmployeeDetailView
extends GeneralBakeriesView
implements GeneralBakeriesDisplayable<Employee> {
@Autowired
EmployeeDetailPresenter presenter;
@PostConstruct
public void init() {
this.addComponents(...);
presenter.setView(this);
}
@Override
public void enter(ViewChangeListener.ViewChangeEvent vce) {
presenter.populate();
}
@Override
public void display(Employee emp) {
...
}
}
The presenters would look as follows:
package com.generalbakeries.erp;
import ...;
@UIScope
@Controller
public class EmployeeListPresenter
extends GeneralBakeriesPresenter {
@Override
public void populate() {
view.<Employee[]>display(EmployeeService.getEmployees());
}
}
package com.generalbakeries.erp;
import ...;
@UIScope
@Controller
public class EmployeeDetailPresenter
extends GeneralBakeriesPresenter {
@Override
public void populate() {
view.<Employee>display(EmployeeService.getEmployee(..));
}
}
The knowledge whether a view has a single or multi-method interface will often only be needed by the presenter, so complexity can be added or removed as needed without impacting the other parts of the system. And if views start out simple, the single-method implementation will actually reinforce simplistic thinking.
By simplifying the patterns wherever possible so to minimize the number of classes and also providing support for views to be addressable indirectly through single-method interfaces, we are implementing and encouraging the fourth rule of XP Simple Design. This rule is to minimize the number of classes and methods. By following this rule we expect to achieve more agility and better quality software.