2

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

  • why the downvote? – blfuentes Jul 23 '17 at 21:56
2

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.

  • So in this case I do not need the subclasses for the Expense types. They don't behave different. What would it be about the segregation between expense and incomes? In my sceneario they do have a difference. Incomes just need to know amount and where they belong to, while expenses carry more info about kind of expense. – blfuentes Jul 24 '17 at 7:05
  • @blfuentes I recommend coming up with all the details about the differences that you know of for sure. Incomes could also have tags (I've used finance software that allows characterizing incomes much like expenses). The risk with inheritance is that as soon as you code with it, it's very hard to change the design. – Fuhrmanator Jul 24 '17 at 13:52
  • I get the point. The unique difference between the expenses and incomes in my project is income do not have the type attribute but they do belong to an account and share the rest of properties.. – blfuentes Jul 24 '17 at 18:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.