Skip to main content
11 events
when toggle format what by license comment
May 13, 2014 at 22:35 vote accept Ashitaka
May 13, 2014 at 22:35 comment added Ashitaka You cleared my mind regarding this code. I feel a little more confident now. Thanks!
May 13, 2014 at 21:44 comment added valenterry Sure, it does not use the sourceControlSystem. But having a required parameter SourceControlSystem does not mean that the argument will directly be used. It rather means that the class/method is somehow dependent on it. Sure, you can use a global variable or global singleton but this will just shift the dependency from an explicit parameter to the implicit global context. But if you don't like passing something to object that does not use it directly, no problem: just create the churn before the turbolence and pass it to the turbolence with the SourceControlSystem already in it
May 13, 2014 at 20:50 comment added Ashitaka I find it cumbersome to pass data to some class that doesn't use that data for anything. It bugs me that Turbulence holds an instance variable for naught. I guess that the lifetime of a Turbulence object isn't that long, after calculating some data, the object is discarded. So I guess that unused instance variable doesn't last long. I'm still a novice at designing a program architecture, so I guess this which you find ok, shouldn't bug me at all :)
May 13, 2014 at 19:39 comment added valenterry Yes that is a bad design choice. It makes it much harder to reason about what a code is doing in doing in the very moment it is executed. It takes more effort to unittest it. It is less extensible, more difficult to maintain. I think you can find the drawbacks yourself. Passing it through several classes is fine. What problems do you see with that approach?
May 13, 2014 at 17:58 comment added Ashitaka So, in your opinion having a globally accessible object like SourceControlSystem is a bad design choice? That way I wouldn't have to pass it around through several classes. But that would hide the fact that Churn needs a SourceControlSystem.
May 13, 2014 at 17:56 comment added Ashitaka Yeah, I thought about injecting Churn like you are suggesting. However, if I did that, then Turbulence would mostly be an empty class. And like you said, then Churn would have to be instantiated somewhere else. Some other class would have to know how to instantiate Churn so the problem would still persist.
May 13, 2014 at 17:25 comment added valenterry But as it is managing it's churn it needs to create the churn. And to do so it must pass over the SCS. If you want to be even more clean you can pass the churn to the turbulence in the moment it is created. If you can't because the turbulence has to do something before we know the (correct) churn to pass it to the turbulence then you are violating the SRP and you should consider splitting the Turbulence class. However at some point there must be a managing class knowing what a churn is and how to create it. You can't get around it unless you make the state/parameters implicit.
May 13, 2014 at 16:50 comment added Ashitaka But the thing is, Turbulence itself does not need access to SourceControlSystem. Only Churn. The problem is that Churn is only created inside Turbulence. So I have to pass SourceControlSystem to Turbulence so it can pass it in turn to Churn.
May 13, 2014 at 16:48 history edited valenterry CC BY-SA 3.0
deleted 1 character in body
May 13, 2014 at 16:43 history answered valenterry CC BY-SA 3.0