When an object uses another unrelated object to carry out a task, the relationship between them is called a dependency. In the software world, we also refer to this relationship as uses a relation. Now let's see if any kind of dependency relationship exists between the objects that we have thought about for our restaurant application.

If we analyze our FoodRepository object, which will be saving and retrieving Food objects from the database and passing them to the UI, we can say that the FoodRepository object has to use the Food object. This means that the relationship between the Food and FoodRepository object is a type of dependency relationship. If we think about the flow in the frontend when a new Food objects is created, that object will be passed to the FoodRepository. The FoodRepository will then serialize the Food object to database data in order to save it in the database. If the FoodRepository doesn't use the Food object, then how would it know what to serialize and store in the database? Here, the FoodRepository must have a dependency relationship with the Food object. Let's look at the code for this:

public class Food {
 public int? FoodId {get;set;}
 public string Name {get;set;}
 public decimal Price {get;set;}
}

public class FoodRepository {
 public int SaveFood(Food food){
 int result = SaveFoodInDatabase(food);
 return result;
 }

 public Food GetFood(int foodId){
 Food result = new Food();
 result = GetFoodFromDatabaseById(foodId);
 return result;
 }
}

In the preceding code, we can see that the FoodRepository class has two methods. One method is SaveFood and the other is GetFood.

The SaveFood method involves taking one Food object and saving it in the database. After saving the food item in the database, it returns the newly created foodId back to the FoodRepository. The FoodRepository then passes the newly created FoodId to the UI to inform the user that the food item creation was successful. On the other hand, the other GetFood method takes an ID as parameter from the UI and checks whether or not the ID is a valid input. If it is, the FoodRepository passes the FoodId to the databasehandler object, which searches the food in the database and maps it back as a Food object. After this, the Food object is returned to the view.

Here, we can see that the FoodRepository object needs to use the Food object to do its work. This type of relationship is called a dependency relationship. We can also use the uses a phrase to identify this relationship. The FoodRepository uses a Food object to save food in the database.

Like FoodRepository, the BeverageRepository does the same thing for a Beverage object: it saves and retrieves beverage objects in the database and UI. Now let's see what the BeverageRepository looks like as code:

public class Beverage {
    public int? BeverageId {get;set;}
    public string Name { get;set;}
    public decimal Price {get;set;}
}

public class BeverageRepository {
    public int SaveBeverage(Beverage beverage){
        int result = SaveBeverageInDatabase(beverage);
        return result;
    }

public Beverage GetBeverage(int beverageId) {
        Beverage result = new Beverage();
        result = GetBeverageFromDatabaseById(beverageId);
        return result;
    }
}

If you look at the preceding code, you will see that the BeverageRepository has two methods: SaveBeverage and GetBeverage. Both of these methods use the Beverage object. This means that the BeverageRepository has a dependency relationship with a Beverage object.

Now let's take a look at the two classes we have created so far, as shown in the following code:

public class FoodRepository {
    public int SaveFood(Food food){
        int result = SaveFoodInDatabase(food);
        return result;
    }

    public Food GetFood(int foodId){
        Food result = new Food();
        result = GetFoodFromDatabaseById(foodId);
        return result;
    }
}

public class BeverageRepository {
    public int SaveBeverage(Beverage beverage){
        int result = SaveBeverageInDatabase(beverage);
        return result;
    }

public Beverage GetBeverage(int beverageId){
        Beverage result = new Beverage();
        result = GetBeverageFromDatabaseById(beverageId);
        return result;
    }
}

One object can be related to multiple objects using a dependency relationship. In OOP, this type of relationship is very common.

Let's look at another example of dependency relationships. A relationship between a Programmer and a Computer could be a dependency relationship. How? Well, we know that a Programmer is most likely a human and a Computer is a machine. A Programmer uses a Computer to write computer programs, but the Computer is not a property of the Programmer. A Programmer uses a computer, and this doesn't have to be one specific computer—it can be any computer. So can we say that a relationship between a Programmer and a Computer is a type of dependency relationship? Yes, we surely can. Let's see how we can represent this in code:

public class Programmer {
    public string Name { get; set; }
    public string Age { get; set; }
    public List<ProgrammingLanguages> ProgrammingLanguages { get; set; }
    public ProgrammerType Type { get; set; } // Backend/Frontend/Full Stack/Web/Mobbile etc

    public bool WorkOnAProject(Project project, Computer computer){
        // use the provided computer to do the project
        // here we can see that the programmer is using a computer
    }
}

public class Computer {
    public int Id { get; set; }
    public string ModelNumber { get; set; }
    public Company Manufacturer { get; set; }
    public Ram Ram { get; set; }
    public MotherBoard MotherBoard { get; set; }
    public CPU CPU { get; set; }
}

In the preceding example, we can clearly see how a Programmer and a Computer have a dependency relationship, however, this is not always the case: it depends on how you design your objects. If you have designed your Programmer class in such a way that each programmer has to have a dedicated computer, you could have used Computer as a property in the Programmer class, and then the relationship between the programmer and the computer would have changed. Consequently, the relationship depends on how the objects are designed.

My main goal in this section was to clarify the dependency relationship. I hope the nature of dependency relationships is now clear to you.

Now let's see how the dependency relationship is drawn in a Unified Modeling Language (UML) diagram, as shown in the following diagram:

A solid line is used to represent a dependency relationship.