if your AccountManipulator
is a Fa?ade to your domain, I wouldn't put the account number in the constructor. I would refactor it this way:
public class AccountManipulator
{
private AccountFactory _factory;
private UserRepository _users;
public AccountManipulator(AccountFactory factory, UserRepository users)
{
_factory = factory;
_users = users;
}
public void FreezeAccount(int accountNumber)
{
var acc = _factory.GetAccount(accountNumber);
acc.Freeze();
}
public IEnumerable<IAccount> GetAccountsOf(User user) {
return _users.GetAccountIds(user).Select(_factory.GetAccount);
}
}
public interface UserRepository {
IEnumerable<int> GetAccountIds(User user);
}
In order to state if your domain is SOLID, you should analyze it with the principle:
- Single Responsibility: every object has is own responsibility (and only that one):
- AccountFactory: creates IAccounts
- SavingsAccount: implementation of IAccount that reads from/writes to (a database? a web service?)
- AccountManipulator: provide a minimal and simple set of operations to do with domain objects.
- Open/Closed: are you classes are open to extensions and closed to changes?
- AccountFactory: well, no. If you write a new implementation of IAccount, in order to use it you have to change AccountFactory. Solution: abstract factory
- SavingsAccount? It depends if it will use external dependencies. Need more code to say.
- AccountManipulator: yes. If you need to do another operation with your domain objects, you can use directly the other services without change AccountManipulator. Or you can inherit from it
- Liskov substitution: can you substitute any class with another implementation? Need more code to say. You have no other implementations of IAccount or IAccountFactory now
- Dependency Inversion:
- AccountManipulator should depend on abstractions: AccountFactory and UserRepository should be interfaces.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…