Skip to main content
added 81 characters in body
Source Link
doubleYou
  • 2.9k
  • 1
  • 14
  • 26

Good question.

  1. It would make sense to keep the fireEmployee(Employee emp) method fireEmployee(Employee emp) inside Managerthe Manager class only if ManagerManager maintains a list of employees reporting to him and is allowed to fire only those employees who report to him... in which case "emp"the emp passed as the parameter to this method would have to be one of the employees reporting to him. This way, when an employee is fired we would also need to update the list of employees reporting to that manager which would amount to a change in the state of the Manager object, and hence it would make perfect sense for the fireEmployeefireEmployee method to be a part of Managerthe Manager class, as per OOP principles.
  2. You could instead keep this method directly inside employeethe Employee class with ManagerIda ManagerId as method-parameter, i.e. fireEmployee(string managerId)fireEmployee(string managerId)... Let Employeethe Employee class also have a property named empManagerIdempManagerId, which would store employee-Idthe ManagerId of his manager. When the method fireEmployeefireEmployee is called, the client would supply the manager-id of the manager responsible for firing him. This method of Employeethe Employee class would then validate that the managerIdmanagerId passed as a parameter should be the same as the id of his manager i.e. empManagerIdempManagerId

Hope this helps.

Good question.

  1. It would make sense to keep method fireEmployee(Employee emp) inside Manager class only if Manager maintains a list of employees reporting to him and is allowed to fire only those employees who report to him... in which case "emp" passed as the parameter to this method would be one of the employees reporting to him. This way, when an employee is fired we would also need to update the list of employees reporting to that manager which would amount to change in the state of Manager object and hence would make perfect sense for the fireEmployee method to be a part of Manager class as per OOP principles
  2. You could instead keep this method directly inside employee class with ManagerId as method-parameter i.e. fireEmployee(string managerId)... Let Employee class also have a property named empManagerId which would store employee-Id of his manager. When method fireEmployee is called, client would supply manager-id of the manager responsible for firing him. This method of Employee class would then validate that the managerId passed as a parameter should be same as the id of his manager i.e. empManagerId

Hope this helps.

Good question.

  1. It would make sense to keep the fireEmployee(Employee emp) method inside the Manager class only if Manager maintains a list of employees reporting to him and is allowed to fire only those employees... in which case the emp passed as the parameter to this method would have to be one of the employees reporting to him. This way, when an employee is fired we would also need to update the list of employees reporting to that manager which would amount to a change in the state of the Manager object, and hence it would make perfect sense for the fireEmployee method to be a part of the Manager class, as per OOP principles.
  2. You could instead keep this method directly inside the Employee class with a ManagerId as method-parameter, i.e. fireEmployee(string managerId)... Let the Employee class also have a property named empManagerId, which would store the ManagerId of his manager. When the method fireEmployee is called, the client would supply the manager-id of the manager responsible for firing him. This method of the Employee class would then validate that the managerId passed as a parameter should be the same as the id of his manager i.e. empManagerId

Hope this helps.

Source Link

Good question.

  1. It would make sense to keep method fireEmployee(Employee emp) inside Manager class only if Manager maintains a list of employees reporting to him and is allowed to fire only those employees who report to him... in which case "emp" passed as the parameter to this method would be one of the employees reporting to him. This way, when an employee is fired we would also need to update the list of employees reporting to that manager which would amount to change in the state of Manager object and hence would make perfect sense for the fireEmployee method to be a part of Manager class as per OOP principles
  2. You could instead keep this method directly inside employee class with ManagerId as method-parameter i.e. fireEmployee(string managerId)... Let Employee class also have a property named empManagerId which would store employee-Id of his manager. When method fireEmployee is called, client would supply manager-id of the manager responsible for firing him. This method of Employee class would then validate that the managerId passed as a parameter should be same as the id of his manager i.e. empManagerId

Hope this helps.