Paul Clapham wrote:If you have an informal architecture like that, then yes, it doesn't really matter how you structure things.
Paul Clapham wrote:So (for example) any code can add a new Status object to the list at any time?
Paul Clapham wrote:And therefore the question is "What is the intent of your StatusList class?"
We are not suggesting that every use of Map be encapsulated in this form. Rather, we are advising you not to pass Map s (or any other interface at a boundary) around your system. If you use a boundary interface like Map , keep it inside the class, or close family of classes, where it is used. Avoid returning it from, or accepting it as an argument to, public APIs.
The error page mechanism described does not intervene when errors occur when invoked using the RequestDispatcher or filter.doFilter method. In this way, a filter or servlet using the RequestDispatcher has the opportunity to handle errors generated.
Bear Bibeault wrote:The first two will be handled by whatever's installed as the ROOT web app. So no surprise that they're different from the last, which is handled by your web app.
Jesper de Jong wrote:I would say yes - why make an abstract class when it's not necessary? That only adds code, making your program longer and more complex for no benefit.
Sometimes it is beneficial to provide an abstract class, especially if you want a default implementation for some of the methods of the interface. If you then make multiple concrete classes that have to implement the interface, you can make those extend the abstract class, so that they inherit the implementation of the methods from the abstract class.