Michael Swierczek wrote:I'm curious what you think of a possible design philosophy change in Java from making most interface methods contain default implementations, and override them only as necessary? This strikes me as a better way of getting code modularity and avoiding duplication than classic parent to child inheritance. I wonder whether that will become common in Java code going forward, and whether it is a good thing if it does.
Michael Swierczek wrote:Make eight interfaces with default method implementations. For the actual classes you want to create, do Class Foo implements Interface1, Interface2, Interface3, Interface4... and only override the behavior you need to change. Simplest design, smallest amount of duplicate code, but you don't have massive amounts of code sitting in just one class or one class hierarchy like you do with GiantMotherParentClass.
Michael Swierczek wrote:More specific example - our top level abstract parent class has methods for getting and setting our application-specific replacements/enhancements to ye olde HttpServletRequest and HttpServletResponse. Child level 1 attaches the current user account information. Child level 2 attaches localization hooks and validation layer. Child level 3 attaches output format handlers (our reports have six different possible output formats the user can select) plus conversion of HTML form input parameters into corresponding domain objects. Child level 4 adds the ability to save and load an entered report configuration. Child level 5 adds the specific database query logic for the date range of data this particular report family can draw upon, and some report-family-wide shared aspects of the SQL query for that report. Child level 6 adds the specific report name and title-builder, and creates the query-handler object using the domain objects from the input handler and the report-family-wide aspects of the query from the respective parents, plus of course it can override aspects of any of the parents when necessary.
Michael Swierczek wrote:I am miscommunicating something. The problem is that many dozens of non-homogeneous pieces of state need to be passed around. If you use a POJO, you've got a colossal POJO and another form of the same monster object problem that we already have. If you partition pieces of the data into smaller groups, you either need to pass them around in an HttpServletRequest attribute map, or something similar, right? Then you have the type-casting / instanceof problems. Right?