Size: a a a

Архитектура ИТ-решений

2021 February 28

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Phil Delgyado
Что не хватает на уровне языка - я хорошо понимаю. Но у тебя пример не про выразительность языка, а про анализ.
Артефакты анализа удобно отражать на конструкции ЯП естественным образом, а не через костыли (классы)
источник

e

elendili in Архитектура ИТ-решений
Phil Delgyado
А тем, что у этой функции куча атрибутов. Да хоть label на кнопке калькулятора
Имх. это не у функции сложения есть атрибут “кнопка сложения”, а у класса “калькулятор” есть ассоциация “кнопка сложения”-“функция сложения”.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Gennadiy Kruglov
Артефакты анализа удобно отражать на конструкции ЯП естественным образом, а не через костыли (классы)
Так как раз в анализе у тебя чистых функций и не появилось. И я не видел еще анализа реального мира, где ФП появлялось бы на уровне анализа.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
elendili
Имх. это не у функции сложения есть атрибут “кнопка сложения”, а у класса “калькулятор” есть ассоциация “кнопка сложения”-“функция сложения”.
Можно и так. Но назначать эту функцию на другую кнопку нет смысла
источник

e

elendili in Архитектура ИТ-решений
Phil Delgyado
Можно и так. Но назначать эту функцию на другую кнопку нет смысла
Например, можно придумать композитную функцию, в которую входит функция сложения. например, “кулькулятор” может считать среднее. Функция среднего включает в себя функцию сложения.
А кулькулятор, как сущность, ассоциирует новую ”кнопку среднего” и ”функцию среднего”
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Phil Delgyado
Так как раз в анализе у тебя чистых функций и не появилось. И я не видел еще анализа реального мира, где ФП появлялось бы на уровне анализа.
Потому что привычка, привыкли мыслить классами
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Может привычка. А может просто ближе к наблюдаемой реальности или функциям мозга
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Что такое Сервис? Почему для моделирования сервисов мы должны использовать классы? Для моделирования сервисов нужны "сполпы" объектно-ориентированной парадигмы?
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Я не знаю что такое сервис.
источник

e

elendili in Архитектура ИТ-решений
Phil Delgyado
Может привычка. А может просто ближе к наблюдаемой реальности или функциям мозга
Или ближе к упрощению необходимому для обучения.
Когда счету учат, то учат на конкретных объектах.
Но впоследствии мозгу же как-то удается отделить “счет” от того, что именно считается.
источник

e

elendili in Архитектура ИТ-решений
Или ”движение”. Не знаю, как представить “движение” без конкретных объектов.
Но тем не менее мы можем использовать концепцию “движения” в отрыве от конкретных объектов, просто комбинируя с разными объектами.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
elendili
Или ”движение”. Не знаю, как представить “движение” без конкретных объектов.
Но тем не менее мы можем использовать концепцию “движения” в отрыве от конкретных объектов, просто комбинируя с разными объектами.
Точно
источник

PD

Phil Delgyado in Архитектура ИТ-решений
elendili
Или ”движение”. Не знаю, как представить “движение” без конкретных объектов.
Но тем не менее мы можем использовать концепцию “движения” в отрыве от конкретных объектов, просто комбинируя с разными объектами.
Ну, вот очень хочется посмотреть на анализ какой-то знакомой предметной области (да хоть финтеха) с точки зрения ФП.
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
Phil Delgyado
Ну, вот очень хочется посмотреть на анализ какой-то знакомой предметной области (да хоть финтеха) с точки зрения ФП.
У ООП есть сильная сторона - абстракция. Благодаря абстрации анализ выполнять удобно.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, в ФП оно тоже есть
источник

F

Fagor in Архитектура ИТ-решений
Phil Delgyado
Я не знаю что такое сервис.
все придумано человеком, т.е. все просто соглашения, зачем усложнять, еще и средствами фп, через призму ооп. Само сложится, а если нет, то значит оно и не нужно
источник

e

elendili in Архитектура ИТ-решений
Phil Delgyado
Ну, вот очень хочется посмотреть на анализ какой-то знакомой предметной области (да хоть финтеха) с точки зрения ФП.
Такое ощущение, что функции это абстракции более высокого порядка, чем “предметная область”.
Предметная область это про “существительные”, тогда как функции это “глаголы”. Они как клей для “существительных”.
Анализ предметной области, наверно, невозможен в таком случае, ибо ”предметная область” заранее ограничена “предметами”, некой декомпозицией сущностей, “существительных”.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
А что возможно, где эти более абстрактные глаголы?
источник

GK

Gennadiy Kruglov in Архитектура ИТ-решений
elendili
Такое ощущение, что функции это абстракции более высокого порядка, чем “предметная область”.
Предметная область это про “существительные”, тогда как функции это “глаголы”. Они как клей для “существительных”.
Анализ предметной области, наверно, невозможен в таком случае, ибо ”предметная область” заранее ограничена “предметами”, некой декомпозицией сущностей, “существительных”.
Да, точно. Хорошая мысль
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Я глупый, я не понимаю без примеров
источник