3

I am building a solution for the recruitment division of an organization. The requirement is to create new employee records in the organization's database for the applicants who have cleared the interviews and are joining the organization.

I have built an API to receive the 'Applicant' object from my HR system and create an 'Employee' record for the same. I am using Adapter Pattern to transform 'Applicant' object to 'Employee' object.

This transformation is a multi step process. Like

Step 1) Transform applicant's personal information. 
Step 2) Transform her educational qualifications. 
Step 3) Transform her previous experiences.
Step 4) Transform financial records of the employee.

The above solution works good. Now the organization has to consider applicants who are being referred from a recruitment agency. In that case, most of the applicant's information such as personal information would not be available in the organization's database. But my Source object would contain an Applicant Id as well as an applicant type (denoting she is referred from recruitment agency), with which I can invoke a webservice to get the applicant's personal information and do the transformation.

So to describe it in a higher level, the proposed solution should decide which route to take based on the applicant type for certain steps in my adapter transformation, either to look for the information in source object or invoke a web service.

My question is how to introduce this condition based execution (based on the applicant type) for certain steps in the existing adapter pattern. My architect doesn't want to change to a different design pattern, rather we would like to achieve this conditional execution with the same adapters. Any suggestions to help us start with this could be of great help.

Thanks in advance. Happy learning !!!

  • 1
    You can have different adapter classes based on the applicant type. Then, you instantiate the right one to process a record. Sprinkling if statements everywhere in your existing classes is not very scalable (development-wise). – Jordão Apr 16 '17 at 14:51
  • +1 @Jordão - Suggestion does makes sense. Let me give it a try. Thanks for the tip. – Dinny Apr 16 '17 at 16:26
2

The problem you mentioned is perfect for the Strategy Pattern. Basically, you have a strategy that encapsulates the behavior (in the form of your Adapters). Your client would ask a factory to create the appropriate Strategy/Adapter based on the rules you define.

The beauty of this lies in the fact that when the rules for how to process the applicant into an employee change (e.g. there might be a new system that you need to retrieve applicant data from), the client is isolated from that, you just have to create a new strategy, and update the factory to handle the new scenario.

| improve this answer | |
  • Thumbs up Mike. I am going ahead with your proposed solution. – Dinny Apr 17 '17 at 6:14
0

looks like you are already doing all necessary things it just need some restructuring. 1 possible way enter image description here

Please share if you are doing something different, I am also learning through this

| improve this answer | |
  • Thanks. I went ahead with @Micheal Brown's suggestion. I will share my poc shortly. – Dinny Apr 17 '17 at 6:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.