This is for an Android app, but I think the question applies to any software designed with a service layer.
Our app is structured with a presentation layer that handles the UI and a service layer beneath it, comprising lots of service objects that the UI layer will call when it needs to perform some business logic. Say there's an EventRecordingService that records whenever the user clicks something and lots of UI classes hold a reference to the same EventRecordingService object.
Now lets say the EventRecordingService needs to assign an incrementing number to each event it sees, which means it has to maintain a counter. Obviously it would be better to be stateless but sometimes it can't be avoided. Now if an event is recorded from two different threads simultaneously, unless access to the counter is synchronized, it could get confused and give the wrong result.
My attitude to this kind of thing normally is to never make any classes thread safe unless they need to be, because thread safety is expensive and difficult. Right now, all calls to this service happen in the same thread and there's no plans to add more, so it's fine.
My colleague argues that it should be thread safe because in the future, someone else might come along and call the service from a different thread. The service doesn't look stateful from the outside, the counter is an implementation detail, and while there's no plans to add more calls to it currently it's easy to imagine it happening in the future. In this case not making it thread safe could be dangerous, because it might appear to work with the new call added but just occasionally go badly wrong.
I feel he has a point, but also, it seems like if we make everything thread safe even if it doesn't need to be we'll never get anything done.
So what's the normal thing to do in cases like this? Should we add a warning to the class saying it isn't thread safe, or make it thread safe? Or should we find a way to make it stateless at all costs?