If a method is not going to modify anything and a command is not going to return anything, then there is another simple called the Principle of least surprise. This often turns out to be nice to rely on this. Otherwise the alternative can be a nasty surprise violating the Principle of Least Surprise in software development.
It is a classic object oriented design principle for methods that states: a command method that performs an action (updating, coordinating, …), often has side effects such as changing the state of objects, and is void (no return value); or a query that returns data to the caller and has no side effectsit should not permanently change the state of any objects Butand this is the key pointa method should not be both.
When there are alternative design choices, take a closer look at the cohesion and coupling implications of the alternatives, and possibly at the future evolution pressures on the alternatives. Choose an alternative with good cohesion, coupling, and stability in the presence of likely future changes.
When coding, program at least some Start Up initialization first. But during OO design modeling, consider the Start Up initialization design last, after you have discovered what really needs to be created and initialized. Then, design the initialization to support the needs of other use case realizations.
The use case suggests the system operations which noted in operation contracts written against each system event in the System Sequence Diagrams.
A use-case realization describes how a particular use case is realized within the Design Model, in terms of collaborating objects" [RUP].