If the problem domain naturally maps to OO approach, then programming it as such is reasonable. On the other hand, if the problem, or its understanding at prese

If the problem domain naturally maps to OO approach, then programming it as such is reasonable. On the other hand, if the problem, or its understanding at present stage, is not OO (for example not much functional relations, but tons of properties and states), then forcing it into OO implementation in not going to bring any of the promised benefits, but most of the overhead. Alternatively, spending a lot of lead time doing OO analysis in such cases is more like premature optimization. Instead, if the problem does not appear obviously OO, just implement it as procedural/structural, but implement it properly trying to keep the scopes and states as limited as needed. If a better model, perhaps OO, could emerge from such implementation, then it could be applied in the next iteration.