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 |