- Preventing Unnecessary Duplication
- Building a Panel
- Where Do We Go from Here?
Where Do We Go from Here?
Is this the best approach to designing your views? It’s definitely not the only way. But it’s the way that comes about most naturally by driving them through tests. It’s a lot more work to write tests against views that interact with the underlying domain. I view TDD as a protection against allowing logic to creep into the view, where it absolutely doesn’t belong.
Creating views in this fashion is also more flexible. You can do all you want with your view components without needing to actually deploy them into a live application. This can allow for very efficient layout programming and visual inspection.
We can execute the HoldEm application class and see what these views look like. We snuck in a bit of layout code in SeatPanel that puts the seat position above the player’s name. Otherwise, it’s not a very aesthetically pleasing application.
The aesthetics can always wait. More importantly, these Swing classes are not capable of effecting anything through their controller components. For example, if we push the Deal button, it does nothing. In the next installment, we’ll figure out how to make things happen.