+ 1
How do you guys think and plan when a exercise or task is infront of you? How do you break them down? Any basic tips?
Uni-student, Trying to solve problems by myself and to break loose from the "tutorial-spell".
2 Respuestas
+ 3
I think in terms of the following:
- What can be a method?
- What can be packed into classes / namespaces?
- Any other way of looking at something?
- Possible refactors?
Additionally, just continuing to solve problems allows you to become better at doing it in the future😁
You will also notice there are "patterns" in how to solve problems. I can't quite explain it, certain problems tend to repeat themselves in one way or another and you learn to see that
+ 2
Personally I think this is a bit of an intuitive thing, too. The solution just 'comes' to you. Maybe I'll make a few diagrams to check out my idea.
And this intuition is built up gradually by solving a lot of tasks, starting very simple, then gradually getting more tricky.
When the program is more complicated, identify the simple sub-tasks it consists of. Write and test these separately, for example as functions.
Apart from that, I'll try to make my code short and tidy. It has to be easy to read.
When the program is not so long, or you're basically only using one type of data, and it's not complicated, OOP will imo add unnecessary complexity - it doesn't really do anything.
In most cases, I'd use classes when I have at least two types of data that mustn't be messed up, that need to 'protect themselves' and control when or how data is accessed (the point of it all).