There are several posts about the MVP¹ pattern (or whatever fancy name some authors use to call it
:wink:) and even more of them explaining what SOLID² stands for, so we will focus on:
- The contract between presenter and view
- Code reuse
Speaking of MVP and contracts, some developers should read this for goodness sake!
Time and again we are told that we must avoid repetition and redundancy because “the less code to maintain the better” but then we find ourselves typing almost the same interfaces over and over again an indefinite number of times.
It’s almost pseudo-code, but I’m sure it’s not the first time you’ve seen something like that
What can we do to follow the DRY principle mentioned above? Applying the Interface Segregation Principle. That’s it.
What do you think? From my point of view, among other benefits, it looks much cleaner, more refactor-friendly and certainly a better way to avoid monolithic interfaces with hundreds of methods.
Further information about these Sealed Classes is available here
It’s true that we haven’t gone into the details but I think the code fragments shown above are worth more than a thousand words
This article was originally published on Medium
 Model-View-Presenter (btw it’s impressive to know this architectural pattern is over 20 years old
 SOLID (the acronym is not used in its original paper so look for the reference to “the first five principles of class design” or even better go for a easier explanation)
 Don’t Repeat Yourself
 Keep It Short and Simple (politically correct variation)