Amazon Interview Question
Software Engineer / DevelopersMy Solution: ( Fasade Design pattern )
idea: Going through different department to handle differenet new employee procedures is pretty inconvenient , so we need to create a interface class to handle all the procedures in one place , so this is a classic senario which Fasade Design pattern is applied .....
Class HR // class to handle procedure in HR department
{
Public:
HR();
~HR();
HR_Procedure();
}
Class Admin // class to handle procedure in Admin department
{
Public:
Admin();
~Admin();
Admin_Procedure();
}
Class Financial // class to handle procedure in Financial department
{
Public:
Financial();
~Financial();
Financial_Procedure();
}
Class Software // class to handle procedure in Software department
{
Public:
Software();
~Software();
Software_Procedure();
}
Class NewEmployee // Interface class to handle all the procedures in different classes
{
Public:
NewEmployee()
{
hr_p = new HR();
fin_p = new Financial();
admin_p = new Admin();
sf_p = new Software();
}
~NewEmployee()
{
Delete hr_p;
Delete fin_p;
Delete admin_p;
Delete sf_p;
}
ProcedureWrapper()
{
hr_p-> HR_Procedure();
fin_p-> Financial_Procedure();
admin_p-> Admin_Procedure();
sf_p-> Software_Procedure();
}
Private:
HR * hr_p;
Admin *admin_p;
Financial *fin_p;
Software *sf_p;
}
Void main()
{
NewEmployee *nep = new NewEmployee;
nep->ProcedureWrapper(); // handle all messy procedures in one place
Delete nep;
}
Would be great if we have more information on the problem domain, like:
- TheRandomGuy July 04, 20101) For what purpose does the person "go through" the various departments
2) what departments?
3) Does he have go through the departments only once?
4) What does each of those departments do with the person's data ?
5) Who will be using this design that we have been asked to create?
From the above questions we can get a general overview of how the common and uncommon functions that departments have, in addition so the peripheral (not core) functions, P1...Pn.
abstract class Department{/* Will hold the core functions or data*/}
interface P1 {}
.
.
interface Pn {}
class Dept1 extends Department implements P1, P3 {}
class Finance extends Department implements Insurable, ClaimRefunds {}
class Admin extends Department implements
Further, we need to see how might these various objects need to communicate between each other. So for the use case where a new employee joins Amazon,
HumanResources --informs --> Admin --informs--> finance
all of these "informs" can be implemented using, Publisher-Subscriber model. For other use cases, we might want the Admin or the HR dept to also act as the "Driver" class.
Also, we might want to choose to make each of these departments to be implemented as a Singleton (security and better maintainability)
This is an open ended question, we need more information for a "working" design/code.