Общее использование абстракции развязано.Для работы с Employee не нужно знать реализацию, только интерфейс и его контракты.Это, например, используется для Collections.sort(List<T> list): программистам Collections.sort(...) не нужно было знать реализацию определенного списка для его сортировки.Это обеспечивает то преимущество, что реализация поддерживает будущий код, соответствующий интерфейсу List . Этот вопрос связан в этом отношении (#selfPromotion).Меньшее сцепление ведет к меньшему трению и в целом к менее хрупкому коду.
Тем не менее, приведенный вами пример плохой, поскольку он нарушает Принцип единой ответственности : Это не ответственностьEmployee экземпляр для расчета зарплаты.Для этого у вас должен быть отдельный объект, который рассчитывает зарплату на основе Employee экземпляра и нескольких отработанных часов.Внутренне, этот Uber-калькулятор может использовать Chain of Responsibility , который содержит одну Calculator за Employee -воплощение, отделяя Employee от того, как рассчитывается ее / его зарплата.Это обеспечивает дополнительное преимущество расширяемости и гибкости: если меняется способ расчета заработной платы (например, может быть, компания меняет политику так, что каждый FullTimeEmployee получает одинаковую зарплату, или, возможно, компания хочет рассчитывать зарплату по неделямвместо помесячной) другие службы, использующие FullTimeEmployee, скажем, не затрагиваются).