In the previous post you can read how to use
Session object to maintain current user information through the application lifecycle. Now we’ll explore different options of implementing varying behavior depending on user type.
I find it neat when an application allows me to use it before I’m forced to create an account or sign in. In such a case there will be a, potentially very long, time where we have no way of identifying the user. At the same time we’ll want to provide as much features of an identified user as possible. There will however be cases where application behavior will be different depending on whether the user is logged in or not.
Let’s assume that our application allows changing preferences for both anonymous and authenticated users. When saving or reading user dependent application settings we can write a simple
if statement to decide which preferences to use.
Notice how in line
23 we do a check to decide the name of
SharedPreferences to use. There’s nothing wrong with doing such a check in 1 or 2 places however this type of logic will typically spread over dozens and more places in the various parts of the code base.
Instead of relying on null checks we can use a simple pattern described in detail by Martin Fowler. Here’s how it would look like in our case:
Now all places where we require an easily substitutable information about the user can be handled with plain old polymorphism.
The above approach will work whenever we need a default value for the anonymous user - no so much when we need different behavior. It’s tempting to embed various actions into
UserReference interface implementations (
RegularUserReference) however this will make the mentioned interface depend on UI concepts which I would like to avoid.
Before I show how to avoid putting too much weight onto
UserReference interface, let’s make our situation a bit more complicated. Let’s assume that our app can be used by three types of users: anonymous, regular and premium.
A very common approach is to use an enum to handle that i.e.:
In fact because
default the above implementation works well as long as we have a small number of user types and there’s little shared behavior.
A slightly different approach is to hide the decision making and expose method(s) that accept different behaviors. The following code is an example of how we can approach encapsulating differences between user types in by explicitly declaring a behavior:
Note that the above uses double dispatch but it could easily be replaced with a
switch statement. Using separate class to encapsulate differences should make it easier to keep unnecessary logic out of
A curious reader might notice that if we would like to change how we handle only one user type we’re still forced to override all methods. There’s a fairly simple way to improve the above though:
Now we can implement custom actions as well as indicate a default. As usual whether to go with a simple
if statement, a
switch or a double dispatch depends on a use case. However it’s useful to know the different ways of tackling the same problem.
This article is cross-posted with my company blog