Is using a global to maintain the currently logged in user bad practice?

Question

I'm doing some android development in a relatively inexperienced group, and all of the data used by our application is managed in a database. There are several instances where we'll need to pull info from the database using the identifying information/PK of the user who is currently logged in. Because the only info from the user that is important is the PK (IE we don't need an entire class to represent the types of users or any associated data), and because this ID is important throughout the scope of the application and will not change once it is defined, we considered storing the ID/PK of the user in a global on successful login.

Is the use of a global variable in a circumstance like this bad practice? Is there a better way to handle it?

Answer 1

Using globals is sort of like risky driving. It probably won't hurt you right away, but it makes you complacent about the ways you could get hurt down the road. It might get you there a little faster now, but that's largely because other drivers are driving defensively, and there happens to not have been any unexpected obstacles in the road.

Using globals makes it very difficult to see when you are creating excess coupling, because there's no penalty at the time of writing. If you have to pass a User object around, eventually you'll get annoyed at having to pass it around, and figure out a way to minimize the areas where it is used. Usually you don't need a piece of data in as many places as you think you do. For example, maybe you can avoid needing your user PK "throughout the application" by using a placeholder in your queries, then substituting the real PK in one place just before it gets run.

As for the idea that you have one logged in user, will only ever have that one user, and will only ever need the PK for that user, I give you the tale of Netflix. When I first signed up for the service, they had one DVD queue per account. That made it really difficult for my wife and I to share. We had to constantly rearrange the queue in order to ensure one of us didn't miss out on DVDs for a stretch.

Then they introduced multiple queues, which was great. However, after a while they said they had to discontinue that feature, because it was making it too unwieldy to maintain their code. I wasn't privy to the details, but I imagine it was due to their architecture being similar to what you are asking about. Maybe not using a global for the user, but making assumptions that made it effectively the case. They painted themselves into a corner when the account user started potentially being different from the queue user.

By that time, video rental stores were stocking a lot more DVDs, so we cancelled our account. We didn't come back until they fixed that problem. It's only recently that they managed to fix it for streaming as well.

My point is you have no way of knowing what features you're going to need or want down the road. Creating excess coupling is going to make it much more difficult to respond to market opportunities down the road. It's worth the small extra effort it will take to avoid globals now.