| 1 2 3 4 5 6 7 8 9 10 11 12 |
| Re[20]: Связность BL и DAL слоёв | |
 | От: | Aikin | |
| Дата: | 18.05.09 11:31 |
| Здравствуйте, IB, Вы писали: A>>В этом случае проще. Но объект дизайнился не для того, чтобы его было просто/удобно перистить, а для того чтобы представлять часть бизнесс логики приложения. IB>Иными словами, мы приходим к двум объектам, один для сериализации, а другой для реализации бизнес-логики приложения — ЧТД..  Нет. Мы приходим к одному объекту, который сохранить/восстановить можно только через доступ к приватным членам класса (через рефлексию, например). A>>То что его нужно сохранять/воссоздавать -- задача сервисного слоя. IB>Сохранять/загружать нужно не его, а данные, которые он содержит. Мы не на телеигре "Define it right". IB>Нужно пояснять, почему второй ответ не правильный? Не, не нужно, я сам смогу это сделать. IB>1. Во внешних методах нарошно заточеных для такого функционала, а значит у тебя есть публичный доступ к этим данным. Не нужно преувеличивать. ReadOnly доступ в 99% случаев будет, оставшийся 1% смысла рассматривать нет. СУВ, Aikin |
| Re[21]: Уточняю насчёт GoF и ООП. | |
 | От: | gandjustas | |
| Дата: | 18.05.09 11:31 |
| Здравствуйте, Aikin, Вы писали: A>Здравствуйте, IB, Вы писали: A>>>ИМХО, единственная польза от ООП в том, что людям тупо удобнее думать в категориях объектов и их взаимодействия. Все, точка. Остальное не более чем плюшки. IB>>Думать всем удобнее по разному. A>Полностью согласен. Но все мы живем в объектом мире с самого рождения. Наш мозг с самого детства развивался в этом ключе. А вот программы в таком мире не живут. Очень малая часть состоит из долгоживущих объектов, которые имеют какое-то поведение и состояние.  |
| Re[22]: Уточняю насчёт GoF и ООП. | |
| От: | Aikin | |
| Дата: | 18.05.09 11:37 |
| Здравствуйте, IB, Вы писали: A>>Но все мы живем в объектом мире с самого рождения. Наш мозг с самого детства развивался в этом ключе. IB>Да вот не факт. Чтобы дорасти до ООП и моделирования в рамках этой концепции мозг приходится вывихнуть довольно основательно. Некоторые вон, до сих пор еще не осилили.. IB>Самый простой подход даже не процедурный, а тупо линейный, другое дело что со сложностью в этом случае вообще не справиться. Пас Конструктивные аргументы закончились  A>>Еще раз: это не более чем плюшки ООП. IB>Что ты понимаешь под "плюшками ООП", а что под не плюшками? Re[18]: Уточняю насчёт GoF и ООП. Автор: Aikin Дата: 18.05.09 Т.е. если убрать Наследование и Полиморфизм, то, ИМХО, ООП как было так и останется ООП. С Инкапсуляцией сложнее, так как она немедленно следует из самого понятия Объект. СУВ, Aikin |
| Re[22]: Уточняю насчёт GoF и ООП. | |
| От: | Aikin | |
| Дата: | 18.05.09 11:39 |
| Здравствуйте, gandjustas, Вы писали: A>>Полностью согласен. Но все мы живем в объектом мире с самого рождения. Наш мозг с самого детства развивался в этом ключе. G>А вот программы в таком мире не живут. Очень малая часть состоит из долгоживущих объектов, которые имеют какое-то поведение и состояние. Продолжай, продолжай, не стоит останавливаться на полуслове. СУВ, Aikin |
| Re[21]: Связность BL и DAL слоёв | |
 | От: | IB rsdn | |
