Здравствуйте, Aikin, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>ИМХО, в любом случае, используем ли мапер или все делаем ручками, контроль соответствия базы приложению можно осуществить только тестами. G>>Ну что за бред. G>>Проконтролироать это можно только на одной машине, никто вам не сможет гарантировать что у пользователя будет база соотвествовть приложению. A>Я где-то утверждаю обратное?
Фраза "контроль соответствия базы приложению можно осуществить только тестами" утверждает обратное.
Здравствуйте, Aikin, Вы писали:
A>О каком контроле типов может идти речь, когда sql нетипизирован (мы ведь говорим про персистентность).
1. Допустим про персистентность — SQL конечно не типизирован, но есть две большие разницы, generic-маппинг через рефлекшен один раз написать, или каждый класс расписывать через рефлекшен — ты предлагаешь второе. И тут отмазка про то что SQL и так не типизирован, не пройдет, тут тебе рефлекшен боком встанет.
2. Персистентность может быть не только в БД, а в тот же XML, тоже заново все писать будешь, через рефлекшен?
3. А если объект куда передать надо, по веб-сервису например?
4. У тебя же объект создается не только для того, чтобы быть сохраненным в базе, наверное он еще для чего-то нужен? Это что-то ты тоже собираешься через рефлекшен делать?
A>ИМХО, в любом случае, используем ли мапер или все делаем ручками, контроль соответствия базы приложению можно осуществить только тестами.
Речь не о том, что используем маппер или нет, а о том, что в реальных приложениях если у тебя объект куда либо сериализуется (не важно, в базу ли, в XML, на диск...) то все его данные которые нужно персистить находятся в публичном доступе.
Понятно, что при желании можно их спрятать и придумать тридцать-три способа их извлечения в зависимости от ситуации, но практического смысла в этом нет.
Здравствуйте, dimgel, Вы писали:
D>Если у кого-нибудь есть пример use-case, опровергающий мои построения, или другие соображения — буду признателен.
Ты прежде чем в юз-кейсы влезать и примеры требовать, сначала сам определись что хочешь понять/доказать и о чем вообще речь-то идет.. )
Можно начать с определения ООП, а то из твоих тезисов оно не прослеживается.
Здравствуйте, gandjustas, Вы писали:
G>Фраза "контроль соответствия базы приложению можно осуществить только тестами" утверждает обратное.
Не вижу смысла в продолжении дискуссии. Твое уточнение никакой пользы не дает.
Здравствуйте, IB, Вы писали:
IB>generic-маппинг через рефлекшен один раз написать, или каждый класс расписывать через рефлекшен — ты предлагаешь второе.
Я говорю про генерик-маппинг + метаданные. Второе тоже возможно, но мне это в голову даже не приходило.
IB>2. Персистентность может быть не только в БД, а в тот же XML, тоже заново все писать будешь, через рефлекшен? IB>3. А если объект куда передать надо, по веб-сервису например? IB>4. У тебя же объект создается не только для того, чтобы быть сохраненным в базе, наверное он еще для чего-то нужен? Это что-то ты тоже собираешься через рефлекшен делать?
Не нужно раздувать вполне конкретное применение способа (для воссоздания объекта из базы) на общий случай.
IB>Речь не о том, что используем маппер или нет, а о том, что в реальных приложениях если у тебя объект куда либо сериализуется (не важно, в базу ли, в XML, на диск...) то все его данные которые нужно персистить находятся в публичном доступе.
Вот с этим я и спорю. IB>Понятно, что при желании можно их спрятать и придумать тридцать-три способа их извлечения в зависимости от ситуации, но практического смысла в этом нет.
А мне нравится
Здравствуйте, dimgel, Вы писали:
D>Тезис собственно такой: единственная существенная польза от ООП, благодаря которой его все используют, — это полиморфизм.
Полиморфизм в функциональных языках так же отлично реализуется.
ИМХО, единственная польза от ООП в том, что людям тупо удобнее думать в категориях объектов и их взаимодействия. Все, точка. Остальное не более чем плюшки.
Здравствуйте, Aikin, Вы писали:
A>Здравствуйте, dimgel, Вы писали:
D>>Тезис собственно такой: единственная существенная польза от ООП, благодаря которой его все используют, — это полиморфизм. A>Полиморфизм в функциональных языках так же отлично реализуется.
Можно конкретный пример, посложнее моего с посетителем? То, что реализуется, я подозреваю, но не знаю как это выглядит на практике. В голове усиленно крутится только реализация на прологе, который вообще из третьей оперы, и мне оно представляется несколько более громоздким.
Здравствуйте, dimgel, Вы писали:
D>Можно конкретный пример, посложнее моего с посетителем? То, что реализуется, я подозреваю, но не знаю как это выглядит на практике. В голове усиленно крутится только реализация на прологе, который вообще из третьей оперы, и мне оно представляется несколько более громоздким.
А смысл?
Ну, допустим, покажешь ты всем, что Посетитель, Стратегия и проч. в функциональных языках -- громоздкие и неудобные конструкции. Ну и что? Что с того, что чисто ООП конструкции имеют неудобный аналог в языках, в которых эти конструкции нафик не нужны, так как имеется куча собственных наработок.
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, samius, Вы писали:
S>>Это стратегия, а не посетитель.
D>Это зависит от семантики вызова. Если задача состоит в том, чтобы обойти дерево и в каждом узле выполнить какую-то операцию, то посетитель.
Посетитель — это когда надо выполнить специфическую для типа узла операцию.
Здравствуйте, Aikin, Вы писали:
A>Я говорю про генерик-маппинг + метаданные.
Ok. то есть ты предлагаешь под каждый случай использования данных, вместо публичного доступа использовать генерик-маппинг + метаданные? Какой в этом практический смысл? "Какую задачу ты этим решаешь?" (с)
A>Не нужно раздувать вполне конкретное применение способа (для воссоздания объекта из базы) на общий случай.
Если у тебя объект ни для чего другого кроме как для "воссоздания" из базы не используестя, то действительно не нужно, но в реальной жизни так не бывает.
A>Вот с этим я и спорю.
Напрасно.
A>А мне нравится
Твои проблемы.
Здравствуйте, IB, Вы писали:
A>>Я говорю про генерик-маппинг + метаданные. IB>Ok. то есть ты предлагаешь под каждый случай использования данных, вместо публичного доступа использовать генерик-маппинг + метаданные?
Нет, я предлагаю под каждый способ использования подобрать способ/инструмент больше всего подходящий для него.
A>>Не нужно раздувать вполне конкретное применение способа (для воссоздания объекта из базы) на общий случай. IB>Если у тебя объект ни для чего другого кроме как для "воссоздания" из базы не используестя, то действительно не нужно, но в реальной жизни так не бывает.
Воссоздали, изменили через его публичный контракт, отобразили пользователю, сохранили.
Что не так?
A>>Вот с этим я и спорю. IB>Напрасно. A>>А мне нравится IB>Твои проблемы.
Ага, ктоб сомневался
Здравствуйте, Aikin, Вы писали:
A>Полиморфизм в функциональных языках так же отлично реализуется.
Полиморфизм реализуется даже в С.. =)
A>ИМХО, единственная польза от ООП в том, что людям тупо удобнее думать в категориях объектов и их взаимодействия. Все, точка. Остальное не более чем плюшки.
Думать всем удобнее по разному. Просто в ООП языках такие вещи как полиморфизм, инкапсуляция и всевозможное наследование введены на уровене языка, как следствие, в таких языках этими вещами удобнее пользоваться и выражать логику приложения именно в этих терминах.
В функциональных языках, где на нативно поддерживаются другие вещи, та же логика совершенно естественным образом выражается по другому, в процедурных — по третьему.
И совсем не фокус взять один язык и писать на нем в стиле другого.
Вопрос лиш в том, какая (прости-господи) парадигма лучше подходит под конкретную задачу.
Здравствуйте, Aikin, Вы писали:
A>Нет, я предлагаю под каждый способ использования подобрать способ/инструмент больше всего подходящий для него.
Дело в том, что в качестве способа публичный доступ больше всего подходит для всех способов/инструментов, даже для тех, о которых ты еще не подумал. Причем он универсальный, не надо отдельно приседать в каждом конкретном случае.
A>Воссоздали, изменили через его публичный контракт, отобразили пользователю, сохранили. A>Что не так?
Да все так, просто публичный контракт — это тривиальный геттер/сеттер. И ничто не мешает реализовать тот же персистанс ровно через этот же публичный контракт.
A>Ага, ктоб сомневался
Ну просто ощущение что "баба яга против".
Здравствуйте, IB, Вы писали:
A>>ИМХО, единственная польза от ООП в том, что людям тупо удобнее думать в категориях объектов и их взаимодействия. Все, точка. Остальное не более чем плюшки. IB>Думать всем удобнее по разному.
Полностью согласен. Но все мы живем в объектом мире с самого рождения. Наш мозг с самого детства развивался в этом ключе.
IB>Просто в ООП языках такие вещи как полиморфизм, инкапсуляция и всевозможное наследование введены на уровене языка, как следствие, в таких языках этими вещами удобнее пользоваться и выражать логику приложения именно в этих терминах.
Еще раз: это не более чем плюшки ООП.
IB>В функциональных языках, где на нативно поддерживаются другие вещи, та же логика совершенно естественным образом выражается по другому, в процедурных — по третьему. IB>И совсем не фокус взять один язык и писать на нем в стиле другого.
+1 IB>Вопрос лиш в том, какая (прости-господи) парадигма лучше подходит под конкретную задачу.
+10000!
Здравствуйте, IB, Вы писали:
A>>Нет, я предлагаю под каждый способ использования подобрать способ/инструмент больше всего подходящий для него. IB>Дело в том, что в качестве способа публичный доступ больше всего подходит для всех способов/инструментов, даже для тех, о которых ты еще не подумал. Причем он универсальный, не надо отдельно приседать в каждом конкретном случае.
В этом случае проще. Но объект дизайнился не для того, чтобы его было просто/удобно перистить, а для того чтобы представлять часть бизнесс логики приложения. То что его нужно сохранять/воссоздавать -- задача сервисного слоя.
A>>Воссоздали, изменили через его публичный контракт, отобразили пользователю, сохранили. A>>Что не так? IB>Да все так, просто публичный контракт — это тривиальный геттер/сеттер. И ничто не мешает реализовать тот же персистанс ровно через этот же публичный контракт.
Нет, публичный контракт это публичный контракт.
Например метод DoEverythingYouCan(), гетер без сеттера.
Здравствуйте, Aikin, Вы писали:
A>В этом случае проще. Но объект дизайнился не для того, чтобы его было просто/удобно перистить, а для того чтобы представлять часть бизнесс логики приложения.
Иными словами, мы приходим к двум объектам, один для сериализации, а другой для реализации бизнес-логики приложения — ЧТД..
A>То что его нужно сохранять/воссоздавать -- задача сервисного слоя.
Сохранять/загружать нужно не его, а данные, которые он содержит.
A>Нет, публичный контракт это публичный контракт. A>Например метод DoEverythingYouCan(), гетер без сеттера.
Каким методом ты будешь сериализовать свой объект в XML?
Каким методом ты будешь считать скользящее среднее по коллекции объектов?
Каким методом ты будешь выполнять форматирование ФИО для разных сценариев?
...
Для ответа на все эти вопросы у тебя есть ровно два варианта
1. Во внешних методах нарошно заточеных для такого функционала, а значит у тебя есть публичный доступ к этим данным.
2. С помощю методов реализованных прямо в этом объекте.
Нужно пояснять, почему второй ответ не правильный?
Здравствуйте, Aikin, Вы писали:
A>Но все мы живем в объектом мире с самого рождения. Наш мозг с самого детства развивался в этом ключе.
Да вот не факт. Чтобы дорасти до ООП и моделирования в рамках этой концепции мозг приходится вывихнуть довольно основательно. Некоторые вон, до сих пор еще не осилили..
Самый простой подход даже не процедурный, а тупо линейный, другое дело что со сложностью в этом случае вообще не справиться.
A>Еще раз: это не более чем плюшки ООП.
Что ты понимаешь под "плюшками ООП", а что под не плюшками?
Мы уже победили, просто это еще не так заметно...
