но DTO НЕ! антипаттерн.

EAV нарушает реляционную теорию из-за обхода типизации ячейки и невозможности достижения консистентности через тот же NOT NULL. Это костыль, хак, аномалия. Также Data Transfer Object нарушает каноническое определение Object в теории ООП как чего-то, имеющего инкапсулированное состояние и поведение. Здесь слово "антипаттерн" воспринимайте в хорошем смысле как аномалию, противоречащую теории.

+1 Спасибо. Некоторые штуки прояснились. Осталось почитать и понять anemic model && value object

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

@funivan только учти, что те же деньги могут быть и сущностью, зависит от ситуации

EAV нарушает реляционную теорию из-за обхода типизации ячейки и невозможности достижения консистентности через тот же NOT NULL. Это костыль, хак, аномалия. Также Data Transfer Object нарушает каноническое определение Object в теории ООП как чего-то, имеющего инкапсулированное состояние и поведение. Здесь слово "антипаттерн" воспринимайте в хорошем смысле как аномалию, противоречащую теории.

да, с EAV согласен что это антипаттерн. Причем именно в плохом смысле. Что до "канонического определения" - для меня твое определение (что объект это инстанс класса) не канон (это определение любителей C++ и симулы), ну или просто незначительно поскольку оно мало чего дает. А вот определение объекта Алана Кея чуть выше. Если что термин "объект" был ДО ООП, и всем было хорошо.

@funivan только учти, что те же деньги могут быть и сущностью, зависит от ситуации

я привел кейс когда деньги сущность

я привел кейс когда деньги сущность

сори, чукча писатель =(

сори, чукча писатель =(

сам такой)

да, с EAV согласен что это антипаттерн. Причем именно в плохом смысле. Что до "канонического определения" - для меня твое определение (что объект это инстанс класса) не канон (это определение любителей C++ и симулы), ну или просто незначительно поскольку оно мало чего дает. А вот определение объекта Алана Кея чуть выше. Если что термин "объект" был ДО ООП, и всем было хорошо.

Что "объект – это инстанс класса" – это не моё определение. Мне классы тоже не интересны. Я ООП всегда воспринимаю как Объектно-ориентированное П, а не как Классово-ориентированное КОП. Объекты я могу и без классов делать.

Что "объект – это инстанс класса" – это не моё определение. Мне классы тоже не интересны. Я ООП всегда воспринимаю как Объектно-ориентированное П, а не как Классово-ориентированное КОП. Объекты я могу и без классов делать.

это не определение Алана Кея)

для меня ООП это больше про децентрализованные системы. Пример - Erlang, где у тебя есть среда предоставляемая языком и етсь твои "объекты" (микротреды). Аналогичная штука - Akka для java

это не определение Алана Кея)

Да, а определение каких-то технических неадекватов. На него мне пофиг.

микросервисы - тоже могут восприниматься как объекты, если сделаны правильно

Да, а определение каких-то технических неадекватов. На него мне пофиг.

поясни мысль)

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

то есть подобные определения банально не несут никакой практической ценности

и да. если что весь этот чат создавался что бы толпой разобраться "что же блядь такое это ООП"

для меня ООП это больше про децентрализованные системы. Пример - Erlang, где у тебя есть среда предоставляемая языком и етсь твои "объекты" (микротреды). Аналогичная штука - Akka для java

Для меня ООП – это модульность с разделением по ответственностям. Со слабосвязанным общением друг с другом. А там хоть классы, хоть процедуры, хоть ассемблер, хоть умные унитазы.

и да. если что весь этот чат создавался что бы толпой разобраться "что же блядь такое это ООП"

чет этому чату уже больше года и чет не получилось)

надо на работе задатьвопрос "Что такое ООП?" И посмотреть что ответят ?

надо на работе задатьвопрос "Что такое ООП?" И посмотреть что ответят ?

можешь начать с "наследование или композиция" и требовать объяснить, почему

