16.08.2023 12:30
rayvector44 7 7600 Источник

Параметры: +DRY, -KISS

В программировании (да и в жизни в целом) есть два типа мышления — условиями и связями. Второе, на сегодняшний день, является самым лучшим и оптимальным видом мышления, ведь благодаря ему не приходится останавливаться, вы можете его переиспользовать, и, тем самым, не повторяться. Но оно чуть сложнее первого типа мышления.

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

Рассмотрим на примере кода. У нас есть enum — список типов данных на служебном языке:

STRING

BOOL

DATE

INTEGER

DATETIME

DECIMAL

Мы должны обработать этот список так, чтобы выводить человеко-читаемые слова в зависимости от типа данных.

Условным (первым) типом мышления мы бы сделали так:

1) Добавили выборку switch в компоненте

component.ext 

switch (type) { 
  case 'DATE': 
    return 'Дата' 
  case 'STRING': 
    return 'Строка' 
  case 'BOOL': 
    return 'Булево' 
  case 'INTEGER': 
    return 'Число' 
 case 'DECIMAL': 
    return 'Десятичное' 
 case 'DATETIME': 
    return 'Время'
 default:
    return 'Без значения'
}

Типом мышления "Связи" (вторым) мы бы сделали так:

1) Создадим глобально (или локально) config file:

configs/data-types.js 

// так же будет использоваться в select компонентах 
export const dataTypes = [ 
  { 
    name: 'Строка', 
    value: 'STRING' 
  },
  {
    name: 'Булево', 
    value: 'BOOL' 
  },
  {
    name: 'Дата', 
    value: 'DATE' 
  },
  { 
    name: 'Число', 
    value: 'INTEGER' 
  }, 

  { 
    name: 'Время', 
    value: 'DATETIME' 
  }, 

  { 
    name: 'Десятичное', 
    value: 'DECIMAL' 
  } 
]

2) Добавим рядом вид-по-ключу (позволяет сделать вид "value: name" из массива):

configs/data-types.js 

export const dataTypesKeys = {} 

dataTypes.forEach(({ value, name }) => dataTypesKeys[value] = name)

3) Добавим выборку в компоненте:

component.ext 

import { dataTypesKeys } from 'src/configs/data-types'

const func = type => dataTypesKeys[type]

func('BOOL') // Булево

Подведем итоги способов мышления

1) С помощью первого образа мышления мы получили довольно простой механизм связи текста к служебным данным, но переиспользовать это мы уже не способны (лишь вынести в отдельную export функцию, но тогда мы потеряем чистоту статичных данных). А это большой минус, так как мы нарушаем DRY, хоть и потакаем KISS.

2) Второй способ мышления сложнее, но его можно переиспользовать и, благодаря ему, открывается множество способов на расширение, например мы можем модернизировать исходный массив в различные конфигурации объектов или массивов, как мы сделали под конец примера.

3) Благодаря второму способу мы можем с легкостью добавлять статичные данные и они будут доставлены во все компоненты и все зависимости.

4) Из минусов второго примера можно отметить, что при получении не записанного type мы получим undefined, а в первом мы способны поставить default опцию в switch и обработать это значение. Но нам стоит уточнить один важный факт: на back-end и на front-end статичные enum-ы должны иметь одинаковый набор данных, иначе это ожидаемая ошибка. Этот случай легко обходится во втором способе мышления добавлением нескольких символов:

component.ext 

import { dataTypesKeys } from 'src/configs/data-types'

const func = type => dataTypesKeys[type] ?? 'Без значения' // look at me

func('BOOL') // Булево

5) Этот подход работает только на статичных данных, динамичные же мы получает с нашего API.

6) Таким образом мы создали единственный главный источник истины и положили его глобально в директорию configs.

