1

What would be a good approach to resume both the state & operation of an object?

For example, when transition to a particular state, the object will need to perform a certain operation.

The problem is when restoring the state directly via the object constructor: it is not a good practice to perform operation in the constructor. So at this point, only the state is restored, not the operation.

enum State { OPEN, CLOSED }

class Stuff {

    State state;
    Timer timer;
    Counter counter;

    Stuff(State state, Timer timer, Counter counter) {
        this.state = state;
        this.timer = timer;
        this.counter = counter;

        // It is not a good idea to call timer.start() here when the state = OPEN.
    }

    void open() {
        state = OPEN;
        timer.start();
        counter.reset();
    }

    void close() {
        state = CLOSED;
    }

}

When resuming the object operation, we could not simply call open. Because the counter will be reset and lose its initial value (the value that is provided in the constructor).

Pablo Espantoso
  • 416
  • 6
  • 13
  • Why performing operation in constructor is not a good practice? Especially in such case, where running timer is in fact part of object state? – bezet Aug 28 '17 at 12:05
  • Because it violates SRP. On practical level, for example you want to wait for other objects / components to be initialised before starting the timer of this object. – Pablo Espantoso Aug 28 '17 at 12:16
  • It does not(SRP talks about objects not functions). Your object needs timer, you passed it into constructor, so your object is free to do whatever it needs with it(also in constructor). – bezet Aug 28 '17 at 12:24
  • Also, regarding your example, environment and dependencies of an object shall be in exactly the same state they were when "snapshoting" state. So unless the original object was waiting for something, your restored object shall not wait for anything to restore it's internal state. Note that waiting for some resources in constructor is perfectly in line with RAII. – bezet Aug 28 '17 at 12:37
  • In Java you should not start threads in constructors because the constructor may not have terminated. See https://stackoverflow.com/questions/5623285/why-not-to-start-a-thread-in-the-constructor-how-to-terminate -- can you make a design such that the object that performs the restoring will then call the appropriate transition method? Having a model of your states and transitions will help, since, e.g. entering state A could be achieved via distinct transitions (from B or C). Perhaps you can use the [Memento pattern](https://en.wikipedia.org/wiki/Memento_pattern) and avoid the constructor? – Fuhrmanator Aug 29 '17 at 21:09
  • @Fuhrmanator Yes, I was considering that as well. The problem is when I change the state that way (by calling the transition method), the object will reset some counter. If I am simply resuming the state from persistence, then I don't want the counter to be reset. Another thing that I was thinking is to have an extra method `resume` that does the check of the current state and resume the state operation there. – Pablo Espantoso Aug 30 '17 at 11:59

0 Answers0