| Дата: | 18.05.09 12:00 |
| Здравствуйте, Aikin, Вы писали: A>Нет. Как это нет? Ты же сам все отлично сформулировал — есть две разные цели : 1. Сериализовать. 2. Заниматься бизнес-логикой. Следуя SRP мы должны сделать два объекта для этих двух обязанностей. A> Мы приходим к одному объекту, который сохранить/восстановить можно только через доступ к приватным членам класса (через рефлексию, например). Поехали по кругу. 1. Какую проблему ты решаешь сначала закрывая доступ, а потом протаптывая дырки через рефлекшен? 2. У тебя объект ничем не занимается, кроме восстановления из БД? С другими подсистемами не взаимодействует? A>Мы не на телеигре "Define it right". Если ты define it wrong, то разговор вообще бесполезен. A>Не нужно преувеличивать. ReadOnly доступ в 99% случаев будет, оставшийся 1% смысла рассматривать нет. То есть хотя бы геттеры у нас все-таки публичные, уже хорошо. Собственно этого достаточно для выноса логики персистентности наружу без извращений, для поднятия из БД достаточно соответствующего конструктора.  Мы уже победили, просто это еще не так заметно... |
| Re[23]: Уточняю насчёт GoF и ООП. | |
| От: | IB rsdn | |
| Дата: | 18.05.09 12:14 | ||
| Оценка: | 4 (1) +1 | ||
| Здравствуйте, Aikin, Вы писали: A>Т.е. если убрать Наследование и Полиморфизм, то, ИМХО, ООП как было так и останется ООП. A>С Инкапсуляцией сложнее, так как она немедленно следует из самого понятия Объект. Нет, все немного сложнее. ООП невозможно без инкапсуляции и полиморфизма. Инкапсуляция вполне возможна и без объектов, но не наоборот, то же самое и с полиморфизмом. Это если от этих терминов плясать. Наследование реализаций действительно в некотором роде рудимент и имеет довольно опосредованное отношение к ООП. Мы уже победили, просто это еще не так заметно... |
| Re[22]: Связность BL и DAL слоёв | |
| От: | Aikin | |
| Дата: | 18.05.09 12:55 |
| Здравствуйте, IB, Вы писали: IB>1. Сериализовать. IB>2. Заниматься бизнес-логикой. IB>Следуя SRP мы должны сделать два объекта для этих двух обязанностей. Да, точно! Что-то я туплю. Сорри. IB>1. Какую проблему ты решаешь сначала закрывая доступ, а потом протаптывая дырки через рефлекшен? Уменьшение сложности системы путем инкапсуляции логики изменения состояния объекта внутри него (напомню, я проектирую в стиле анемик-анемик-рич). Соответственно я запрещаю изменять состояние объекта в обход этой логики. IB>2. У тебя объект ничем не занимается, кроме восстановления из БД? С другими подсистемами не взаимодействует? Я запутался. Есть объект-сущность и объект-"персистер". Я говорю о первом. Сложности второго меня не сильно интересуют, если первый удобно использовать для выполнения его задачи. Тем более, что принципы персистинга универсальны, а вот бизнес-правила уникальны. A>>Не нужно преувеличивать. ReadOnly доступ в 99% случаев будет, оставшийся 1% смысла рассматривать нет. IB>То есть хотя бы геттеры у нас все-таки публичные, уже хорошо. Да. Не вижу особого смысла в абсолютно приватном "данном". IB>Собственно этого достаточно для выноса логики персистентности наружу без извращений, для поднятия из БД достаточно соответствующего конструктора. Это если вручную писать, а если использовать инструменты, то они так же плохо дружат с конструкторами  СУВ, Aikin |
| Re[24]: Уточняю насчёт GoF и ООП. | |
| От: | Aikin | |
| Дата: | 18.05.09 12:55 |
| Здравствуйте, IB, Вы писали: A>>Т.е. если убрать Наследование и Полиморфизм, то, ИМХО, ООП как было так и останется ООП. A>>С Инкапсуляцией сложнее, так как она немедленно следует из самого понятия Объект. IB>Нет, все немного сложнее. ООП невозможно без инкапсуляции и полиморфизма. Инкапсуляция вполне возможна и без объектов, но не наоборот, то же самое и с полиморфизмом. Это если от этих терминов плясать. Ага. Полиморфное поведение присуще объектам мира в котором мы живем: если это автомобиль, то вне зависимости от ее марки он будет "рулиться" так же как и другие. Согласен, без Полиморфизма ООП сильно потерял бы и точно не стал бы мэйнстримом. Но все равно, изначальный тезис не изменился: "людям тупо удобнее думать в категориях объектов и их взаимодействия". И я на нем настаиваю  СУВ, Aikin |
| Re[18]: Уточняю насчёт GoF и ООП. | |
 | От: | IT админ | |
