How to keep the interface segregation principle while using the state design pattern?

33 Views Asked by At

In a previous question on StackOverflow, I asked about preventing the Context class within a State design pattern from having too many responsibilities, and I received an answer on that (moving it all to the states) but now I wonder...

If I have an interface called IState and in that interface I list multiple methods that are applied by some of the states but not others (they simply return a message like, "Can't be done in state X") am I not breaking the interface segregation principle by forcing my states to depend on methods they do not implement?

I found an answer to a similar question on StackOverflow. Now, I would argue that my question builds over this one because I want to also ask if I have this original IState with many methods:

interface IState {
  void OpenChargePort();
  void CloseChargePort();
  void PLayMusic();
  void StopMusic();
  void OpenWindow();
  void CloseWindow();
  void OpenTrunk();
  void CloseTrunk(); 
}

And I convert this to multiple smaller interfaces, following the Interface Segregation Principle:

interface IChagePort {
  void OpenChargePort();
  void CloseChargePort();
}
interface ITrunk {
  void OpenTrunk();
  void CloseTrunk(); 
}

Does this satisfy the State Design pattern?

0

There are 0 best solutions below