Для меня ООП – это модульность с разделением по ответственностям. Со слабосвязанным общением друг с другом. А там хоть классы, хоть процедуры, хоть ассемблер, хоть умные унитазы.

то есть в твоем виденьи нет никакой разницы между ООП и не ООП на уровне рантайма и вся разница выражается только в коде. Ни тебе повсеместного late binding, ни тебе децентрализации (потому что всегда есть main рутина)

можешь начать с "наследование или композиция" и требовать объяснить, почему

судя по собеседованию мне врядли что-то вразумительное ответят. Хотя кто знает

это как rest - "у меня rest потому что я соблюдаю 2 принципа реста из 7-ми - тот который про клиент-серверную архитектуру и стэйтлес"

так же и ооп - "у меня ооп потому что штуки которыми я оперирую называются объекты"

Для меня ООП – это модульность с разделением по ответственностям. Со слабосвязанным общением друг с другом. А там хоть классы, хоть процедуры, хоть ассемблер, хоть умные унитазы.

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

Можно ли считать такую систему "ООП" или нет? если нет - почему?

упрощая вопрос - "можно ли говорить о ООП когда в системе один объект"

можешь начать с "наследование или композиция" и требовать объяснить, почему

агрегация)

агрегация)

вопрос от @mkusher - почему в ООП комьюнити перепутали термины композиция и агрегация? В том плане что то что подразумевается под композицией в ООП это на самом деле агрегация с точки зрения термина, а агрегация - композиция)

ты сломал мне моск

const foo = () => {} const bar = (fn) => () => fn(); // aggregation const baz = () => foo() // composition const fooBar = bar(foo)

можно придумать свои термины!

вопрос от @mkusher - почему в ООП комьюнити перепутали термины композиция и агрегация? В том плане что то что подразумевается под композицией в ООП это на самом деле агрегация с точки зрения термина, а агрегация - композиция)

так я не понял какая точка зрения ооп а кака правильная? я так всегда называл: композиция - объекты из которых состоит данных не могут сущетсвовать без родителя агрегация - могут

вопрос от @mkusher - почему в ООП комьюнити перепутали термины композиция и агрегация? В том плане что то что подразумевается под композицией в ООП это на самом деле агрегация с точки зрения термина, а агрегация - композиция)

ну да. яснопонятно же. Крэг Ларман это норм обьясняет.

const foo = () => {} const bar = (fn) => () => fn(); // aggregation const baz = () => foo() // composition const fooBar = bar(foo)

f(g(h(e)))

вопрос от @mkusher - почему в ООП комьюнити перепутали термины композиция и агрегация? В том плане что то что подразумевается под композицией в ООП это на самом деле агрегация с точки зрения термина, а агрегация - композиция)

@Adelf32 hah

+

@Adelf32 hah

То есть ты прав? (читал вчера ваши дебаты)

То есть ты прав? (читал вчера ваши дебаты)

правота Шредингера

так я не понял какая точка зрения ооп а кака правильная? я так всегда называл: композиция - объекты из которых состоит данных не могут сущетсвовать без родителя агрегация - могут

ну просто композиция функций - вроде понятно что. И поскольку чаще ты работаешь с композицией объектов без состояния (только зависимости) - то в целом все должно быть одинаково

но почему-то это называется агрегацией

При этом корнем агрегата называется штука, которая сама полностью контролит все внутри

это чтобы жизнь мёдом не казалась :D

?

а шо, чем больше различных терминов, тем больше можно заработать на их разъяснении

а шо, чем больше различных терминов, тем больше можно заработать на их разъяснении

на чем и зарабатывают консультанты

на чем и зарабатывают консультанты

придумал свою концепцию охулиард лет назад @ до сих пор ездишь и объясняешь челам что к чему

идеально же

вспомним Марко, лол

подобное практикуют всякие аджайл тренеры и скрам мастера - пишут статьи что мол "вы делаете не правильно, заплатите и я вас научу"

главное напугать людей что они делают что-то не так, и тогда они сами прибегут молить о том что бы ты рассказал как надо)

