Интересно было прочитать про использование closure и associated type в перичислении. Хочется спросить, возможно ли карирование при использовании indirect перечислений? И в каком случае будет использоваться dynamic dispatch вместо традиционного для перечисления static dispatch?
Кстати, оператор сравнения вручную реализовывать не нужно. Достаточно прописать Comparable протокол в объявлении.
Чтобы до конца покончить с дилетантами оставлю здесь комментарий о том, как бы автор реализовал данную систему с использованием языка C++.
Объявить базовый класс Worker(сотрудник), от которого унаследовать производные классы PartialTimeWorker, FullTimeWorker и т.д.
Создать объект Department(штат сотрудников), который хранит список всех сотрудников в виде списка vector
Создать объект Accounting(бухгалтерия), который содержит метод calculate_salary(WorkerType) и само перечисление WorkerType
При необходимости расчитать зарплату, объект Department для каждого сотрудника в списке vector выполняет downcast, определяя при этом значение переменной workerType и вызывает метод accounting.calculate_salary(worker_type)
Таким образом объект Department зависит только от типов работников (инверсия), но не от деталей реализации расчета заработной платы. Также каждый объект Worker не знает о существовании других типов сотрудников.
В подобных случаях говорят, что нужно заткнуть сегодня те дыры, которые, к сожалению присутствуют в профессии, если не удается предложить что-либо лучше. Поскольку самые умные уже давно работают в Apple.
А вообще автору, как программисту, нужно обратить внимание на то, что профессия в основном связана с чтением. Поэтому код должен быть компактным и выразительным.
Считаю, что статья на ту же тему на несколько порядков лучше.
Это ваше видение и вы имеете право иметь свою точку зрения. Я же считаю, что создавать модель избыточно, тем более когда требуется разный naming в модели и json. Представьте, что бы было, если в модель LoginRequest добавить несколько CodingKey перечислений.
В самом начале статьи приведен пример в виде LoginRequest модели. Обратите внимание, насколько тяжело читается эта модель. Безусловно, лучше передавать один аргумент вместо 5, но если вы работаете со словарем [String: Any], то избежите большого числа вложенных моделей. Все, что останется - объявить промежуточную модель с теми самыми 5 полями.
В конечном итоге вы можете передавать сам словарь в качестве аргумента.
Интересно было прочитать про использование closure и associated type в перичислении. Хочется спросить, возможно ли карирование при использовании indirect перечислений? И в каком случае будет использоваться dynamic dispatch вместо традиционного для перечисления static dispatch?
Кстати, оператор сравнения вручную реализовывать не нужно. Достаточно прописать Comparable протокол в объявлении.
История изменений:
Добавлена ссылка на оригинал
Благодарю
Чтобы до конца покончить с дилетантами оставлю здесь комментарий о том, как бы автор реализовал данную систему с использованием языка C++.
Объявить базовый класс Worker(сотрудник), от которого унаследовать производные классы PartialTimeWorker, FullTimeWorker и т.д.
Создать объект Department(штат сотрудников), который хранит список всех сотрудников в виде списка vector
Создать объект Accounting(бухгалтерия), который содержит метод calculate_salary(WorkerType) и само перечисление WorkerType
При необходимости расчитать зарплату, объект Department для каждого сотрудника в списке vector выполняет downcast, определяя при этом значение переменной workerType и вызывает метод accounting.calculate_salary(worker_type)
Таким образом объект Department зависит только от типов работников (инверсия), но не от деталей реализации расчета заработной платы. Также каждый объект Worker не знает о существовании других типов сотрудников.
Очевидно, что речь идет про стрелку зависимости.
Написано в стиле источника [1]. Кратко и по-сути.
С той лишь разницей, что показано, **где возникает инверсия**.
Благодарю.
В подобных случаях говорят, что нужно заткнуть сегодня те дыры, которые, к сожалению присутствуют в профессии, если не удается предложить что-либо лучше. Поскольку самые умные уже давно работают в Apple.
А вообще автору, как программисту, нужно обратить внимание на то, что профессия в основном связана с чтением. Поэтому код должен быть компактным и выразительным.
Считаю, что статья на ту же тему на несколько порядков лучше.
Это ваше видение и вы имеете право иметь свою точку зрения. Я же считаю, что создавать модель избыточно, тем более когда требуется разный naming в модели и json. Представьте, что бы было, если в модель LoginRequest добавить несколько CodingKey перечислений.
В самом начале статьи приведен пример в виде LoginRequest модели. Обратите внимание, насколько тяжело читается эта модель. Безусловно, лучше передавать один аргумент вместо 5, но если вы работаете со словарем [String: Any], то избежите большого числа вложенных моделей. Все, что останется - объявить промежуточную модель с теми самыми 5 полями.
В конечном итоге вы можете передавать сам словарь в качестве аргумента.