| Дата: | 18.05.09 13:21 | ||
| Оценка: | +1 | ||
| Здравствуйте, dimgel, Вы писали: D>Тезис собственно такой: единственная существенная польза от ООП, благодаря которой его все используют, — это полиморфизм. Полиморфизм в конечном счёте сводится к косвенной адресации, которой в ФП соответствует ФВП, а в C простые указатели на функцию. В общем, ничего военного. Только не понятно, почему народ с таким усердием пытается сэмулировать ООП в pure FP языках, а я помниться, после пары лет применения ООП, когда меня заставили писать обратно на C первый параметер своих глобальных функций называл this.   If nobody helps us, then we, too, will show no mercy. |
| Re[24]: Уточняю насчёт GoF и ООП. | |
| От: | IT админ | |
| Дата: | 18.05.09 13:28 |
| Здравствуйте, IB, Вы писали: IB>Наследование реализаций действительно в некотором роде рудимент и имеет довольно опосредованное отношение к ООП. Только без этого рудимента почему-то не обходится ни одна приличная UI библиотека If nobody helps us, then we, too, will show no mercy. |
| Re[19]: Уточняю насчёт GoF и ООП. | |
| От: | IB rsdn | |
| Дата: | 18.05.09 13:36 |
| Здравствуйте, IT, Вы писали: IT> Только не понятно, почему народ с таким усердием пытается сэмулировать ООП в pure FP языках, а я помниться, после пары лет применения ООП, когда меня заставили писать обратно на C первый параметер своих глобальных функций называл this. Ну есть и обратный эффект, пописав на функциональных языках и возвращаясь к объектным, все равно пишешь немного в функциональном стиле и, надо заметить, как правило не плохо получается. Мы уже победили, просто это еще не так заметно... |
| Re[20]: Уточняю насчёт GoF и ООП. | |
| От: | IT админ | |
| Дата: | 18.05.09 13:38 | ||
| Оценка: | +2 | ||
| Здравствуйте, IB, Вы писали: IB>Ну есть и обратный эффект, пописав на функциональных языках и возвращаясь к объектным, все равно пишешь немного в функциональном стиле и, надо заметить, как правило не плохо получается. Мы это всё уже много раз пережевали. ООП и ФП никак не конфликтуют и отлично дополняют друг друга. Я вообще не понимаю о чём спор If nobody helps us, then we, too, will show no mercy. |
| Re[25]: Уточняю насчёт GoF и ООП. | |
| От: | IB rsdn | |
| Дата: | 18.05.09 13:41 |
| Здравствуйте, IT, Вы писали: IT>Только без этого рудимента почему-то не обходится ни одна приличная UI библиотека Ну, как бы эта. Речь то не про обходиться без этого или нет, а про относится это к ООП или нет.. К тому же, если взять, например, тот же WPF, то при его использовании наследование нужно уже гораздо меньше, чем в winforms... Мы уже победили, просто это еще не так заметно... |
| Re[26]: Уточняю насчёт GoF и ООП. | |
| От: | IT админ | |
| Дата: | 18.05.09 13:50 | ||
| Оценка: | +1 | ||
| Здравствуйте, IB, Вы писали: IT>>Только без этого рудимента почему-то не обходится ни одна приличная UI библиотека IB>Ну, как бы эта. Речь то не про обходиться без этого или нет, а про относится это к ООП или нет.. А к чему оно теперь относится? IB>К тому же, если взять, например, тот же WPF, то при его использовании наследование нужно уже гораздо меньше, чем в winforms... Тем не менее, делать свою кнопку (не говоря уже про грид) с нуля, используя только интерфейсы, тебе не захочется даже в страшном сне If nobody helps us, then we, too, will show no mercy. |
| Re[23]: Связность BL и DAL слоёв | |
| От: | IB rsdn | |
| Дата: | 18.05.09 13:56 |
| Здравствуйте, Aikin, Вы писали: A>Соответственно я запрещаю изменять состояние объекта в обход этой логики. То есть ты эту логику прописываешь на все случаи жизни? А если надо добавить новую логику? A>Это если вручную писать, а если использовать инструменты, то они так же плохо дружат с конструкторами Это проблемы инструментов. Мы уже победили, просто это еще не так заметно... |
| Re[27]: Уточняю насчёт GoF и ООП. | |
| От: | IB rsdn | |
| Дата: | 18.05.09 14:47 |
| Здравствуйте, IT, Вы писали: IT>А к чему оно теперь относится? К особенностям реализации конкретных языков. IT>Тем не менее, делать свою кнопку (не говоря уже про грид) с нуля, используя только интерфейсы, тебе не захочется даже в страшном сне Что значит "с нуля"? Для произвольной кнопки в WPF достаточно XSAML-а. Мы уже победили, просто это еще не так заметно... |
| Re[28]: Уточняю насчёт GoF и ООП. | |
| От: | IT админ | |
| Дата: | 18.05.09 16:13 |
| Здравствуйте, IB, Вы писали: IT>>А к чему оно теперь относится? IB>К особенностям реализации конкретных языков. Особенностям реализации чего? IT>>Тем не менее, делать свою кнопку (не говоря уже про грид) с нуля, используя только интерфейсы, тебе не захочется даже в страшном сне IB>Что значит "с нуля"? Для произвольной кнопки в WPF достаточно XSAML-а. А XAML во что потом преобразуется, не в объекты ли WPF? If nobody helps us, then we, too, will show no mercy. |
| Re[29]: Уточняю насчёт GoF и ООП. | |
| От: | IB rsdn | |
| Дата: | 18.05.09 19:22 |
| Здравствуйте, IT, Вы писали: IT>Особенностям реализации чего? Языков.. ) IT>А XAML во что потом преобразуется, не в объекты ли WPF? В объекты, но это уже дело WPF, а не мое.. Твой же концепт, что библиотека может быть сколь угодно ужасна, лишь бы внешний интерфейс был прекрасен — вот он в действии.. Мы уже победили, просто это еще не так заметно... |
| Re[30]: Уточняю насчёт GoF и ООП. | |
 | От: | Sinix | |
