| 1 2 3 4 5 6 7 8 9 10 11 12 |
| Re[15]: Связность BL и DAL слоёв | |
 | От: | gandjustas | |
| Дата: | 18.05.09 07:07 |
| Здравствуйте, Aikin, Вы писали: A>Здравствуйте, gandjustas, Вы писали: A>>>ИМХО, в любом случае, используем ли мапер или все делаем ручками, контроль соответствия базы приложению можно осуществить только тестами. G>>Ну что за бред. G>>Проконтролироать это можно только на одной машине, никто вам не сможет гарантировать что у пользователя будет база соотвествовть приложению. A>Я где-то утверждаю обратное? Фраза "контроль соответствия базы приложению можно осуществить только тестами" утверждает обратное.  |
| Re[13]: Связность BL и DAL слоёв | |
 | От: | IB rsdn | |
| Дата: | 18.05.09 07:11 |
| Здравствуйте, Aikin, Вы писали: A>О каком контроле типов может идти речь, когда sql нетипизирован (мы ведь говорим про персистентность). 1. Допустим про персистентность — SQL конечно не типизирован, но есть две большие разницы, generic-маппинг через рефлекшен один раз написать, или каждый класс расписывать через рефлекшен — ты предлагаешь второе. И тут отмазка про то что SQL и так не типизирован, не пройдет, тут тебе рефлекшен боком встанет. 2. Персистентность может быть не только в БД, а в тот же XML, тоже заново все писать будешь, через рефлекшен? 3. А если объект куда передать надо, по веб-сервису например? 4. У тебя же объект создается не только для того, чтобы быть сохраненным в базе, наверное он еще для чего-то нужен? Это что-то ты тоже собираешься через рефлекшен делать? A>ИМХО, в любом случае, используем ли мапер или все делаем ручками, контроль соответствия базы приложению можно осуществить только тестами. Речь не о том, что используем маппер или нет, а о том, что в реальных приложениях если у тебя объект куда либо сериализуется (не важно, в базу ли, в XML, на диск...) то все его данные которые нужно персистить находятся в публичном доступе. Понятно, что при желании можно их спрятать и придумать тридцать-три способа их извлечения в зависимости от ситуации, но практического смысла в этом нет.  Мы уже победили, просто это еще не так заметно... |
| Re[18]: Уточняю насчёт GoF и ООП. | |
| От: | IB rsdn | |
| Дата: | 18.05.09 07:18 | ||
| Оценка: | -1 | ||
| Здравствуйте, dimgel, Вы писали: D>Если у кого-нибудь есть пример use-case, опровергающий мои построения, или другие соображения — буду признателен. Ты прежде чем в юз-кейсы влезать и примеры требовать, сначала сам определись что хочешь понять/доказать и о чем вообще речь-то идет.. ) Можно начать с определения ООП, а то из твоих тезисов оно не прослеживается. Мы уже победили, просто это еще не так заметно... |
| Re[16]: Связность BL и DAL слоёв | |
 | От: | Aikin | |
| Дата: | 18.05.09 07:27 | ||
| Оценка: | +1 | ||
| Здравствуйте, gandjustas, Вы писали: G>Фраза "контроль соответствия базы приложению можно осуществить только тестами" утверждает обратное. Не вижу смысла в продолжении дискуссии. Твое уточнение никакой пользы не дает. СУВ, Aikin |
| Re[14]: Связность BL и DAL слоёв | |
| От: | Aikin | |
| Дата: | 18.05.09 07:27 |
| Здравствуйте, IB, Вы писали: IB>generic-маппинг через рефлекшен один раз написать, или каждый класс расписывать через рефлекшен — ты предлагаешь второе. Я говорю про генерик-маппинг + метаданные. Второе тоже возможно, но мне это в голову даже не приходило. IB>2. Персистентность может быть не только в БД, а в тот же XML, тоже заново все писать будешь, через рефлекшен? IB>3. А если объект куда передать надо, по веб-сервису например? IB>4. У тебя же объект создается не только для того, чтобы быть сохраненным в базе, наверное он еще для чего-то нужен? Это что-то ты тоже собираешься через рефлекшен делать? Не нужно раздувать вполне конкретное применение способа (для воссоздания объекта из базы) на общий случай. IB>Речь не о том, что используем маппер или нет, а о том, что в реальных приложениях если у тебя объект куда либо сериализуется (не важно, в базу ли, в XML, на диск...) то все его данные которые нужно персистить находятся в публичном доступе. Вот с этим я и спорю. IB>Понятно, что при желании можно их спрятать и придумать тридцать-три способа их извлечения в зависимости от ситуации, но практического смысла в этом нет. А мне нравится  СУВ, Aikin |
| Re[18]: Уточняю насчёт GoF и ООП. | |
| От: | Aikin | |
| Дата: | 18.05.09 07:50 | ||
| Оценка: | +1 | ||
| Здравствуйте, dimgel, Вы писали: D>Тезис собственно такой: единственная существенная польза от ООП, благодаря которой его все используют, — это полиморфизм. Полиморфизм в функциональных языках так же отлично реализуется. ИМХО, единственная польза от ООП в том, что людям тупо удобнее думать в категориях объектов и их взаимодействия. Все, точка. Остальное не более чем плюшки. СУВ, Aikin |
| Re[19]: Уточняю насчёт GoF и ООП. | |
 | От: | dimgel | |
