Что такое уровни абстракции в книге 'Чистый код' Мартина?

Question

[ant123455432143]

Читаю книгу 'Чистый код' Роберта Мартина и там в третьей главе о функциях используют понятие уровни абстракции. И я не могу нормально понять что это за уровни или как тут помогут TO-абзацы?
Я это понимаю так, что есть какое-то общее название функции, которое олицетворяет бизнес-логику, — это один уровень абстракции, а те операции, которые уже непосредственно выполняют действия, которые позволяют выполнить бизнес-логику (допустим запрос в БД или модификация строки), — это другой уровень.
Но потом в книге приводят пример

public Money calculatePay(Employee e)
throws InvalidEmployeeType {
    switch (e.type) {
      case COMMISSIONED:
        return calculateCommissionedPay(e);
      case HOURLY:
        return calculateHourlyPay(e);
      case SALARIED:
        return calculateSalariedPay(e);
      default:
        throw new InvalidEmployeeType(e.type);
    }
  }

Далее в книге пишут, что эта функция

совершенно очевидно выполняет более одной операции

. А мне это вообще не очевидно, ведь тут подразумевается, что в методе несколько уровней абстракции, но почему?
Я из-за этой главы не могу дальше книгу прочитать, поэтому прошу, объясните, пожалуйста, по простому, что это за уровни абстракции, как их выделять?

Comments

[dmitriy]

Простыми словами, например если вам нужен компьютер вы покупаете системник, монитор, клаву , мыш - это уровень вам позволяет использовать провод для разетки, hdmi кабеля и тд для соединения и использования ваших устройств.

Если у вас возникает ситуация собрать системнык, вы погружаетесь на другой уровень абстракции, покупаете материнскую, память, жесткий, шлейфы всякие - это другой уровень абстракции.

Есть вариант погрузится в другую абстракцию на уровень транзисторов, там будут другие интерфейсы, коннекторы и тд.

Уровни позволяют не погружаясь в детали использовать систему как черный ящик где наружу торчат упращеные органы управления.

Каждый уровень использует нижестоящий, но не наоборот, это позволяет снизить зависимость.

В ПО, я использую:
Слой Инфраструктуры
Слой Представления
Слой Приложения
Слой Домена

Правила для слоев:
- Слой НЕ использует вышестоящий
- Каждый слой меняется со своей периодичностью, как правило чем ближе к представлению тем чаще меняется
- Общение между слоями реализуется через абстракции
- Для каждого слоя свои паттерны и правила разработки, например для Домена - это всегда ООП, много тестов. Для aplication - это UseCases, в основном Busines Process, для Presentation - это меньше ООП, больше процедурного кода, меньше тестов, покрайней мере у меняя.

Расслоение значительно повышает стабильность, понимание.

[Adamos]

Возможно, вы просто рано схватили "Чистый код". Это не учебник программирования, его бесполезно читать, не имея хоть какого-то опыта.
Проблематика книги - как управиться с огромным объемом информации, который требуется держать в голове, чтобы написать сложную программу, а то и систему. В ученических программах эта проблема не стоит, поэтому материалу книги зацепиться не за что. Нужно набить руку и шишки, убедиться, что при росте сложности неизбежно получается говнокод и хаос - и уже тогда брать Мартина, Макконнелла, Фаулера. Они дадут теорию преодоления этих грабель, после чего можно будет биться головой уже в правильном направлении.

Answer 1

[Rsa97]

Уровни абстракции - разбиение программы на модули, каждый из которых реализует свой уровень, предоставляя интерфейс для следующего уровня и скрывая от него детали реализации.

Например:
Первый уровень - драйверы базы данных. Они реализуют соединение с базой, протокол обмена данными.
Второй - универсальный интерфейс базы данных (PDO). Он реализует работу с любой базой данных в едином стиле.
Третий - ORM. Он представляет объектную модель данных, хранящихся в БД.
Четвёртый - основные операции бизнес-логики.
Пятый - бизнес-логика верхнего уровня.

При этом, драйвер БД использует сетевой интерфейс, у которого семь уровней абстракции (модель OSI), не вдаваясь в детали реализации.

Answer 2

[res2001]

А мне это вообще не очевидно, ведь тут подразумевается, что в методе несколько уровней абстракции

Тут не несколько уровней абстракции. Тут не хватает абстракций, а потому и возникает проблема.

совершенно очевидно выполняет более одной операции

Для данного примера очевидно, что "более одной операции" - это расчет выплат для разных типов сотрудников.
А раз разные типы, то значит в этом методе, по мнению автора, не хватает абстракций для типов сотрудников.
Об этом же говорит и способ решения проблемы, предлагаемый автором в следующем листинге - он предлагает применить полиморфизм, т.е. создать иерархию классов по типам сотрудников, которые будут наследоваться от абстрактного класса Employee и сделать "абстрактную фабрику", которая будет создавать объект нужного класса сотрудника в зависимости от переданного типа сотрудника. Тогда каждый дочерний класс сотрудника будет переопределять свой метод calculatePay только для своего типа. Вышестоящий код благодаря полиморфизму получит правильный расчет выплат для данного сотрудника без switch.
Точнее в решении switch остается, но на уровне абстрактной фабрики, когда делается выбор какой объект сотрудника надо создавать. И это единственное место, где будет такой switch. Если же не использовать полиморфизм, то потенциально может существовать множество мест, где понадобится использовать switch по типам сотрудников.