I'm working on a simple class to get a token from an API. As simple as it is, it has different aspects. A connection to the API is needed for this to work at least the first time. Credentials are stored in the code (security is not the subject).A token should not be fetched from the API more than once every 9 hours, thus it should be saved in a file when successfully fetched.If the file is too old, it needs to be generated again.Now I'm thinking about doing four classes :File : responsible for creating, overwriting and returning the file.Parser : responsible for parsing a received file.DateCheck : responsible for checking whether the token is too old or notConnection : responsible for fetching the token through the API if neededNow all these classes are fine (what do you think ?), but I obviously need a higher level class at some point to wrap all this logic and get the token with one simple call to this class.Firstly there will be 4 dependencies, isn't that too much ?Also, it will actually do many things and the reason why it is troublesome to me is because the unit tests are pretty big (15-30 lines) with all the mocking required, and most tests in successful projects code I've read are very small and simple to understand.Is there something wrong with this reasoning, or is that the downfall the splitting up things that much ?
Where does the logic belong to respect SRP here?
design;single responsibility