Marcenary
@Marcenary

Как должна выглядеть UML диаграмма компонентов для функционального подхода?

Не понятно как делать диаграмму для работы. В примере программа состоит из классов, там всё понятно как делать. Но у меня написана программа на другом языке из за чего надобность в классах отсутствует, классы есть, но их мало. А если всё грести под классы, то выйдет маленькая диаграмма
  • Вопрос задан
  • 139 просмотров
Решения вопроса 1
mayton2019
@mayton2019
Bigdata Engineer
Во первых. Функциональное программирование не запрещает дата-объекты. Вот к примеру если у вас есть таблица Employee из стандартного учебного набора Oracle то она может быть отражена таким образом в Haskell:

data Employee = Employee {
 empno :: Integer,
 ename :: [Char],
 job :: [Char],
 mgr :: Maybe[Integer],
 hiredate :: Day,
 sal :: Integer,
 comm :: Maybe[Integer],
 deptno :: Integer
}


В том что Haskell это достаточно строгий язык который лежит в категории ФП я надеюсь никто не сомневается.

А в мультипарадигменных языках типа Scala с объектами
вообще нет проблем. Берите - делайте объекты сколько надо.

Во вторых, UML проектирование - это такой-себе уровень абстракций, который удобно
обсуждать с бизнесом и показывать на слайдах. Но он вовсе не обязан следовать буква-в-букву коду.
Архитектура - это вообще не про код. Это про намерения, про взаимодействие, про стандарты и смыслы.

Методы UML объектов вы можете сделать функциями. Я не вижу в этом чего-то нерешаемого.
Рассматривайте метод как функцию где первый аргумент - это сам объект. Это такой легкий
троллинг ООП. Типа ООП - это функции где первый аргумент == this.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
@AlexSku
не буду отвечать из-за модератора
Функции это блок обработки данных (вход -> выход). Можете рисовать поток данных аналогично обработке в DSP (цифровых сигнальных процессорах).
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы