Comments 70
Я зашёл почитать про ADT, а вместо этого увидел упоминание 1C.
Я боюсь того дня, когда у нас будет 1C: Монада для управления расписанием уборки туалетов.
В концепции ООП ТД это класс
А вы в курсе про то, что бывает ООП без классов?
… что же делать с ООП, в котором классов нет?
Так что же соответствует типу данных в ООП без классов?
Я не владею вопросом ООП без классов
Тогда, пожалуйста, не говорите о концепции ООП. Ограничьте свои высказывание ООП, основанным на классах.
А можно тогда пример мейнстримного языка, в котором такой используется такой подход к ООП?
А можно тогда пример мейнстримного языка, в котором такой используется такой подход к ООП?
Может Вы подскажите язык с ООП где нет классов? Вы ведь начали говорить о таком.
Один из пример языка где есть классы это Java
Может Вы подскажите язык с ООП где нет классов?
Много их, но первыми на ум приходят JavaScript, Lisp и Lua.
Один из пример языка где есть классы это Java
А еще там есть примитивные значения. Они не типы данных?
В реляционной БД теоретически, во избежания аномалий работы с данными Вы можете создать несколько таблиц, Но придерживаясь правил которые предоставил выше вероятней всего это будет одна таблица, если это будет несколько таблиц, то вы что то сделали не так.
Здесь больше подразумевается как сущность, единица с которой потом далее мы производим работу.
Ну так целое число, дата или строка — это разве не "сущность, единица, с которой потом далее мы прозводим работу"?
А в соседнем C# еще и структуры есть, которые не классы, а структуры. Они Типы Данных или нет?
Но придерживаясь правил которые предоставил выше вероятней всего это будет одна таблица, если это будет несколько таблиц, то вы что то сделали не так.
Мы пока даже не определились, относятся ли эти правила к таблицам.
Ну так целое число, дата или строка — это разве не «сущность, единица, с которой потом далее мы прозводим работу»?
Сущность, если для начала отвечает на вопрос «кто?» или «что?», даже если состоит из одного примитива или даты.
Мы пока даже не определились, относятся ли эти правила к таблицам
Вернемся к примеру про параллелограммы (ромб, прямоугольник и квадрат), в БД хранятся данные об этих фигурах, Вы вправе сделать для всех фигур одну таблицу, тогда каждый раз при выборке данных Вам надо будет ставить условие WHERE (если мы говорим только о БД), аналог условного операвтора в программном коде. Нужен Вам этот оператор или нет, решать только Вам, но чем больше условных операторов, тем сложнее производить работу с данными и тем дороже приложение в своей работе. Разве нет?
Сущность, если для начала отвечает на вопрос «кто?» или «что?»
Так вы о типах данных или о сущностях? А если о сущностях, то по какому определению сущности?
Вернемся к примеру про параллелограммы
Ну да. Вот мне надо получить ответ на вопрос "сколько параллелограммов учтено в системе". М?
Ну да. Вот мне надо получить ответ на вопрос «сколько параллелограммов учтено в системе». М?
Мое решение не панацея, об этом и написал, все зависит от контекста исполняемой задачи, если вам чаще требуется получать кол-во параллелограммов в системе, нежеди сколько только квадратов или только прямоугольников или т.п., то конечно можно все в одной таблице разместить.
Так вы о типах данных или о сущностях? А если о сущностях, то по какому определению сущности?
Тип Данных как набор данных. С.Макконнел говорит об АТД как набор, включающий данные. Описал как выделить данные чтобы потом было с ними легче работать.
все зависит от контекста исполняемой задачи
Ну то есть правила — они и не правила, получаются.
Тип Данных как набор данных.
Значит, сущности не при чем. Выкидываем сущности, возвращаемся к вопросу: целые числа, строки или даты — это Типы Данных или нет?
Вот что я написал:
Далее, выделенные данные (совокупность объекта мира и его параметров) буду определять как Тип Данных (далее ТД).
Т.е. в данной статье Тип Данных рассматривается как совокупность объекта мира и его параметров, а не как тип данных одного из языков программирования. Данную формулировку посчитал наиболее подходящей т.к. изначально речь идет об Абстрактном ТД в ООП о котором написал С.Макконнел.
Ну то есть правила — они и не правила, получаются.
А Вы знаете волшебную таблетку, так чтобы правила работали абсолютно везде? Может и есть такие, но я о них не знаю, не претендую на гениальность и решение всех проблем мира разом, одним ударом. Меня вдохновил С.Макконнел, надеюсь и мои мысли кого то на что то да натолкнут.
Данные должны быть неизменяемые (immutable) [...] неизменяемые данные объекта принято называть “внутренним состоянием”.
Нет, не "принято". Внутреннее состояние объекта — это все то состояние, которое не видно снаружи. И если оно состояние, то достаточно странно называть его неизменяемым.
Александр Швец, “Погружение в паттерны проектирования”, паттерн “Легковес” — неизменяемые данные объекта принято называть “внутренним состоянием”
Именно об этом идет речь.
Я не знаю, кто такой "Александр Швец", и его мнение не является для меня никаким авторитетом. Вы могли бы привести полную цитату, чтобы можно было по крайней мере понять контекст этого высказывания?
При этом, скажем SO со мной согласен.
Неизменяемые данные объекта принято называть «внутрен-
ним состоянием». Все остальные данные — это «внешнее состояние».
Считаю это все уже просто игра слов, в данной статье подразумевается именно неизменяемые данные.
Я купил его книгу на refactoring.guru, считаю этот ресурс достаточно авторитетным
И про этот ресурс я тоже первый раз слышу.
в данной статье подразумевается именно неизменяемые данные.
Тогда уберите из статьи все упоминания состояния. Если АТД должен быть immutable, у него нет состояния.
… так вот, если данные в ТД неизменны, то в СУБД ТД принципиально нет (ой). Да и в ООП начинаются большие проблемы, прямо скажем.
Далее, выделенные данные (совокупность объекта мира и его параметров) буду определять как Тип Данных (далее ТД).
Да и в ООП начинаются большие проблемы, прямо скажем.
В последнем параграфе написал, волшебной таблетки не бывает, это один лишь прием из множества возможных.
Тип Данных это определение которое дал именно в этой статье
Так оно относится к данным в БД или нет? И если нет, то к чему оно относится?
В последнем параграфе написал, волшебной таблетки не бывает, это один лишь прием из множества возможных.
Я не знаю, о каких "приемах" вы говорите, я цитирую ваши "требования к ТД".
Так оно относится к данным в БД или нет? И если нет, то к чему оно относится?
В первом комментарии упомянули о Монадах, к ним пожалуй и относится — единица, простая сущность, «единое, как неделимое»
Давайте сначала с БД разберемся.
(потому что обычно, когда говорят о программировании, под монадами понимают не то, что вы написали)
Давайте сначала с БД разберемся.
Т.о. это различные типы данных, в ООП эти фигуры должны быть представлены различными классами и различными таблицами в реляционной БД
Так таблица в реляционной БД — это тип данных или нет?
Это противоречит вашему требованию на иммутабельность.
Что-то у вас не так в фундаментальных определениях.
Что именно противоречит требованию иммутабельности?
Если придерживаться этих правил, то у Вас будет одна таблица
… одна таблица в БД? Или что?
Что именно противоречит требованию иммутабельности?
Данные в таблицах РСУБД по определению мутабельны.
(я не рассматриваю редкий случай append-only databases, мне почему-то кажется, что вы вряд ли про них)
одна таблица в БД? Или что?
За один тип данных (набора данных примитивного типа) будет отвечать одна таблица, да.
Бойтесь/избегайте непредсказуемого изменения данных
Важнее это. Требование про неизменчивость удалил, вероятно лишнее.
За один тип данных (набора данных примитивного типа) будет отвечать одна таблица, да.
… а почему? И что такое "примитивный тип"?
Бойтесь/избегайте непредсказуемого изменения данных
Ну давайте это обсудим. Возьмем ваше "определение":
Далее, выделенные данные (совокупность объекта мира и его параметров) буду определять как Тип Данных (далее ТД).
Согласно нему, у Типа Данных нет поведения. Как можно отличить "непредсказуемое" изменение от "предсказуемого"?
И методов у таких классов быть тоже не может.
И методов у таких классов быть тоже не может.
Об этом так же писал и даже писал что в ТД реляционной БД и ТД ООП есть принципиальное отлицие, и даже писал что «Обекты данных» являются плохим тоном в ООП.
Согласно нему, у Типа Данных нет поведения. Как можно отличить «непредсказуемое» изменение от «предсказуемого»?
Речь идет не о поведении, а о результате работы с данными.
стремление избежать непредсказуемости результата
Об этом так же писал
Ну так определение-то не изменилось от того, что вы писали. Как не могло быть методов, так и не может. Или у вас в определении ошибка?
даже писал что «Обекты данных» являются плохим тоном в ООП.
Вот только к типам данных это отношения не имеет.
результате работы с данными.
Любой "результат" — это следствие поведения. Нет поведения — нет результата.
Любой «результат» — это следствие поведения. Нет поведения — нет результата.
Данная статья посвящена выделению данных, управлением данными занимается уже АТД и об этом во второй части. Просто надо пользоваться всеми доступными возможностями, а не строго следовать правилам, например в ООП можно написать методы работы с данными.
управлением данными занимается уже АТД и об этом во второй части.
Это значит, что применительно к Типам Данных бесполезно говорить о "работе с данными" и ее "результате".
например в ООП можно написать методы работы с данными.
Тогда это не будет Тип Данных по вашему определению.
Ну или у вас проблема с определениями.
Тогда это не будет Тип Данных по вашему определению.
Где Вы такое увидели, подскажите?
ТД должен уметь работать только со своими данными (полями)
По моему везде говорится о работе ТД с данными. Только в реляционной БД это не так, об этом так же сказано.
Все вокруг нас это данные и надо их корректно выделять, а как работать с ними это уже другой вопрос, об этом и идет речь.
Где Вы такое увидели, подскажите?
Там, где "выделенные данные (совокупность объекта мира и его параметров) буду определять как Тип Данных (далее ТД)". Это значит, что поведения нет, есть только данные.
По моему везде говорится о работе ТД с данными.
Без определения понятия "работа с данными" это бессмысленно.
Еще раз: либо Тип Данных может иметь поведение, либо нет. Если может, то чем он отличается от абстрактного типа данных по МакКоннелу?
Т.о. первая задача которая стоит перед нами, это корректное выделение данных из всего нас окружающего, данных к которым будем применять действие.
В реляционной БД например есть таблицы и методов у таблицы быть не может. Структуры в различных языках программирования это так же наборы данных без методов работы с ними. В классах ООП же можно написать и даже нужно написать методы работы с данными, да, это пожалуй то же самое о чем и говорит МакКоннелл, просто развил мысль дальше и во второй части описал как можно управлять всеми данными которые имеем и это назвал АТД, т.к. одна единица ТД может работать только со своими данными, а нам как правило надо управлять набором данных.
Я повторю свой вопрос: чем ваш Тип Данных отличается от АТД по МакКоннелу, если ваш Тип Данных может иметь поведение?
А если данные в ТД не могут меняться в процессе вычислений производимым им самим, то ТД не может обладать самостоятельным действием, он может только производить какие то вычисления над своими данными не меняя их.
Спасибо! Вы мне помогли сформулировать требование по поводу неизменяемости данных.
Если вычисление площади фигуры, вычисление хэшей по различным полям и т.п., не меняя свои данные, относить к действию/поведению, то пожалуй ничем по определению.
Конечно, относить. А почему нет?
Основное отличие ТД от АТД (по моему описанию), это то, что первый не может изменять свои данные в процессе вычислений производимых им самим, а второй может.
Скажу Вам честно, у самого возникал такой вопрос, чем ТД отличается от АТД по С.Макконнелла
А зачем вы вообще ввели дополнительное понятие?
По хорошему здесь описан несколько иной подход, я как бы расширил АТД добавив к нему ТД и описав требования к нему.
Для того, чтобы расширять что-то, надо с этим чем-то разобраться, а к определению АТД мы даже еще не приблизились.
Основное отличие ТД от АТД (по моему описанию), это то, что первый не может изменять свои данные в процессе вычислений производимых им самим, а второй может.
Т.е., как только я добавляю в ТД кэширование результатов, он становится АТД?
В чем смысл этого разделения?
А зачем вы вообще ввели дополнительное понятие?
Потому что без этого дополнительного понятия я как то раз очень долго мучался над решением одной из задач и никак не мог решить ее, даже когда что то получалось при появлении новых требований все ломалось и опять несколько бессонных ночей впереди.
Т.е., как только я добавляю в ТД кэширование результатов, он становится АТД?
Да, если кэширование будет происходить в процессе вычислений в ТД и далее для сохранения этого кэша Вы будете вынуждены менять значения внутренних полей. У ТД по определению не может быть много вычислений т.к. его данные неизменны, по хорошему все вычисления при желании можно закэшировать при определении ТД, но метод для получения этих вычислений нужен все равно.
И еще раз — строгое следование правилам это ошибка. В данной статье хотел только дать пищу для размышления, возможно кому то это поможет в решении его задачь. Действовать надо в зависимости от контекста задачи, будьте гибче.
Потому что без этого дополнительного понятия я как то раз очень долго мучался над решением одной из задач и никак не мог решить ее
Какой задачи? Почему понятия АТД было недостаточно для ее решения?
У ТД по определению не может быть много вычислений т.к. его данные неизменны
Не вижу никакой связи между изменяемостью данных и объемом вычислений. Представьте себе ТД, описывающий матрицу (из линейной алгебры), и операцию, которая делает декомпозицию этой матрицы.
Да, если кэширование будет происходить в процессе вычислений в ТД и далее для сохранения этого кэша Вы будете вынуждены менять значения внутренних полей.
Так зачем нужно это разделение, если простое добавление кэша, не меняющее наблюдаемое поведение (кроме производительности), меняет категорию объекта?
Какой задачи? Почему понятия АТД было недостаточно для ее решения?
Какой именно задачи не могу сказать в силу юредических ньюансов, но во второй части привел пример который на мой взгляд подходит для подобной ситуации. Понятия АТД не хватало т.к. работать приходилось не только с классами ООП, для них вероятно и достаточно его определения, а вот как быть с данными в БД, у таблиц ведь не напишешь свои методы, а еще и для работы с БД используется Data Mapper. Вот и пришёл к тому, что для начала надо корректно выделить данные из окружающего нас мира, с которыми в дальнейшем будет легко работать.
во второй части привел пример который на мой взгляд подходит для подобной ситуации
Ваша "вторая часть" работает с АТД. Никаких достоинств ТД как отдельной категории там нет.
Понятия АТД не хватало т.к. работать приходилось не только с классами ООП
Вообще-то, понятие АТД намного шире, чем классы ООП.
вот как быть с данными в БД
Для них есть ER-модели.
еще и для работы с БД используется Data Mapper
А это описано в PoEAA у Фаулера, и никак не связано с АТД.
для начала надо корректно выделить данные из окружающего нас мира
Это называется "построение модели". Вводить понятие "типа данных" для этого не нужно. Методик моделирования сильно больше одной.
Ну и да, ничто из описанного вами не объясняет, зачем нужно разделение на АТД и ТД по признаку "не изменяет данные при вычислениях".
Вообще-то, понятие АТД намного шире, чем классы ООП.
Статья не о ADT, в самом начале и было написано что подразумевается под АТД. ADT действительно понятие широкое и эта статья явно не о нем.
Для них есть ER-модели.
Должен признаться не совсем пойму к чему это, каким образом постороение модели Сущность-Отношение поможет? Более того, как раз эти правила и помогут корректно составить модель БД, да и Вы ниже написали, что это уже вопрос не ТД, а построения модели.
А это описано в PoEAA у Фаулера, и никак не связано с АТД.
Здесь я описал как выделить данные (сущность мира и минимально избыточные параметры), Data Mapper упомянул потому, что если все запихнуть в одну таблицу, то и в коде ООП это все будет в одном классе (если не заниматься извращениями), что приведет ко множеству IF, а это значит и логика усложнится, и поддержка станет сложнее и в производительности приложение станет дороже (почему, я как раз написал в примере с параллелограммом).
Ну и да, ничто из описанного вами не объясняет, зачем нужно разделение на АТД и ТД по признаку «не изменяет данные при вычислениях».
Как уже писал выше, у самого возникал вопросы по АТД и ТД. Опишу чуть по подробнее, для чего это все надо было, как к этому пришёл:
1. Поступила задача — написать систему по учёту «чего то там» (не буду конкретизировать в силу трудового договора) и на основе этого получать «что то». Вроде все просто, написал сервисный класс в котором вся логика работы. ну и дело в шляпе.
2. Поступила задача — добавить в систему функционал по работе еще там с «чем то». Еще один сервисный класс и дело в шляпе.
3. Поступила задаче — добавить функционал по работе еще с «чем то». Еще один класс и дело в шляпе.
4. Поступила задача — первое «что то» оказывается влияет на второе «что то». Хм, пришлось подумать, как два сервиссных класса совместить.
5. Поступила задача — второе «что то» влияет на третье «что то», в свою очередь третье «что то» влияет на первое «что то». Кроме этого, надо добавить функционал для работы с еще «чем то» который в свою очередь влияет на третье «что то», ну а как мы помним третье «что то» влияет на первое «что то». Хм, вот тут бессонные ночи и начались. Ладно, кое как сделал, даже тесты проходят.
6. Поступила задача добавить еще «что то» которое в свою очередь влияет на первое и второе «что то». Хм, при малейшем пчихе все тесты повалились, несколько бессонных ночей никчему не привели.
Что делать, уволят ведь!?
Тут я вспомнил про АТД С.Макконнелла и меня посетила мысль, может от каждого функционала получать нужные данные, собирать их в одном месте и управлять ими как только потредуется!? В итоге перешел на «провайдеры данных» которые получают нужные данные от кажного «чего то там», создаю класс (АТД по С.Макконнелу), передаю в него данные от всех провайдеров данных и далее уже работаю в нем с этими данными, сравниваю эти данные, меняю данные первого «чего то там» в зависимости от данных второго «что то там» и т.д. и т.п.
В итоге получилась очень гибкая система, можно добавить любой функционал или изменить старый без лишних хлопот. Заказчик очень доволен и сам своим глазам не верит, что все работает и работает стабильно (подобный пример во второй части и описал).
Решил поделится своими мыслями, возможно кого то это так же натолкнет на хорошее решение его задач.
Вот и вопрос, отличаются ли данные полученные провайдерами данных от АТД в котором происходит работа с ними? Думаю отличаются, как минимум по функциональным возможностям, возможно Вы меня и натолкнете на правильную формулировку.
К чему пришел, как выделять данные с которыми далее работать в АТД здесь и написал. Да, с формулировками у меня сложновато, но если варится в своем соку сами по себе они не появятся.
Статья не о ADT
А почему в заголовке тогда написано "Абстрактный тип данных"?
самом начале и было написано что подразумевается под АТД
… определение по МакКоннелу. Оно не противоречит тому, что я сказал.
Должен признаться не совсем пойму к чему это, каким образом постороение модели Сущность-Отношение поможет?
Ровно таким, что оно описывает то, что вы пытаетесь назвать Типом Данных применительно к РСУБД.
Data Mapper упомянул потому, что если все запихнуть в одну таблицу, то и в коде ООП это все будет в одном классе
Нет, не будет. Весь смысл Data Mapper как паттерна в том, что объектная модель не обязана соответствовать реляционной.
что приведет ко множеству IF,
Нет, не приведет.
db.Get<Square>(); //вот вам квадраты
db.Get<Rectangle>(); //вот вам прямоугольники
db.Get<Circle>(); //вот вам круги
db.Get<Shape>(); //вот вам все фигурыЧто делать, уволят ведь!?
Давайте я вам быстренько объясню, что делать. Читаете Эванса, декомпонуете вашу задачу на доменные сущности, те группируете в агрегаты, размещаете логику в сущностях, профит. Никаких нововведенных Типов Данных.
меня посетила мысль, может от каждого функционала получать нужные данные, собирать их в одном месте и управлять ими как только потредуется
… которая никак с АТД по МакКоннелу не связана. Но посетила вас, да.
создаю класс (АТД по С.Макконнелу), передаю в него данные от всех провайдеров данных и далее уже работаю в нем с этими данными, сравниваю эти данные, меняю данные первого «чего то там» в зависимости от данных второго «что то там» и т.д. и т.п.
Это называется god object. В вашем случае — god class. Не надо так.
И нет, это не АТД. Это ровно наоборот.
Вот и вопрос, отличаются ли данные полученные провайдерами данных от АТД в котором происходит работа с ними?
А что такое "провайдер данных", и почему он возвращает не АТД?
Думаю отличаются, как минимум по функциональным возможностям
А я думаю, что это будет зависеть исключительно от того, что такое "провайдер данных", и как он работает.
Это называется god object.
Это совсем совсем о другом.
Такое ощущение, что мы говорим с вами на различных языках о разных вещах, думаю стоит остановиться. В любом случае такие беседы иногда полезны, но надо знать меру и когда остановиться.
Давайте я вам быстренько объясню, что делать.
Спасибо конечно.
декомпонуете вашу задачу на доменные сущности
По хорошему об этом речь и идет.
определение по МакКоннелу. Оно не противоречит тому, что я сказал.
По хорошему нично ничему не противоречит, поэтому и привел в пример ошибку №11 «Строгое следование правилам». Джун пишет все в контроллерах, мидл пишет все на интерфейсах, сеньер знает где можно написать код в контроллере, а где и как использовать интерфейсы (не мои слова).
Это совсем совсем о другом.
Почему? Это соответствует вашему описанию "собирать их в одном месте".
Такое ощущение, что мы говорим с вами на различных языках о разных вещах
Неудивительно: вы говорите общими словами, не давая никакой конкретики.
По хорошему об этом речь и идет.
Нет, не идет. У вас речь идет об АТД и "Типах Данных", а не о доменных сущностях.
Терминология важна, понимаете?
По хорошему нично ничему не противоречит
Да нет, по-хорошему, у вас есть набор правил и определений, и вы можете сказать, выполняются правила, или нет, и попадает объект под определение, или нет. А если "ничто ничему не противоречит", невозможно определить, работает ли система.
Джун пишет все в контроллерах, мидл пишет все на интерфейсах, сеньер знает где можно написать код в контроллере, а где и как использовать интерфейсы (не мои слова).
… мне, конечно, в этот момент очень любопытно, кем вы себя считаете из этого списка.
Терминология важна, понимаете?
Понимаю, первый опыт хабра, решил поделиться, пришел к тому, что статьи должны выглядеть по другому, конкретики больше, ьелее четкая терминология и т.п.
… мне, конечно, в этот момент очень любопытно, кем вы себя считаете из этого списка.
Богом всевышним, кем я могу себя еще считать то!
“Топ-11 самых частых ошибок в JavaScript” — ошибка №11: Ты следуешь всем правилам,
Давайте расмотрим еще один пример, у вас есть структура с данными из пяти значений и вам в некоторых местах кода требуется получить хэш по трем полям, где то по двум полям, где то сумма четырех значений, где то разность двух полей. Для данных в БД, для структуры, вам неизбежно придется писать все четыре функции и брать на себя риски, что во всем коде будут использоваться именно эти функции, чем меньше/проще приложение, тем проще это отслеживать. А если вы используете класс с этими пятью полями, то кто вам мешает написать эти четыре функции в нем и быть уверенным, что везде где используются эти данные будут вызваны именно эти функции и всегда когда они изменятся изменения будут работать во всем коде, какой бы сложный и большой он не был.
Будьте гибче!
А если вы используете класс с этими пятью полями, то кто вам мешает написать эти четыре функции в нем и быть уверенным, что везде где используются эти данные будут вызваны именно эти функции
Ну вообще-то, если эти данные доступны потребителю, то у меня нет никакого способа удостовериться, что вызываются именно мои функции, а не функции потребителя. А если данные потребителю недоступны, то нет способа удостовериться, что вызывается нужная функция, а не соседняя.
У паттерна "Легковес" (хотя обычно его переводят как "Приспособленец") своя терминология, связанная с тем, что несколько классов виртуально "представляют" один.
Там берется состояние некоторого объекта, и сначала разделяется на внутренне и внешнее, а уже потом внутреннее выносится в неизменяемый объект-легковес. При этом, говоря формально, у самого легковеса никакого состояния нет (его данные неизменяемы), но сам легковес при этом выступает как (внутреннее) состояние другого объекта, отсюда и путаница.
Абстрактный тип данных. Часть 1: Данные (Тип Данных)