| Дата: | 18.05.09 08:06 |
| Здравствуйте, Aikin, Вы писали: A>Здравствуйте, dimgel, Вы писали: D>>Тезис собственно такой: единственная существенная польза от ООП, благодаря которой его все используют, — это полиморфизм. A>Полиморфизм в функциональных языках так же отлично реализуется. Можно конкретный пример, посложнее моего с посетителем? То, что реализуется, я подозреваю, но не знаю как это выглядит на практике. В голове усиленно крутится только реализация на прологе, который вообще из третьей оперы, и мне оно представляется несколько более громоздким. ... << RSDN@Home 1.1.4 stable SR1 rev. 568>> Человек становится мужественным, когда ему нечего терять. Мы малодушны только тогда, когда есть еще что-то, за что мы можем цепляться. |
| Re[18]: Уточняю насчёт GoF и ООП. | |
 | От: | samius | |
| Дата: | 18.05.09 08:31 |
| Здравствуйте, dimgel, Вы писали: D>1. Посетитель. В функциональном языке это просто суперпозиция функций: D>
Это стратегия, а не посетитель. |
| Re[20]: Уточняю насчёт GoF и ООП. | |
| От: | Aikin | |
| Дата: | 18.05.09 08:38 |
| Здравствуйте, dimgel, Вы писали: D>Можно конкретный пример, посложнее моего с посетителем? То, что реализуется, я подозреваю, но не знаю как это выглядит на практике. В голове усиленно крутится только реализация на прологе, который вообще из третьей оперы, и мне оно представляется несколько более громоздким. А смысл? Ну, допустим, покажешь ты всем, что Посетитель, Стратегия и проч. в функциональных языках -- громоздкие и неудобные конструкции. Ну и что? Что с того, что чисто ООП конструкции имеют неудобный аналог в языках, в которых эти конструкции нафик не нужны, так как имеется куча собственных наработок. СУВ, Aikin |
| Re[19]: Уточняю насчёт GoF и ООП. | |
| От: | dimgel | |
| Дата: | 18.05.09 08:39 |
| Здравствуйте, samius, Вы писали: D>>
S>Это стратегия, а не посетитель. Это зависит от семантики вызова. Если задача состоит в том, чтобы обойти дерево и в каждом узле выполнить какую-то операцию, то посетитель. ... << RSDN@Home 1.1.4 stable SR1 rev. 568>> Человек становится мужественным, когда ему нечего терять. Мы малодушны только тогда, когда есть еще что-то, за что мы можем цепляться. |
| Re[20]: Уточняю насчёт GoF и ООП. | |
| От: | samius | |
| Дата: | 18.05.09 08:43 | ||
| Оценка: | 2 (1) | ||
| Здравствуйте, dimgel, Вы писали: D>Здравствуйте, samius, Вы писали: S>>Это стратегия, а не посетитель. D>Это зависит от семантики вызова. Если задача состоит в том, чтобы обойти дерево и в каждом узле выполнить какую-то операцию, то посетитель. Посетитель — это когда надо выполнить специфическую для типа узла операцию. |
| Re[15]: Связность BL и DAL слоёв | |
| От: | IB rsdn | |
| Дата: | 18.05.09 08:52 |
| Здравствуйте, Aikin, Вы писали: A>Я говорю про генерик-маппинг + метаданные. Ok. то есть ты предлагаешь под каждый случай использования данных, вместо публичного доступа использовать генерик-маппинг + метаданные? Какой в этом практический смысл? "Какую задачу ты этим решаешь?" (с) A>Не нужно раздувать вполне конкретное применение способа (для воссоздания объекта из базы) на общий случай. Если у тебя объект ни для чего другого кроме как для "воссоздания" из базы не используестя, то действительно не нужно, но в реальной жизни так не бывает. A>Вот с этим я и спорю. Напрасно. A>А мне нравится Твои проблемы. Мы уже победили, просто это еще не так заметно... |
| Re[16]: Связность BL и DAL слоёв | |
| От: | Aikin | |
| Дата: | 18.05.09 09:00 |
| Здравствуйте, IB, Вы писали: A>>Я говорю про генерик-маппинг + метаданные. IB>Ok. то есть ты предлагаешь под каждый случай использования данных, вместо публичного доступа использовать генерик-маппинг + метаданные? Нет, я предлагаю под каждый способ использования подобрать способ/инструмент больше всего подходящий для него. A>>Не нужно раздувать вполне конкретное применение способа (для воссоздания объекта из базы) на общий случай. IB>Если у тебя объект ни для чего другого кроме как для "воссоздания" из базы не используестя, то действительно не нужно, но в реальной жизни так не бывает. Воссоздали, изменили через его публичный контракт, отобразили пользователю, сохранили. Что не так? A>>Вот с этим я и спорю. IB>Напрасно. A>>А мне нравится IB>Твои проблемы. Ага, ктоб сомневался  СУВ, Aikin |
| Re[21]: Уточняю насчёт GoF и ООП. | |
| От: | dimgel | |
| Дата: | 18.05.09 09:00 |
| Здравствуйте, samius, Вы писали: S>Посетитель — это когда надо выполнить специфическую для типа узла операцию. Да, точно, попутал. ... << RSDN@Home 1.1.4 stable SR1 rev. 568>> Человек становится мужественным, когда ему нечего терять. Мы малодушны только тогда, когда есть еще что-то, за что мы можем цепляться. |
| Re[19]: Уточняю насчёт GoF и ООП. | |
| От: | IB rsdn | |
| Дата: | 18.05.09 09:08 |
| Здравствуйте, Aikin, Вы писали: A>Полиморфизм в функциональных языках так же отлично реализуется. Полиморфизм реализуется даже в С.. =) A>ИМХО, единственная польза от ООП в том, что людям тупо удобнее думать в категориях объектов и их взаимодействия. Все, точка. Остальное не более чем плюшки. Думать всем удобнее по разному. Просто в ООП языках такие вещи как полиморфизм, инкапсуляция и всевозможное наследование введены на уровене языка, как следствие, в таких языках этими вещами удобнее пользоваться и выражать логику приложения именно в этих терминах. В функциональных языках, где на нативно поддерживаются другие вещи, та же логика совершенно естественным образом выражается по другому, в процедурных — по третьему. И совсем не фокус взять один язык и писать на нем в стиле другого. Вопрос лиш в том, какая (прости-господи) парадигма лучше подходит под конкретную задачу. Мы уже победили, просто это еще не так заметно... |
| Re[17]: Связность BL и DAL слоёв | |
| От: | IB rsdn | |
| Дата: | 18.05.09 09:16 |
| Здравствуйте, Aikin, Вы писали: A>Нет, я предлагаю под каждый способ использования подобрать способ/инструмент больше всего подходящий для него. Дело в том, что в качестве способа публичный доступ больше всего подходит для всех способов/инструментов, даже для тех, о которых ты еще не подумал. Причем он универсальный, не надо отдельно приседать в каждом конкретном случае. A>Воссоздали, изменили через его публичный контракт, отобразили пользователю, сохранили. A>Что не так? Да все так, просто публичный контракт — это тривиальный геттер/сеттер. И ничто не мешает реализовать тот же персистанс ровно через этот же публичный контракт. A>Ага, ктоб сомневался Ну просто ощущение что "баба яга против". Мы уже победили, просто это еще не так заметно... |
| Re[20]: Уточняю насчёт GoF и ООП. | |
| От: | Aikin | |
| Дата: | 18.05.09 09:23 |
| Здравствуйте, IB, Вы писали: A>>ИМХО, единственная польза от ООП в том, что людям тупо удобнее думать в категориях объектов и их взаимодействия. Все, точка. Остальное не более чем плюшки. IB>Думать всем удобнее по разному. Полностью согласен. Но все мы живем в объектом мире с самого рождения. Наш мозг с самого детства развивался в этом ключе. IB>Просто в ООП языках такие вещи как полиморфизм, инкапсуляция и всевозможное наследование введены на уровене языка, как следствие, в таких языках этими вещами удобнее пользоваться и выражать логику приложения именно в этих терминах. Еще раз: это не более чем плюшки ООП. IB>В функциональных языках, где на нативно поддерживаются другие вещи, та же логика совершенно естественным образом выражается по другому, в процедурных — по третьему. IB>И совсем не фокус взять один язык и писать на нем в стиле другого. +1 IB>Вопрос лиш в том, какая (прости-господи) парадигма лучше подходит под конкретную задачу. +10000! СУВ, Aikin |
| Re[18]: Связность BL и DAL слоёв | |
| От: | Aikin | |
| Дата: | 18.05.09 09:30 |
| Здравствуйте, IB, Вы писали: A>>Нет, я предлагаю под каждый способ использования подобрать способ/инструмент больше всего подходящий для него. IB>Дело в том, что в качестве способа публичный доступ больше всего подходит для всех способов/инструментов, даже для тех, о которых ты еще не подумал. Причем он универсальный, не надо отдельно приседать в каждом конкретном случае. В этом случае проще. Но объект дизайнился не для того, чтобы его было просто/удобно перистить, а для того чтобы представлять часть бизнесс логики приложения. То что его нужно сохранять/воссоздавать -- задача сервисного слоя. A>>Воссоздали, изменили через его публичный контракт, отобразили пользователю, сохранили. A>>Что не так? IB>Да все так, просто публичный контракт — это тривиальный геттер/сеттер. И ничто не мешает реализовать тот же персистанс ровно через этот же публичный контракт. Нет, публичный контракт это публичный контракт. Например метод DoEverythingYouCan(), гетер без сеттера. СУВ, Aikin |
| Re[19]: Связность BL и DAL слоёв | |
| От: | IB rsdn | |
| Дата: | 18.05.09 11:18 |
| Здравствуйте, Aikin, Вы писали: A>В этом случае проще. Но объект дизайнился не для того, чтобы его было просто/удобно перистить, а для того чтобы представлять часть бизнесс логики приложения. Иными словами, мы приходим к двум объектам, один для сериализации, а другой для реализации бизнес-логики приложения — ЧТД..  A>То что его нужно сохранять/воссоздавать -- задача сервисного слоя. Сохранять/загружать нужно не его, а данные, которые он содержит. A>Нет, публичный контракт это публичный контракт. A>Например метод DoEverythingYouCan(), гетер без сеттера. Каким методом ты будешь сериализовать свой объект в XML? Каким методом ты будешь считать скользящее среднее по коллекции объектов? Каким методом ты будешь выполнять форматирование ФИО для разных сценариев? ... Для ответа на все эти вопросы у тебя есть ровно два варианта 1. Во внешних методах нарошно заточеных для такого функционала, а значит у тебя есть публичный доступ к этим данным. 2. С помощю методов реализованных прямо в этом объекте. Нужно пояснять, почему второй ответ не правильный? Мы уже победили, просто это еще не так заметно... |
| Re[21]: Уточняю насчёт GoF и ООП. | |
| От: | IB rsdn | |
| Дата: | 18.05.09 11:23 |
| Здравствуйте, Aikin, Вы писали: A>Но все мы живем в объектом мире с самого рождения. Наш мозг с самого детства развивался в этом ключе. Да вот не факт. Чтобы дорасти до ООП и моделирования в рамках этой концепции мозг приходится вывихнуть довольно основательно. Некоторые вон, до сих пор еще не осилили.. Самый простой подход даже не процедурный, а тупо линейный, другое дело что со сложностью в этом случае вообще не справиться. A>Еще раз: это не более чем плюшки ООП. Что ты понимаешь под "плюшками ООП", а что под не плюшками? Мы уже победили, просто это еще не так заметно... |
| 1 2 3 4 5 6 7 8 9 10 11 12 |