The question might sound a little weird, and I guess it is. I'm came up with the question while browsing through some design patterns. I came to the notorious state / strategy pattern and I came up with this code:
public class Account
{
public double Balance { get; private set; }
private IAccountState state;
public Account()
{
state = new ActiveAccountState();
}
public void Deposit(double number)
{
state = state.Deposit(() => Balance += number);
}
public void Withdraw(double number)
{
state = state.Withdraw(() => Balance -= number);
}
public void Freeze()
{
state = state.Freeze();
}
public void Close()
{
state = state.Close();
}
}
It is simplistic and not production ready of course, but I'm not trying for it to be that. It is a simple example. This code actually shows well the problem I'm having. Basically I have an IAccountState interface which represents the state / strategy. Now this could be considered a dependency and by allowing the Account class to KNOW how to manufacture the ActiveAccountState I enable the Account class to have more than 1 responsibilities. I could create an AccountStateFactory and make that a dependency on the account class. This would allow me to easily inject this newly created Factory dependency with the use of the Account class' constructor. But this way I, well, expose the implementation detail which is probably only interesting to the Account class and to none else. I guess that would make unit testing a tad bit easier.
My question would be how to know if something should be a dependency? Sometimes it is dead simple (ie. services, factories, providers etc.) but then there are times when I'm confused (like in this state / strategy example). Thanks in advance!
