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