If you have several very similar operations, one approach is to make them a single parameterized operation

public class Employee
{
    public enum PaidAbsenceType { Vacation, Sickness, MPternity, Training, Travel };

    public void setAllowance(PaidAbsenceType type, int amount);
    public int getAllowance(PaidAbsenceType type);

    public void useAllowance(PaidAbsenceType type, int amount);
    public int getUsed(PaidAbsenceType type);
}

and another is to split them into a dedicated class you can re-use

public class Employee
{
    public class PaidAbsence {
        public int allowance { get; set; }
        public int used { get; set; }
    }

    public PaidAbsence Vacation;
    public PaidAbsence Sickness;
    public PaidAbsence MPternity;
    public PaidAbsence Training;
    public PaidAbsence Travel;
}

hard-coding two versions of the same logic into your class, unless there are actual behavioural differences, smells a bit odd.

Note that in either of the above cases, a single calculator would suffice (either passing the PaidAbsenceType of interest, or directly passing the appropriate PaidAbsence object) - again assuming the actual logic is the same.

If you have several very similar operations, one approach is to make them a single parameterized operation, and another is to split them into a dedicated class and aggregate several instances.

parameterized pseudo-code example:

public class Employee
{
    public enum PaidAbsenceType { Vacation, Sickness, MPternity, Training, Travel };

    public void setAllowance(PaidAbsenceType type, int amount);
    public int getAllowance(PaidAbsenceType type);

    public void useAllowance(PaidAbsenceType type, int amount);
    public int getUsed(PaidAbsenceType type);
}

aggregated pseudo-code example:

public class Employee
{
    public class PaidAbsence {
        public int allowance { get; set; }
        public int used { get; set; }
    }

    public PaidAbsence Vacation;
    public PaidAbsence Sickness;
    public PaidAbsence MPternity;
    public PaidAbsence Training;
    public PaidAbsence Travel;
}

In both cases, the responsibility of the containing class is to aggregate these members, and if necessary to co-ordinate them.

Hard-coding two versions of the same logic into your class, unless there are actual behavioural differences, smells a bit odd.

Note that in either of the above cases, a single calculator would suffice (either passing the PaidAbsenceType of interest, or directly passing the appropriate PaidAbsence object) - again assuming the actual logic is the same.