Lab 1: Abstraction and access

Starter files: code.zip

Objectives

The objectives of this lab are:

• Use abstraction in code and tests as a way to minimize code duplication and improve design.

• Use appropriate access modifiers and data restrictions for tighter design.

• Use documentation to convey design intent.

1 Introduction

Duplicate code and redundant design is a common occurrence. Although sometimes it is the result of bad design, many times duplication and redundancy creeps into code that has been developed over a period of time. Abstraction is an effective way to tackle duplication in design and code.

Today, we are working with a job recommendation system with two components: job offers and skills.

Each job offer supports some operations. These operations are listed in the Offer interface. What follow are the kinds of job offers.

1. The FullTimeJob class represents an offer for a salaried full time job. This offer consists of

   • A job description

   • The yearly salary

   • A list of skill requirements

2. The Coop class represents an offer for an hourly co-op. This offer consists of

   • A job description

   • An hourly salary

   • A maximum number of hours someone can work per week

   • A list of skill requirements

3. The Volunteer class represents an offer for an unpaid volunteer position. This offer consists of

   • A job description

   • A list of skill requirements

The skills themselves also support operations. These operations are listed in the Skill interface. What follows are the kinds of skills.

1. The Years class represents some number of years of experience.

2. The Ability class represents a named ability.

The job offers component evolved over time. As the story goes, the FullTimeJob class was implemented first. Then a second developer wrote the Coop class by “drawing inspiration” from the first (note the similarity in the methods). Then a third developer wrote the Volunteer class by “drawing inspiration” from the second! As a result the provided code have the following undesirable properties:

1. They seem to have redundant and/or duplicate code.

2. The fields are not appropriately guarded against side-effects or inappropriate access.

3. Although the interface is well-documented, the documentation of the implementations is rather scant.

4. Much like the second and third developers, if more types of offers were to be implemented they would likely inherit the same undesirable properties as the above.

5. Even the tests have some duplicated code!

2 What to do: Part 1

Your aim in this lab is to refactor (change the implementations without changing what they do, or how other classes view their public methods) the provided code for both components and their tests. Use abstraction mechanisms such as inheritance, abstract classes and methods, etc. as necessary to minimize duplication of code. Tighten the access and usage of fields as appropriate. Lastly write appropriate Javadoc-style documentation for all the implementations.

3 Questions to ponder/discuss

Discuss these questions with the person next to you, and report to the course staff.

1. Do you still see duplicate code after your abstraction? If so, why did you not remove it?

2. What limitations or shortcomings are you introducing into your code as a result of abstraction?

4 What to do: Part 2

Implement a new type of skill: a proficient ability. This skill is like an Ability, but it also includes its proficiency as one of three values

1. beginner

2. intermediate

3. expert

Try to fit the resulting ProficientAbility class into your improved design. Consider how a job offer might care about Abilities in general, or might prefer to specify proficiencies as well. (Note that in general, we developers do not know what proficiency levels a company expects when they just specify an Ability, so a ProficientAbility cannot be equal to an Ability — but it could satisfy an Ability skill requirement.) What representation makes the most sense for these three proficiency levels? Don’t forget to write tests for it too!

5 Questions to ponder/discuss: Part 2

Discuss these questions with the person next to you, and report to the course staff.

1. Did adding this new class introduce new duplicate code? If so, did you remove it? Why or why not?

2. What limitations or shortcomings did you experience as a result of the given abstraction?

6 What to submit

Submit your final code to the submission server (submit a zip file with the src/ and test/ folders). This lab assignment does not have any auto-graded tests. Then take the self-evaluation for this lab on handins. Note that once you open the self-evaluation, you will not be able to submit to the lab assignment! So do not click on the self-evaluation until you know you are done with the lab!

This self-evaluation differs from the one for the assignments in one important way: this self-evaluation is available to you immediately, whereas the self-evaluation for the assignment will not be available until after the assignment deadline expires. So set your expectations for the assignment’s self-evaluation accordingly.