Skip to main content

Timeline for Whether and how to test façades

Current License: CC BY-SA 3.0

8 events
when toggle format what by license comment
Nov 3, 2016 at 2:44 history tweeted twitter.com/StackSoftEng/status/794007424122449920
Nov 2, 2016 at 9:08 comment added Hugo G Hi @Rogério and thanks for the answer. Feel free to make it a real answer (instead of comment). I agree in that most classes in my layers system do nothing but passing things around, but I found that to be the only way of creating reliable packages and interfaces. For example, my *Manager classes contain lots of logic and many methods meant for other managers, whereas the *Service classes are a filtered view on the managers. My view classes only access the *Service classes. This layer-based abstraction gives me more flexibility than Java interfaces.
Nov 1, 2016 at 18:58 comment added Rogério I would say the real problem here is having those "facades" in the first place. A proper "Facade" (as described in the Design Patterns/GoF book) exists to provide a simpler, smaller API to a pre-existing external API which is more complex than what the application needs. When it's just a do-nothing class containing methods that simply delegate to another application class, then it's an anti-pattern. Eliminate it and then the issue of testing the facade will also go away.
Nov 1, 2016 at 17:28 history edited Tulains Córdova CC BY-SA 3.0
added 3 characters in body; edited title
Oct 31, 2016 at 21:34 history migrated from codereview.stackexchange.com (revisions)
Oct 31, 2016 at 20:03 answer added oopexpert timeline score: 3
Oct 31, 2016 at 18:00 answer added donlys timeline score: 0
Oct 31, 2016 at 11:27 history asked Hugo G CC BY-SA 3.0