Separating functionalities in a food delivery app

Question

I am creating object oriented design for a simple app through which users can order food from restaurants. User can browse nearby restaurants, explore menu, add items to cart, and finally checkout.

For now I am concentrating on two main classes User and Restaurant and the interaction that a user can browse nearby restaurant. Lets say that there is a function called getNearByRestaurants(Location location). Which is the best place for the function to be? Some options that I thought -

1. In User class. My confusion with this is should User class just have all the functions related only to a user, like changing email, credit card, etc. or should it have functions that can interact with other entities?
2. A new class called UserActions where all user interactions with other entities can be listed.
3. A class called RestaurantRegister, which can be a singleton. Any new restaurant would register itself using functions of this class. getNearByRestaurants(Location location) can be in that function.

Answer 1

It seems like a Restaurant and a User are both independently meaningful, so it wouldn't make a whole lot of sense for a User to include the operations that pertain to Restaurant and vice versa. It also wouldn't make sense for the Restaurant to contain this information, because it would result in a bunch of cyclic references that are difficult to manage.

The UserActions approach sounds reasonable at first, but it won't scale. As your functionality grows, you'll end up with one gigantic class that includes basically all the functionality of the application. After all, aren't user actions integrally related to most functionalities in an application built for users to act upon?

A service with a single-responsibility of finding Restaurants close to a location sounds very manageable. I'm not crazy about the name RestaurantRegister, because it doesn't really specify the capabilities of the service. Ambiguity about what the service does might lead to the service becoming its own kind of monolithic service for aggregating all the Restaurant behavior (like a small slice of the UserActions pattern you described). So, rather than RestaurantRegister, you might want to try something more meaningful like RestaurantFinder, for example.

This being said, I think the idea is mostly right here. Except, you may not want to force a singleton implementation. Imagine that you decide you want a feature that filters nearby restaurants by a user's stored preferences about what kind of cuisine they like. It would be reasonable to consider an implementation that can be scoped to the current user, so you wouldn't have to complicate the interface by passing in data about user preferences. This wouldn't be very compatible with a singleton implementation. Another reason to avoid the singleton pattern here is that, depending on what language you're using, a standard singleton implementation can sometimes pose problems for testing.