Added solution to DIP problem statement

Database.cs

@@ -0,0 +1,9 @@
+namespace EmployeeSystem {
+
+    // This way Low-level module(database) implements the abstraction
+    public class Database : IDatabase {
+        public void save(Employee employee) {
+            // Code to save employee to the database
+        }
+    }
+}

Employee.cs

@@ -0,0 +1,14 @@
+namespace EmployeeSystem {
+
+    public class Employee {
+        private String name;
+        private String address;
+
+        public Employee(String name, String address) {
+            this.name = name;
+            this.address = address;
+        }
+
+        // Getters and setters
+    }
+}

EmployeeService.cs

@@ -0,0 +1,15 @@
+namespace EmployeeSystem {
+
+    // This way High-level module(EmployeeService) depends on abstraction
+    public class EmployeeService {
+        private IDatabase iDatabase;
+
+        public EmployeeService(IDatabase employeeRepository) {
+            this.iDatabase = employeeRepository;
+        }
+
+        public void saveEmployee(Employee employee) {
+            iDatabase.save(employee);
+        }
+    }
+}

IDatabase.cs

@@ -0,0 +1,7 @@
+namespace EmployeeSystem {
+    public interface IDatabase {
+        void save(Employee employee);
+    }
+}
+
+//By creating an interface we can also implement it into other database sources such as Files etc in future without changing the existing code. This will also help in maintaining OCP.

README.md

@@ -1,2 +1,10 @@
 # Learn-and-Code
 This Repository includes all the assignments for Learn And Code - 2023
+
+In the provided problem statement of Assignment 7, the code is violating DIP beacause of the following reasons:
+
+1. As the EmployeeService class is directly dependent on the implementation of the Database class, but According to DIP, high-level modules (like EmployeeService) should not depend on low-level modules (like Database). They should depend on abstraction.
+
+2. We also learned that according to DIP the abstractions should not depend upon details, details should depend upon abstractions. Here, EmployeeService directly depends on the Database class, which is a concrete implementation and thus it makes hard to replace Database with a different storage mechanism for eg. Files.
+
+3. Here, it is also hard to maintain the code as if the implementation of Database changes, EmployeeService also might need to change too.