JSF was designed in part by the authors of Struts to create a "Struts" that did a more accurate implementation of MVC (Struts is technically "Model 2") and to get rid of all the interface and subclass dependencies. The idea being that POJOS are more re-usable and easier to unit-test offline than framework-dependent code. Which is why I chant endlessly:
The more JSF-specific code that is in your JSF webapp, the more likely it is that you're doing it wrong.
The other thing that the Struts folks didn't like about Struts was that you had to define too many classes for each component. In JSF, you define a view template file, a backing bean (model), and that's basically it. There's no separate "action" class to transition data in and out of the MVC part of the webapp, just POJO methods that are defined in the same class as the POJO model.
Tuesday, August 15, 2017
Tuesday, November 29, 2016
Large, complex private methods are a code smell. An implementation which is so complex that it cannot be usefully decomposed into component parts (with public interfaces) is a problem in testability that reveals potential design and architectural problems. The 1% of cases where the private code is huge will usually benefit from rework to decompose and expose. – S.Lott Feb 14 '12 at 20:06http://softwareengineering.stackexchange.com/questions/135047/new-to-tdd-should-i-avoid-private-methods-now#comment253312_135049
Wednesday, October 12, 2016
...a suite of tests is run, optimized to execute very quickly. We refer to this suite of tests as commit stage tests rather than unit tests, it is useful to include a small selection of tests of other types at this stage...
Begin the design of your commit test suite by running all unit tests. Later, as you learn more about what types of failure are common in acceptance test runs ... you should add specific tests to your commit test suite to try and find them early on.
Acceptance tests written without developer involvement also tend to be tightly coupled to the UI and thus brittle and badly factored, because the testers don't have any insight into the UI's underlying design and lack the skills to create abstraction layers or run acceptance tests against a public API.
- Continuous Delivery
- Jez Humble, 2011
Friday, September 16, 2016
The desire to achieve flexibility may lead to the common antipattern of "ultimate configurability" which is, all too frequently, stated as a requirement for software projects. It is at best unhelpful, and at worst, this one requirement can kill a project.Continuous Delivery - Addison-Wesley 2012 p. 40
Friday, August 12, 2016
Where closures go beyond lambdas is that they bind or "close over" variables that are not explicitly defined in the closure's scope.http://dublintech.blogspot.com/2014/05/groovy-closures-this-owner-delegate.html
Tuesday, August 9, 2016
Favor complex network of simple objects over a simple network of complex objectshttp://stackoverflow.com/a/2947823
That's one more voice in favor of the "tiny pieces" method of breaking down applications.
Monday, August 8, 2016
Now, this isn't to say that you can never use new manually -- but you should reserve that for value-type objects that don't have external dependencies. (And in those cases, I'd argue that you're often better off with a static factory method than a public constructor anyway, but that's beside the point.)http://stackoverflow.com/a/28749192