| Дата: | 18.05.09 23:38 | ||
| Оценка: | 28 (1)  | ||
| Здравствуйте, IB, Вы писали: IB>В объекты, но это уже дело WPF, а не мое.. Твой же концепт, что библиотека может быть сколь угодно ужасна, лишь бы внешний интерфейс был прекрасен — вот он в действии.. Уххх, не удержался... сижу матерюсь на шаблон treeview, а тут вы В общем чтоб вы всю жисть пытались изменять отдельные свойства в шаблонах WPF контролов как они сейчас есть! С ViewStateManager оно попроще слекга будет. Когда он выйдет. Нету сейчас в WPF "прекрасного внешнего интерфейса" для тонкого тюнинга стилей. Максимум что можно — сделать сампл/пообъявлять PART_'ы. Хотите свой фон у кнопочки — пишите template с нуля. Сорри за резкость, задалбывают прекрасные поверхностные отзывы, особенно когда забурился в прекрасный внешний интерфейс по уши. |
| Re[30]: Уточняю насчёт GoF и ООП. | |
| От: | IT админ | |
| Дата: | 19.05.09 02:35 |
| Здравствуйте, IB, Вы писали: IT>>Особенностям реализации чего? IB>Языков.. ) Трактовка ООП теперь зависит от языков? Т.е. в C++ и в C# у нас два разных ООП'а? Интересно. IT>>А XAML во что потом преобразуется, не в объекты ли WPF? IB>В объекты, но это уже дело WPF, а не мое.. Твой же концепт, что библиотека может быть сколь угодно ужасна, лишь бы внешний интерфейс был прекрасен — вот он в действии.. Мой концепт? В моих концептах слова "ужасна" нет вообще. Впрочем, "прекрасен" тоже If nobody helps us, then we, too, will show no mercy. |
| 1 2 3 4 5 6 7 8 9 10 11 12 |