Комментарии (7)


  1. Nurked
    16.08.2023 12:42
    #25864218
    +4

    Эээ... В мире сейчас существуют матмодели с миллиардами входных параметров, и те зачастую такую муть выдают. Мы ещё даже не поняли как работает это ваше мышление. А вы тут на примерах из наименее структурированого языка в мире пытаетесь что-то описать.

    Вы говорите о человеческом мышлении. Это - целая вселенная. Причём у каждого она своя. Мы просто не привыкли обсуждать то, как мы сами настраиваем свои логические контуры. У кого-то мысль просто существует, а у кого-то в голове приходит клерк и выдаёт её записаной на бумажке. Кто-то может спокойно рассуждать о вкусе супа с потрохами и мозгом телятины, а кто-то о мысли о нём скукожится в точку.

    Все ваши программистские подходы разобьются о скалы реальности, когда вы попробуете это объяснить Эллочке с соседнего подъезда.


    1. Moskus
      16.08.2023 12:42
      #25865056
      +2

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

      Самый основной вопрос для "самопроверки" на подобный бред - это знаком ли индивидуум с существующими гипотезами о структуре мышления (если нет - марш изучать), и если да - то в каких отношениях (ортогональна, дополняет, исключает, корректирует) его гипотеза с другими, а главное - почему.

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


  1. Batalmv
    16.08.2023 12:42
    #25864728

    Я думаю, это банальная параметризация. Обычный прием, или даже техника. Она уже к мышлению особо не относится, а уже скорее ближе к рефлексам, при достаточном опыте.

    Возможно вам стоит копнуть в сторону граф баз данных, там хотя бы связи в явном виде есть, но это больше стуктурирование, чем мышление. Либо различные AI.

    Просто если бы вы больше дали инфы о способе мышления связями, можно дальше чего-то обсуждать. А так как почти сразу произошел переход к примеру - предмет обсуждения практически пропал


  1. Bender_Rodrigez
    16.08.2023 12:42
    #25865266
    +1

    В программировании (да и в жизни в целом) есть два типа мышления — условиями и связями.

    Можно придумать еще много "типов" мышления, например необходимостью или рациональностью. Все зависит от целей постулирования того или иного предположения.

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

    Третий способ мышления необходимостью - это когда можно бы построить дорогу без светофоров, но на въезде в пункт B узкая полоса пропускания, например таможня. И вот вы приезжаете в пункт В без светофоров, а там пробка на 30 км и вы все-равно стоите и ждете и не можете покинуть эту пробку, поскольку все возможные места для разворотов вы не то что проехали, у вас их наличие вообще не было учтено. И вот, нагрузка на пропускной пункт, дорожное полотно и нервы водителей и работников точки B возросла, т.к. психологически все ожидали упрощения жизни, а получилось в лучшем случае так же, но с еще более долгим ожиданием в конце (согласитесь, ведь движение с ограниченными и предсказуемыми по времени остановками психологически лучше переносится, нежели многочасовое столпотворение в тридцатиградусную жару).

    3) Благодаря второму способу мы можем с легкостью добавлять статичные данные и они будут доставлены во все компоненты и все зависимости.

    Благодаря третьему способу, мы можем оценить какую выгоду принесет вам данное решение. Например, в С++, enum из 10 значений, особенно если он имеет относительно законченное наполнение, switch будет работать быстрее map, т.к. имеет нативную поддержку. Конечно, не настолько, чтобы это заметить глазом в самом примитивном случае, но все же.

    Да, у вас есть весьма гибкий и удобный инструмент для расширения функциональности dataTypesKeys[value]. Но, в случае enum{true, false} он не дает никаких видимых преимуществ, кроме как возможность похвалиться самим наличием этого инструмента, и только усложняет понимание кода.

    Т.е. в зависимости от целесообразности вы можете обладать сразу двумя типами мышления, они, ведь, не взаимоисключающие. Так ведь? Формируется некоторое послевкусие лицемерия в позиции относительно заданной темы, которая как бы предполагает и настраивает аудиторию на то, что человек может следовать только одному из них.

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

    Все сложнее, чем хотелось бы, и желание сделать что-то простым, просто ограничив число доступных вариантов, не делает это проще - наоборот, все становится еще сложнее, сложнее в преодолении.


  1. AlexSteelax
    16.08.2023 12:42
    #25865346
    +2

    Похоже началась новая эпоха: когда посты с пикабу стали просачиваться на хабр.


  1. ptr128
    16.08.2023 12:42
    #25867642

    Третий тип мышления (названия придумывать не буду). Всё в БД. Доступ к данным - по индексу.

    Четвертый тип мышления. Вместо енум - макросы. И тогда в одном массиве имеем и индекс скрытый за макросом, и текст его характеризующий.

    Пятый тип мышления. Рефлексия, как смесь первого и второго типов.

    Хватит? Или ещё придумать?


  1. linchk
    16.08.2023 12:42
    #25869290

    Что так сложно то, типы мышления и т.п. Вопрос то простой будет ли меняться поведение функции возвращающей значение или нет? Хорошая практика при написании любого кода определится с типами данных и их жизненным циклом. Разбить яйцо можно множеством способов, но не все из них подойдут для приготовления яичницы. Вот и вся разница в мышлении. P.S. изучение языков функционального программирования очень сильно прокачивает скил проектирования архитектуры кода на любом языке программирования. Вот там вот как раз и реализуется возможность пощупать другой тип мышления, даже не ради того чтобы на них программировать, а просто ради того, чтобы иметь возможность смотреть на свой код несколько шире чем привык.