Параметры: +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)
Batalmv
16.08.2023 12:42Я думаю, это банальная параметризация. Обычный прием, или даже техника. Она уже к мышлению особо не относится, а уже скорее ближе к рефлексам, при достаточном опыте.
Возможно вам стоит копнуть в сторону граф баз данных, там хотя бы связи в явном виде есть, но это больше стуктурирование, чем мышление. Либо различные AI.
Просто если бы вы больше дали инфы о способе мышления связями, можно дальше чего-то обсуждать. А так как почти сразу произошел переход к примеру - предмет обсуждения практически пропал
Bender_Rodrigez
16.08.2023 12:42+1В программировании (да и в жизни в целом) есть два типа мышления — условиями и связями.
Можно придумать еще много "типов" мышления, например необходимостью или рациональностью. Все зависит от целей постулирования того или иного предположения.
Приведем пример из жизни — у нас есть дорога, по ней едет транспорт. Первый образ мышления — это светофоры, которые переключаются чтобы одни ехали, а другие ожидали своего хода. Так вот второй способ мышления — это отсутствие светофоров и постройка дороги так, чтобы никто никого не ждал и не останавливался, все движение постоянно и, по своей траектории, перетекает от одного пути в другой.
Третий способ мышления необходимостью - это когда можно бы построить дорогу без светофоров, но на въезде в пункт B узкая полоса пропускания, например таможня. И вот вы приезжаете в пункт В без светофоров, а там пробка на 30 км и вы все-равно стоите и ждете и не можете покинуть эту пробку, поскольку все возможные места для разворотов вы не то что проехали, у вас их наличие вообще не было учтено. И вот, нагрузка на пропускной пункт, дорожное полотно и нервы водителей и работников точки B возросла, т.к. психологически все ожидали упрощения жизни, а получилось в лучшем случае так же, но с еще более долгим ожиданием в конце (согласитесь, ведь движение с ограниченными и предсказуемыми по времени остановками психологически лучше переносится, нежели многочасовое столпотворение в тридцатиградусную жару).
3) Благодаря второму способу мы можем с легкостью добавлять статичные данные и они будут доставлены во все компоненты и все зависимости.
Благодаря третьему способу, мы можем оценить какую выгоду принесет вам данное решение. Например, в С++, enum из 10 значений, особенно если он имеет относительно законченное наполнение, switch будет работать быстрее map, т.к. имеет нативную поддержку. Конечно, не настолько, чтобы это заметить глазом в самом примитивном случае, но все же.
Да, у вас есть весьма гибкий и удобный инструмент для расширения функциональности
dataTypesKeys[value]. Но, в случае enum{true, false} он не дает никаких видимых преимуществ, кроме как возможность похвалиться самим наличием этого инструмента, и только усложняет понимание кода.Т.е. в зависимости от целесообразности вы можете обладать сразу двумя типами мышления, они, ведь, не взаимоисключающие. Так ведь? Формируется некоторое послевкусие лицемерия в позиции относительно заданной темы, которая как бы предполагает и настраивает аудиторию на то, что человек может следовать только одному из них.
Т.О. мы имеем попытку зафиксировать позицию, что имеется всего два типа мышления, возможно, для удобства продвижения собственной позиции в будущем, как правдивую и единственно возможную, хотя очевидно, что это не так.
Все сложнее, чем хотелось бы, и желание сделать что-то простым, просто ограничив число доступных вариантов, не делает это проще - наоборот, все становится еще сложнее, сложнее в преодолении.
AlexSteelax
16.08.2023 12:42+2Похоже началась новая эпоха: когда посты с пикабу стали просачиваться на хабр.
ptr128
16.08.2023 12:42Третий тип мышления (названия придумывать не буду). Всё в БД. Доступ к данным - по индексу.
Четвертый тип мышления. Вместо енум - макросы. И тогда в одном массиве имеем и индекс скрытый за макросом, и текст его характеризующий.
Пятый тип мышления. Рефлексия, как смесь первого и второго типов.
Хватит? Или ещё придумать?
linchk
16.08.2023 12:42Что так сложно то, типы мышления и т.п. Вопрос то простой будет ли меняться поведение функции возвращающей значение или нет? Хорошая практика при написании любого кода определится с типами данных и их жизненным циклом. Разбить яйцо можно множеством способов, но не все из них подойдут для приготовления яичницы. Вот и вся разница в мышлении. P.S. изучение языков функционального программирования очень сильно прокачивает скил проектирования архитектуры кода на любом языке программирования. Вот там вот как раз и реализуется возможность пощупать другой тип мышления, даже не ради того чтобы на них программировать, а просто ради того, чтобы иметь возможность смотреть на свой код несколько шире чем привык.
Nurked
Эээ... В мире сейчас существуют матмодели с миллиардами входных параметров, и те зачастую такую муть выдают. Мы ещё даже не поняли как работает это ваше мышление. А вы тут на примерах из наименее структурированого языка в мире пытаетесь что-то описать.
Вы говорите о человеческом мышлении. Это - целая вселенная. Причём у каждого она своя. Мы просто не привыкли обсуждать то, как мы сами настраиваем свои логические контуры. У кого-то мысль просто существует, а у кого-то в голове приходит клерк и выдаёт её записаной на бумажке. Кто-то может спокойно рассуждать о вкусе супа с потрохами и мозгом телятины, а кто-то о мысли о нём скукожится в точку.
Все ваши программистские подходы разобьются о скалы реальности, когда вы попробуете это объяснить Эллочке с соседнего подъезда.
Moskus
Пытаться делать утверждение о мышлении человека на основе безосновательной экстраполяции какого-то "поведения" компьютерных систем - типичный дремучий бред молодых или не очень психически здоровых программистов (в широком смысле этого слова, как типажа, а не непосредственного занятия).
Самый основной вопрос для "самопроверки" на подобный бред - это знаком ли индивидуум с существующими гипотезами о структуре мышления (если нет - марш изучать), и если да - то в каких отношениях (ортогональна, дополняет, исключает, корректирует) его гипотеза с другими, а главное - почему.
Если автор гипотезы ответ дать не может, эти измышления - в топку, как говорится.