Потому что без этого дополнительного понятия я как то раз очень долго мучался над решением одной из задач и никак не мог решить ее, даже когда что то получалось при появлении новых требований все ломалось и опять несколько бессонных ночей впереди.
Т.е., как только я добавляю в ТД кэширование результатов, он становится АТД?
Да, если кэширование будет происходить в процессе вычислений в ТД и далее для сохранения этого кэша Вы будете вынуждены менять значения внутренних полей. У ТД по определению не может быть много вычислений т.к. его данные неизменны, по хорошему все вычисления при желании можно закэшировать при определении ТД, но метод для получения этих вычислений нужен все равно.
И еще раз — строгое следование правилам это ошибка. В данной статье хотел только дать пищу для размышления, возможно кому то это поможет в решении его задачь. Действовать надо в зависимости от контекста задачи, будьте гибче.
Скажу Вам честно, у самого возникал такой вопрос, чем ТД отличается от АТД по С.Макконнелла. А еще он же говорит, что в классах должны быть «нормальные» методы, да и на том же refactoring.guru пишут, что объекты данные это плохо. МакКоннелл вдохновил меня на такой подход, поэтому и упоянул его здесь, хотя про ТД в таком аспекте он не припомню чтобы говорил. По хорошему здесь описан несколько иной подход, я как бы расширил АТД добавив к нему ТД и описав требования к нему. В итоге у нас есть данные в виде ТД и структура которая работает с этими данными, назвал ее АТД т.к. это самое что не на есть наборы данных и методы работы с ними. Это все больше похоже на иной подход, но не буду говорить какой т.к. не хочу здесь устроить холивар.
Основное отличие ТД от АТД (по моему описанию), это то, что первый не может изменять свои данные в процессе вычислений производимых им самим, а второй может.
Если вычисление площади фигуры, вычисление хэшей по различным полям и т.п., не меняя свои данные, относить к действию/поведению, то пожалуй ничем по определению.
А если данные в ТД не могут меняться в процессе вычислений производимым им самим, то ТД не может обладать самостоятельным действием, он может только производить какие то вычисления над своими данными не меняя их.
Спасибо! Вы мне помогли сформулировать требование по поводу неизменяемости данных.
“Топ-11 самых частых ошибок в JavaScript” — ошибка №11: Ты следуешь всем правилам,
Давайте расмотрим еще один пример, у вас есть структура с данными из пяти значений и вам в некоторых местах кода требуется получить хэш по трем полям, где то по двум полям, где то сумма четырех значений, где то разность двух полей. Для данных в БД, для структуры, вам неизбежно придется писать все четыре функции и брать на себя риски, что во всем коде будут использоваться именно эти функции, чем меньше/проще приложение, тем проще это отслеживать. А если вы используете класс с этими пятью полями, то кто вам мешает написать эти четыре функции в нем и быть уверенным, что везде где используются эти данные будут вызваны именно эти функции и всегда когда они изменятся изменения будут работать во всем коде, какой бы сложный и большой он не был.
Т.о. первая задача которая стоит перед нами, это корректное выделение данных из всего нас окружающего, данных к которым будем применять действие.
В реляционной БД например есть таблицы и методов у таблицы быть не может. Структуры в различных языках программирования это так же наборы данных без методов работы с ними. В классах ООП же можно написать и даже нужно написать методы работы с данными, да, это пожалуй то же самое о чем и говорит МакКоннелл, просто развил мысль дальше и во второй части описал как можно управлять всеми данными которые имеем и это назвал АТД, т.к. одна единица ТД может работать только со своими данными, а нам как правило надо управлять набором данных.
Тогда это не будет Тип Данных по вашему определению.
Где Вы такое увидели, подскажите?
ТД должен уметь работать только со своими данными (полями)
По моему везде говорится о работе ТД с данными. Только в реляционной БД это не так, об этом так же сказано.
Все вокруг нас это данные и надо их корректно выделять, а как работать с ними это уже другой вопрос, об этом и идет речь.
Любой «результат» — это следствие поведения. Нет поведения — нет результата.
Данная статья посвящена выделению данных, управлением данными занимается уже АТД и об этом во второй части. Просто надо пользоваться всеми доступными возможностями, а не строго следовать правилам, например в ООП можно написать методы работы с данными.
Ну то есть правила — они и не правила, получаются.
А Вы знаете волшебную таблетку, так чтобы правила работали абсолютно везде? Может и есть такие, но я о них не знаю, не претендую на гениальность и решение всех проблем мира разом, одним ударом. Меня вдохновил С.Макконнел, надеюсь и мои мысли кого то на что то да натолкнут.
Как то вы категорично размышляете, либо так, либо эдак и нваерное прочитали все мельком, наспех.
Вот что я написал:
Далее, выделенные данные (совокупность объекта мира и его параметров) буду определять как Тип Данных (далее ТД).
Т.е. в данной статье Тип Данных рассматривается как совокупность объекта мира и его параметров, а не как тип данных одного из языков программирования. Данную формулировку посчитал наиболее подходящей т.к. изначально речь идет об Абстрактном ТД в ООП о котором написал С.Макконнел.
Об этом так же писал и даже писал что в ТД реляционной БД и ТД ООП есть принципиальное отлицие, и даже писал что «Обекты данных» являются плохим тоном в ООП.
Согласно нему, у Типа Данных нет поведения. Как можно отличить «непредсказуемое» изменение от «предсказуемого»?
Речь идет не о поведении, а о результате работы с данными.
Ну да. Вот мне надо получить ответ на вопрос «сколько параллелограммов учтено в системе». М?
Мое решение не панацея, об этом и написал, все зависит от контекста исполняемой задачи, если вам чаще требуется получать кол-во параллелограммов в системе, нежеди сколько только квадратов или только прямоугольников или т.п., то конечно можно все в одной таблице разместить.
Так вы о типах данных или о сущностях? А если о сущностях, то по какому определению сущности?
Тип Данных как набор данных. С.Макконнел говорит об АТД как набор, включающий данные. Описал как выделить данные чтобы потом было с ними легче работать.
Ну так целое число, дата или строка — это разве не «сущность, единица, с которой потом далее мы прозводим работу»?
Сущность, если для начала отвечает на вопрос «кто?» или «что?», даже если состоит из одного примитива или даты.
Мы пока даже не определились, относятся ли эти правила к таблицам
Вернемся к примеру про параллелограммы (ромб, прямоугольник и квадрат), в БД хранятся данные об этих фигурах, Вы вправе сделать для всех фигур одну таблицу, тогда каждый раз при выборке данных Вам надо будет ставить условие WHERE (если мы говорим только о БД), аналог условного операвтора в программном коде. Нужен Вам этот оператор или нет, решать только Вам, но чем больше условных операторов, тем сложнее производить работу с данными и тем дороже приложение в своей работе. Разве нет?
Если придерживаться этих правил, то у Вас будет одна таблица и в дальнейшем с ней будет работать проще, правила и должны к этому привести.
Что именно противоречит требованию иммутабельности?
Типы Данных здесь не подразумевается как какие то скалярные типы или ссылочные. Здесь больше подразумевается как сущность, единица с которой потом далее мы производим работу. Когда мы определяем класс в ООП мы создаем новый Тип Данных на основе которого далее создаются объекты.
В реляционной БД теоретически, во избежания аномалий работы с данными Вы можете создать несколько таблиц, Но придерживаясь правил которые предоставил выше вероятней всего это будет одна таблица, если это будет несколько таблиц, то вы что то сделали не так.
Да, в данном контексте таблица рассматривается как тип данных, не скалярный тип. Нормализация отношений это уже отдельный вопрос, так один тип данных в реляционной БД может состоять из нескольких таблиц.
Потому что без этого дополнительного понятия я как то раз очень долго мучался над решением одной из задач и никак не мог решить ее, даже когда что то получалось при появлении новых требований все ломалось и опять несколько бессонных ночей впереди.
Да, если кэширование будет происходить в процессе вычислений в ТД и далее для сохранения этого кэша Вы будете вынуждены менять значения внутренних полей. У ТД по определению не может быть много вычислений т.к. его данные неизменны, по хорошему все вычисления при желании можно закэшировать при определении ТД, но метод для получения этих вычислений нужен все равно.
И еще раз — строгое следование правилам это ошибка. В данной статье хотел только дать пищу для размышления, возможно кому то это поможет в решении его задачь. Действовать надо в зависимости от контекста задачи, будьте гибче.
Основное отличие ТД от АТД (по моему описанию), это то, что первый не может изменять свои данные в процессе вычислений производимых им самим, а второй может.
А если данные в ТД не могут меняться в процессе вычислений производимым им самим, то ТД не может обладать самостоятельным действием, он может только производить какие то вычисления над своими данными не меняя их.
Спасибо! Вы мне помогли сформулировать требование по поводу неизменяемости данных.
Давайте расмотрим еще один пример, у вас есть структура с данными из пяти значений и вам в некоторых местах кода требуется получить хэш по трем полям, где то по двум полям, где то сумма четырех значений, где то разность двух полей. Для данных в БД, для структуры, вам неизбежно придется писать все четыре функции и брать на себя риски, что во всем коде будут использоваться именно эти функции, чем меньше/проще приложение, тем проще это отслеживать. А если вы используете класс с этими пятью полями, то кто вам мешает написать эти четыре функции в нем и быть уверенным, что везде где используются эти данные будут вызваны именно эти функции и всегда когда они изменятся изменения будут работать во всем коде, какой бы сложный и большой он не был.
В реляционной БД например есть таблицы и методов у таблицы быть не может. Структуры в различных языках программирования это так же наборы данных без методов работы с ними. В классах ООП же можно написать и даже нужно написать методы работы с данными, да, это пожалуй то же самое о чем и говорит МакКоннелл, просто развил мысль дальше и во второй части описал как можно управлять всеми данными которые имеем и это назвал АТД, т.к. одна единица ТД может работать только со своими данными, а нам как правило надо управлять набором данных.
Где Вы такое увидели, подскажите?
По моему везде говорится о работе ТД с данными. Только в реляционной БД это не так, об этом так же сказано.
Все вокруг нас это данные и надо их корректно выделять, а как работать с ними это уже другой вопрос, об этом и идет речь.
Данная статья посвящена выделению данных, управлением данными занимается уже АТД и об этом во второй части. Просто надо пользоваться всеми доступными возможностями, а не строго следовать правилам, например в ООП можно написать методы работы с данными.
А Вы знаете волшебную таблетку, так чтобы правила работали абсолютно везде? Может и есть такие, но я о них не знаю, не претендую на гениальность и решение всех проблем мира разом, одним ударом. Меня вдохновил С.Макконнел, надеюсь и мои мысли кого то на что то да натолкнут.
Вот что я написал:
Т.е. в данной статье Тип Данных рассматривается как совокупность объекта мира и его параметров, а не как тип данных одного из языков программирования. Данную формулировку посчитал наиболее подходящей т.к. изначально речь идет об Абстрактном ТД в ООП о котором написал С.Макконнел.
Об этом так же писал и даже писал что в ТД реляционной БД и ТД ООП есть принципиальное отлицие, и даже писал что «Обекты данных» являются плохим тоном в ООП.
Речь идет не о поведении, а о результате работы с данными.
Мое решение не панацея, об этом и написал, все зависит от контекста исполняемой задачи, если вам чаще требуется получать кол-во параллелограммов в системе, нежеди сколько только квадратов или только прямоугольников или т.п., то конечно можно все в одной таблице разместить.
Тип Данных как набор данных. С.Макконнел говорит об АТД как набор, включающий данные. Описал как выделить данные чтобы потом было с ними легче работать.
Сущность, если для начала отвечает на вопрос «кто?» или «что?», даже если состоит из одного примитива или даты.
Вернемся к примеру про параллелограммы (ромб, прямоугольник и квадрат), в БД хранятся данные об этих фигурах, Вы вправе сделать для всех фигур одну таблицу, тогда каждый раз при выборке данных Вам надо будет ставить условие WHERE (если мы говорим только о БД), аналог условного операвтора в программном коде. Нужен Вам этот оператор или нет, решать только Вам, но чем больше условных операторов, тем сложнее производить работу с данными и тем дороже приложение в своей работе. Разве нет?
За один тип данных (набора данных примитивного типа) будет отвечать одна таблица, да.
Важнее это. Требование про неизменчивость удалил, вероятно лишнее.
Что именно противоречит требованию иммутабельности?
В реляционной БД теоретически, во избежания аномалий работы с данными Вы можете создать несколько таблиц, Но придерживаясь правил которые предоставил выше вероятней всего это будет одна таблица, если это будет несколько таблиц, то вы что то сделали не так.
Может Вы подскажите язык с ООП где нет классов? Вы ведь начали говорить о таком.
Один из пример языка где есть классы это Java
В первом комментарии упомянули о Монадах, к ним пожалуй и относится — единица, простая сущность, «единое, как неделимое»