I always hear things about that each method should only do one job. But lets say I got Update() method in my game that updates entities state, path finding, player position, etc. Should I refactor that method into separate methods like UpdateAI(); UpdatePlayer(); UpdateWorld(), etc.? I know that mostly it depends on me, but I want to know the best practice.
2
-
3\$\begingroup\$ Yeah that rule is more or less something taught to beginner programmers. While it sounds smart in terms of writing scripts the fact is in real programs there is a lot to do. I find it's better to interpret "One job per method" as "keep it short and make calls to other methods when appropriate". \$\endgroup\$Benjamin Danger Johnson– Benjamin Danger Johnson2013-05-09 23:15:33 +00:00Commented May 9, 2013 at 23:15
-
\$\begingroup\$ A key concept is how concisely you can describe everything a particular method does in its name. When the name runs to more than 5 or 6 syllables, consider making it two methods. \$\endgroup\$Pieter Geerkens– Pieter Geerkens2013-05-10 02:33:43 +00:00Commented May 10, 2013 at 2:33
Add a comment
|
1 Answer
\$\begingroup\$
\$\endgroup\$
0
No. Regardless of whether or not that rule is sound you have to remember that "one job" can have different scopes. "Update" is one job - updating the (whole) logic of your application each frame. But this task consists of several smaller tasks, like the ones you mentioned - "updating AI", "updating player" and so on. They can, of course, consist of further subtasks. That's why you usually call some functions that do smaller tasks in another function that is responsible for a bigger task. (Of course, you can also have some additional code (not function calls) in that function, too.)
