Note that there are some explanatory texts on larger screens.

plurals
  1. POMy poor design and abundance of getters
    text
    copied!<p>I am facing a rather annoying software design problem which has been troubling me for quite some time now. The problem is the initialization of an object and that a lot of getters are used to achieve that. I bumped into an article of Allen Holub [1] about why a lot of getters and setters usually indicate poor design. I listed several other articles below which also discuss this design issue.</p> <p>Now concerning my problem. I am currently working on a fluid simulation. I have a Simulation class which contains the functions and variables relevant for simulating a fluid. At first, this class had only one public function called timeStep() which executes a time step of the simulation. Now, I want to simulate several well-known flows, one could see them as scenario's. This usually boils down to correctly initializing the simulation. For example, I have the Taylor-Green vortex flow. The simulation does not need to know that it is simulating a particular flow, it only has to execute the simulation algorithm, so I created a separate class TaylorGreenVortex. The class TaylorGreenVortex has to initialize the Simulation in such a way that it corresponds to the Taylor-Green vortex flow. Now here comes the trouble: the initialization equations of the Taylor-Green vortex flow require many variables that are also needed by Simulation and therefore are present in that class. So, the result is that I added a lot of getters to the Simulation class to obtain these variables. This is however also undesired, because all these getters makes the Simulation class very exposed and also generates high coupling between Simulation and TaylorGreenVortex. In addition, it is also annoying that the initializer (TaylorGreenVortex) first constructs a Simulation object, so it can get the relevant variables, and then later resets other variables of the Simulation object so that it will simulate a Taylor-Green vortex flow.</p> <p>I have thought about several solutions, but all of these solutions do not really solve the problem, but merely shift the problem to a different class or make the design even worse. For example, if I follow the 'information expert' pattern, then I should remove the TaylorGreenVortex class and move all its functionality to the Simulation class. This however makes the Simulation class bulky when the simulation has to support many different flows. I could also introduce some sort of Data class which has the variables required by both TaylorGreenVortex and Simulation, but then I have to add a lot of getters to this Data class so that Simulation and TaylorGreenVortex get the variables from Data. What are your suggestions for a clean solution? If you know of a particular design pattern related to the problem, could you please explain somewhat concretely how it can be applied in the above situation? Thanks in advance.</p> <ol> <li><a href="http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html" rel="nofollow">http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html</a></li> <li><a href="http://martinfowler.com/bliki/GetterEradicator.html" rel="nofollow">http://martinfowler.com/bliki/GetterEradicator.html</a></li> <li><a href="http://pragprog.com/articles/tell-dont-ask" rel="nofollow">http://pragprog.com/articles/tell-dont-ask</a></li> </ol>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload