Timeline for Service-locator anti-pattern alternative
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 27, 2018 at 8:07 | vote | accept | smoksnes | ||
| Apr 29, 2016 at 16:18 | comment | added | smoksnes | If you are use TDD and want 100% code coverage abstraction is often the way to go. | |
| Apr 29, 2016 at 16:16 | comment | added | smoksnes | I agree. Some layers may not always be necessary. But in my point of view you should abstract for 3 reasons: scalability, responsibility, testability. | |
| Apr 29, 2016 at 15:38 | comment | added | Robert Harvey | Software developers seem to instinctively want to add additional layers of abstraction. The question you have to ask yourself is this: "what exactly am I abstracting, and what problem does that additional abstraction solve?" Also, "Does the benefit exceed the cost in terms of additional complexity and maintenance?" | |
| Apr 29, 2016 at 15:29 | history | tweeted | twitter.com/StackProgrammer/status/726070927344209920 | ||
| Apr 29, 2016 at 15:27 | comment | added | smoksnes | @RobertHarvey Good point. I added an actual factory that I use. But I really want to find a balance and know what's "good practice". But I guess it's really depends on the particular case... | |
| Apr 29, 2016 at 15:26 | history | edited | smoksnes | CC BY-SA 3.0 | added 1181 characters in body |
| Apr 29, 2016 at 15:00 | comment | added | Robert Harvey | Consider providing code samples that are more concrete than foobar. There's no way to meaningfully connect foobar examples to a specific, real-world problem that your technique solves. On another note, using factories to create mock objects sounds really overengineered, especially for a testing scenario. | |
| Apr 29, 2016 at 14:47 | answer | added | Andy | timeline score: 1 | |
| Apr 29, 2016 at 14:46 | answer | added | Telastyn | timeline score: 12 | |
| Apr 29, 2016 at 14:33 | history | edited | Robert Harvey | CC BY-SA 3.0 | deleted 22 characters in body |
| Apr 29, 2016 at 14:18 | comment | added | smoksnes | @CodesInChaos I've added some examples to when I use a factory. | |
| Apr 29, 2016 at 14:18 | history | edited | smoksnes | CC BY-SA 3.0 | Added explaination of why to use factory. |
| Apr 29, 2016 at 13:50 | history | edited | smoksnes | CC BY-SA 3.0 | added 257 characters in body |
| Apr 29, 2016 at 13:45 | comment | added | CodesInChaos | Injecting an instance already removes the creation of the object from your class. I'd only inject a factory if the class needs to create multiple instances with different parameters. | |
| Apr 29, 2016 at 13:44 | comment | added | smoksnes | @CodesInChaos good question. It's really just a way for me to abstract the creation of models in order to be able to create really testable code with 100% code-coverage. I find it easier to mock the objects if I abstract the creation of them. | |
| Apr 29, 2016 at 13:42 | comment | added | CodesInChaos | Why do you "usually use a factory"? In most cases you can simply inject an instance instead of a factory. And even if you need a factory, Func<IFoo> is already a factory, no need to wrap it in another class+interface. | |
| Apr 29, 2016 at 13:38 | history | asked | smoksnes | CC BY-SA 3.0 |