2

I am trying to create chat app that will have different users:simple user, vip users and etcetera.

all types of users will have the data that simple user have, like:name,password,email and so on however all the other users type have uniqe options only to them.

I thought to create class SimpleUser that will have the basic functionality that achieved by using private variables, getters/setters,and so on, while all other user types will have their own classes that extends the SimpleUser class and add their uniqe functionality.

but after I seen this article Do subclasses inherit private fields? its just doesn't seems the right approach.

I am not sure that using Interface to provide optional functionality will help, because i still have private variabels in each user type that I access using getters/setters.

also currently I am cheking in every screen what the type of the user (in order to choose the rigth options for him), its seems clunky, is there a way to check the type of the user only once (when the user logs in) and in all screens simply use his uniqe functions?

  • what is the correct way to design my classes?

  • is their one solution for both my problems?

Community
  • 1
  • 1
D.Rotenberg
  • 71
  • 1
  • 10
  • What kind of behavior will differ from simple and VIP users? Focus on modeling behaviors, not data. – plalx Feb 28 '16 at 15:58

1 Answers1

0

Perhaps approach things from the other side, rather than think about user, perhaps think about screens, each user has a "level" and the screens provide the per level functionality, as really the functionality isn't really the users its the screens, the screen just decides based on the user.

I think I would stat with an enum with Simple VIP etc and this enum would have methods that do the appropriate thing for that level of user.

Gavin
  • 1,725
  • 21
  • 34
  • you right, but everyone have the same screens only some of functionlity change, and some of the fields appear/ disappear. – D.Rotenberg Feb 28 '16 at 14:14
  • Then it strikes me the Screen is in charge, so, the if you have a Lobby screen it has knows how to draw itself for the logged in ```User```, determined on the user's "level", if the ```User``` has to understand how to control the ```Screen```, every new ```Screen``` you add to your chat program will cause a change to the ```User``` class. You can have a config object ```LobbyConfig``` for example which can return the appropriate config for the users level. – Gavin Feb 28 '16 at 14:20
  • you right, but everyone have the same screens only some of functionlity change, and some of the fields appear/ disappear. if i use Enum with methods how to confirm that only the "right" type of Enum can use the method? also from what I learned in OOP (maybe I misunderstood) its not the best approach to create Type(Class,Enum Etc.) that part of his objects(in our case Enums) never use some part of his functions. – D.Rotenberg Feb 28 '16 at 14:21
  • A Enum represents a ```Level``` of usability, every physical user at a terminal will get there own instance of a ```Screen```, it will have a method, say ```init(Level level)``` this will call ```ScreenConfig.getConfig(Level level)``` returning a ```ScreenConfig``` that ```init``` can use to turn fields off and on. Using types ensure correct access, there is no reason why a class can't have functionality that isn't always used, it is sometimes bad form to not implement everything when inheriting as this breaks the IS-A relationship, but sometimes it happens, I don't see that happening here. – Gavin Feb 28 '16 at 14:32
  • thanks, I need to find the right way to to implement this in terms of Android usage. – D.Rotenberg Feb 28 '16 at 14:42