Pergunta

So I would like to model the class diagram for the following scenario:

  • the client has to manage three types of accounts(Pocket, Postbank, DKB). More types of accounts may be added later.

  • the client registers movements(expenses and incomes). These movements are what define the state of each account

  • While income are pretty basic(there is only need to register for which account it was made), expenses have to be sorted depending of their nature(leisure, food, transport, general) More types of expenses may be added later.

For these requirements I came with this modeling:

  • Singleton instance for the 'movementFactory'. It will be extended by two types of creators: Income and Expense.

  • Expense creator will be implemented by concrete classes depending on what kind of expense would be created.

My doubts come when trying to figure out if having two "Factory method" for the "expense path" is somehow overkill and if the class SingletonMovementProducer is a good practice in this case or how could I model the given scenario.

UML Class Diagram

Foi útil?

Solução

Accounting models are simpler than what you've presented, and don't require so much inheritance. Martin Fowler has one from 2006 at https://martinfowler.com/eaaDev/AccountingNarrative.html

enter image description here

I think it is not a good design to use sub classes for expense types, for a couple of reasons.

  • the requirements don't specify any real differences between Expense types, or Movement types. You have an overly complex design to understand and maintain.
  • what happens when you have a user who wants to classify an expense that is both Leisure and Food? Inheritance is not flexible, and probably a non-hierarchical tag model (with composition) would be better?

I suggest you simplify things until you really have concrete examples of why sub classes are needed. As you can see, with a simpler design, the question about factories goes away.

Licenciado em: CC-BY-SA com atribuição
scroll top