This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I am trying to draw up a UML of a Gym membership program. I need Staff Members Gym Members and Yoga Members. If Yoga Members and Gym Members have monthly dues but Staff Members do not, how can I have a Staff Member that is also a Gym Member (meaning they have monthly dues now)? Or would this be a case when I would need separate classes? I was thinking I should create an interface where any member may implement PayingMember.
Have you considered not using classes to codify this particular business rule? Maybe all you need is an attribute like say, paysDues (boolean). It's always easier to start with a simple design then evolve it as more scenarios come into the picture rather than start with a complex mess and try to make sense of it all. Grow your software design little by little, always refactoring as you go.