подобное практикуют всякие аджайл тренеры и скрам мастера - пишут статьи что мол "вы делаете не правильно, заплатите и я вас научу"

"Давай по новой Миша, всё хуйня("

вот по поводу композиции и наследования, почитал статью https://www.sicpers.info/2018/03/why-inheritance-never-made-any-sense/ Там автор пишет в конце: If I am using subtypes to tighten up interface contracts, I should be not only allowed to mark a class anywhere in the tree as a subtype of another class anywhere in the tree, but required to do so: once again, it should not be assumed that my subclasses are also subtypes. То есть с одной стороны он говорит, что если наследование используется для типов, то вся иерархия должна использоваться для типов, но тут же добавляет, что не думайте, что сабклассы - это подтипы. То ли я просто запутался, то ли мая непонимать английский =\

хех я помнится начинал переводить эту статью

я так понял что основная мысль что наследование это не удачный термин

это же расширение причем тут наследственность

Ну, есть исключения. У IDE от jB нет конкурентов, но они не стагнируют.

Когда там нормальный UI без джавы завезут? Уже пол десятилетия костыль волочится

это же расширение причем тут наследственность

попробуй найти каких публикаций где эту идею впервые начали обсасывать и обсуждения какие на эту тему

Когда там нормальный UI без джавы завезут? Уже пол десятилетия костыль волочится

Вкусовщина.

Когда там нормальный UI без джавы завезут? Уже пол десятилетия костыль волочится

Qt ж был уже

Вкусовщина.

Нет, наоборот это максимально конкретная претензия

ERROR: S client not available

Нет, наоборот это максимально конкретная претензия

Чем плох этот ui?

У них объективно неудобный (ака не нативный) интерфейс, исправлять который они не. считают нужным

Чем плох этот ui?

"этот" это какой?

У них объективно неудобный (ака не нативный) интерфейс, исправлять который они не. считают нужным

неудобный => вкусовщина.

Ты можешь считать его каким угодно, но он остаётся не нативным нигде

Для меня это идеальный интерфейс.

Я тебе сказал, почему так считается

Когда там нормальный UI без джавы завезут? Уже пол десятилетия костыль волочится

а понял

Мнения не при чём

Удобство и нативность - это ортогональные вещи.

UI который не умеет в нативные контролы хотя бы на самом минимальном уровне — костыль

Удобство и нативность - это ортогональные вещи.

пойду наброшу UX дизайнерам

*Костыль подразумевает что существует нормальное решение

*Костыль подразумевает что существует нормальное решение

А можно пример нормального решения?

*Костыль подразумевает что существует нормальное решение

а если нормальное решение приводит к тому что тебе надо в три раза больше работы?

в три раза больше доков

UI который не умеет в нативные контролы хотя бы на самом минимальном уровне — костыль

Где-то ручкой нам машет веб

в три раза больше "конфуза" что в статье используется контрол которого нет у пользователя потому что сраный макаеб опять учит виндусятников?

в три раза больше "конфуза" что в статье используется контрол которого нет у пользователя потому что сраный макаеб опять учит виндусятников?

И наоборот.

Всем tui

Где-то ручкой нам машет веб

Передаёт привет и спрашивает когда люди перестанут волочить костыли с ненативным ui

а если нормальное решение приводит к тому что тебе надо в три раза больше работы?

no money — no honey

Так какая кроссплатформенная IDE имеет нативный интерфейс?

Хороший вопрос для саморазвития

Ясно. Вопросов больше нет.

Так какая кроссплатформенная IDE имеет нативный интерфейс?

vim

я так понял что основная мысль что наследование это не удачный термин

Это не объясняет противоречия в предложении. С одной стороны вся иерархия - субтипы, и тут же - не думайте, что сабклассы - это субтипы =\

Ясно. Вопросов больше нет.

Я не буду отвечать на провокативный вопрос с изначально негативной коннотацией

Ищи сам

Ищи сам

Смысл? Если появится какой-нибудь достойный продукт, то я о нём из сообщества узнаю.

Лол