Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Here's what I'd do:</p> <p>start with the basics:</p> <pre><code>class Car {}; </code></pre> <p>and then extend on it as needed.</p> <p>The thing is, so far, there are no further requirements. There is no requirement that the car <em>uses</em> the different components for anything, so I leave them out for now. We just have to be able to create a car with specific components. But until we know what these components are supposed to <em>do</em>, there's no reason to make them anything more than a comment:</p> <pre><code>// create a car using engine A and gearbox B Car car1; // create one with engine C and electrical D Car car2; </code></pre> <p>And there we are. This is my design. Given this starting point, it takes very little code to extend the system when you come up with more requirements. There is virtually nothing that can break, or require rewrites when the requirements change. It is simple and clean.</p> <p>So for now, I conclude that this is the ideal design matching your requirements. It is far more robust, far more efficient and far less likely to contain bugs than your big inheritance hierarchy. And it is one hundred percent reusable code too.</p> <p>As you've probably gathered from my comments under your question, good design depends on context. There is no good design for "cars" in the abstract.</p> <p>But we can come up with good designs for "cars for a racing game", or "a system for managing a car factory", or for "displaying the status of various properties of a car (doors open or closed, current speed, fuel level, unfastened seatbelts)."</p> <p>The design doesn't depend on what <strong>objects</strong> you're modelling, but on <strong>what you want to do with them</strong>. And from your description so far, the purpose of the objects is nothing, except to be there. So I suggest a model where the cars <em>are there</em> and nothing else.</p> <p>The best design is not the one that best describes some physical object, but the one that best allows your application to do what it is supposed to do. </p> <p>And if all your application is supposed to do is "have a car", then the model becomes pretty simple.</p>
 

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