Timeline for Do I have to stop using Dependency Injection to keep object debug printouts small?
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 2, 2016 at 21:34 | vote | accept | Dennis | ||
| Mar 2, 2016 at 5:23 | comment | added | Doc Brown |
@Dennis: the question you have to ask yourself is: does the class Small contain something you want to unit test, decoupled from the database? If yes, you should inject a factory into Small. If there is no need to unit test the class, aa the purpose of Small might be simply to provide the method getData, then a SmallFactory might be the better choice.
|
|
| Mar 1, 2016 at 23:09 | comment | added | Dennis |
@Doc, what do you think of inverting control entirely and have a Factory Method for Small instead, where SmallFactory instantiates the Small object, populates with data gotten via BigTerribleDatabaseObject, and then returns a clean lean populated Small object to the caller?
|
|
| Mar 1, 2016 at 22:52 | comment | added | Dennis |
BigTerribleDatabaseObject in my case is Doctrine's EntityManager library class. Can't change it, it's not mine, but when printing it out is causes much havoc, sometimes flooding the screen with useless to me information, or even breaking the browser for whatever reason (either it is just too big or there is recursion somewhere or a memory leak when trying to print it out)
|
|
| Mar 1, 2016 at 22:02 | history | edited | Doc Brown | CC BY-SA 3.0 |
deleted 66 characters in body
|
| Mar 1, 2016 at 21:58 | comment | added | Doc Brown |
@DavidPacker: I guess the whole point of the question is that BigTerribleDatabaseObject might not be easily split into smaller objects (though, if possible, that would probably be a good idea). However, just splitting the big object into smaller ones alone won't decouple the class from the database.
|
|
| Mar 1, 2016 at 21:42 | comment | added | Andy |
@Dennis You don't have to use factory per se. You can instead to choose the path of fixing the design of your BigTerribleDatabaseObject, split it into several smaller, more specific, classes. Still, Doc Brown is right that there's something fundamentally wrong with your current design which is more than ready for refactoring.
|
|
| Mar 1, 2016 at 21:30 | comment | added | Dennis |
thanks. What you are suggesting then is just to keep using DI but use a Factory instead exposing the factory but hiding the big object behind it. Also I have changed my class name to just Small realizing that it was too much to read. Plus, less letters -> easier to spot which one was smaller
|
|
| Mar 1, 2016 at 20:37 | history | edited | Doc Brown | CC BY-SA 3.0 |
added 387 characters in body
|
| Mar 1, 2016 at 20:25 | history | answered | Doc Brown | CC BY-SA 3.0 |