Design – How to handle assumptions while designing any system

designdesign-patternsobject-oriented-design

I have been going through various system design examples to understand how we approach any system design question.
Here is what I have understood till now.

Know the system first and find out how it works.
Think of all use case.
Identify key components and their responsibilities.
Connect all the components so that they can communicate to each other.
Use all standard practices while integrating components and if possible use standard design patterns.

Sometimes we make assumptions about the system, so those assumptions should be used to remove one use case or to add a variation.

I will put this question in context of Parking Lot design.

If I assume that Parking Lot is not commercial, and it is free parking lot, then design of parking lot should handle free parking lot as one of use cases , and it should be generic. OR Simply design parking lot which will never work for Commercial parking lot.

Main idea is that if someone asks you to design a parking lot and that is free parking lot, then design should be generic or specific?

Best Answer

Personally, I'm a big fan of YAGNI - (you ain't gonna need it).

Designing the general solution is hard.

The general rule I've seen (but naturally can't find a link to when I want it) is

Write the first block of code to solve the problem.
When you see a second instance of the problem, copy the first code & make changes to suit.
When you see a third instance of the problem, refactor to a general solution.

You might find the story about the Object Toaster useful reading. It's a cautionary tale about the dangers of over thinking a problem.

Related Solutions

Java Simulation – Designing Parking Simulation Software

I agree fully to you, for the given task, introducing a Vehicle class IMHO does not make much sense. It could make sense in the future, assumed you need to record more information about cars than currently requested, but when someone tells me to write "production ready" code, I would stick as near to the YAGNI principle as possible and would not design any features not requested yet.

To how "other people" might interpret the task: I have seen examples of Vehicle and Car in so many introductory OO examples, especially for introducing the concept of inheritance, that I am pretty sure lots of devs who read the requirement description half-way through are tempted to shoehorn the problem into the Vehicle/Car abstraction they have learned earlier ago.

IMHO that's a form of "programming by conincidence", something which is mentioned in the book "The Pragmatic Programmer" as a kind of anti-pattern.

Design – How to allow for custom Rules in a Entity Component System designed game engine

To begin with, a caveat: even more than other domains of programming, every design decision in game development is a tradeoff. The "right" answer is "whatever works for the game you are making."

Okay. There are a few approaches we can take:

If there are a small, known set of general behaviors, write them inline and allow the user to tweak parameters. (i.e., which enemies does this tower avoid, how far away does it need to be, etc.) This is the most straightforward and maintainable approach, but it scales poorly the more different behaviors you have.
Functions can be data! In C, this is a function pointer, other languages have equivalents. The code that creates the entity is responsible for giving it a function telling it how to act.

In C it'd look something like this:

// Define a function pointer type.
typedef void BehaviorFunc(Entity * this);

struct FooComponent {
    BehaviorFunc * my_behavior;
    // Other data as needed...
}

// User code:
void MyBehaviorFunc(Entity * this) {
    DoTheThing();
}
// ...
{
    FooComponent * f = AddFooComponent();
    f->my_behavior = MyBehaviorFunc;
}

// Update:
void UpdateFooComponent(FooComponent * f) {
    // stuff
    f->my_behavior(GetEntityFromComponent(f));
    // more stuff
}

We actually have other options here as well. If you need to allow non-programmers to define behaviors, you could replace the function pointer with a behavior tree, compiled script code, etc. All of these are much more complicated, though, so don't bother unless you actually need the extra flexibility. Keep in mind that the more general you make the system, the harder it is to implement (and optimize), for both the engine and client code.

Related Topic

Java – Cache vs DB design decision