Здравствуйте, IB, Вы писали:
A>>В этом случае проще. Но объект дизайнился не для того, чтобы его было просто/удобно перистить, а для того чтобы представлять часть бизнесс логики приложения. IB>Иными словами, мы приходим к двум объектам, один для сериализации, а другой для реализации бизнес-логики приложения — ЧТД..
Нет. Мы приходим к одному объекту, который сохранить/восстановить можно только через доступ к приватным членам класса (через рефлексию, например).
A>>То что его нужно сохранять/воссоздавать -- задача сервисного слоя. IB>Сохранять/загружать нужно не его, а данные, которые он содержит.
Мы не на телеигре "Define it right".
IB>Нужно пояснять, почему второй ответ не правильный?
Не, не нужно, я сам смогу это сделать.
IB>1. Во внешних методах нарошно заточеных для такого функционала, а значит у тебя есть публичный доступ к этим данным.
Не нужно преувеличивать. ReadOnly доступ в 99% случаев будет, оставшийся 1% смысла рассматривать нет.
Здравствуйте, Aikin, Вы писали:
A>Здравствуйте, IB, Вы писали:
A>>>ИМХО, единственная польза от ООП в том, что людям тупо удобнее думать в категориях объектов и их взаимодействия. Все, точка. Остальное не более чем плюшки. IB>>Думать всем удобнее по разному. A>Полностью согласен. Но все мы живем в объектом мире с самого рождения. Наш мозг с самого детства развивался в этом ключе.
А вот программы в таком мире не живут. Очень малая часть состоит из долгоживущих объектов, которые имеют какое-то поведение и состояние.
Здравствуйте, IB, Вы писали:
A>>Но все мы живем в объектом мире с самого рождения. Наш мозг с самого детства развивался в этом ключе. IB>Да вот не факт. Чтобы дорасти до ООП и моделирования в рамках этой концепции мозг приходится вывихнуть довольно основательно. Некоторые вон, до сих пор еще не осилили.. IB>Самый простой подход даже не процедурный, а тупо линейный, другое дело что со сложностью в этом случае вообще не справиться.
Пас
Конструктивные аргументы закончились
A>>Еще раз: это не более чем плюшки ООП. IB>Что ты понимаешь под "плюшками ООП", а что под не плюшками? Re[18]: Уточняю насчёт GoF и ООП.
ИМХО, единственная польза от ООП в том, что людям тупо удобнее думать в категориях объектов и их взаимодействия. Все, точка. Остальное не более чем плюшки.
Т.е. если убрать Наследование и Полиморфизм, то, ИМХО, ООП как было так и останется ООП.
С Инкапсуляцией сложнее, так как она немедленно следует из самого понятия Объект.
Здравствуйте, gandjustas, Вы писали:
A>>Полностью согласен. Но все мы живем в объектом мире с самого рождения. Наш мозг с самого детства развивался в этом ключе. G>А вот программы в таком мире не живут. Очень малая часть состоит из долгоживущих объектов, которые имеют какое-то поведение и состояние.
Продолжай, продолжай, не стоит останавливаться на полуслове.
Здравствуйте, Aikin, Вы писали:
A>Нет.
Как это нет? Ты же сам все отлично сформулировал — есть две разные цели :
1. Сериализовать.
2. Заниматься бизнес-логикой.
Следуя SRP мы должны сделать два объекта для этих двух обязанностей.
A> Мы приходим к одному объекту, который сохранить/восстановить можно только через доступ к приватным членам класса (через рефлексию, например).
Поехали по кругу.
1. Какую проблему ты решаешь сначала закрывая доступ, а потом протаптывая дырки через рефлекшен?
2. У тебя объект ничем не занимается, кроме восстановления из БД? С другими подсистемами не взаимодействует?
A>Мы не на телеигре "Define it right".
Если ты define it wrong, то разговор вообще бесполезен.
A>Не нужно преувеличивать. ReadOnly доступ в 99% случаев будет, оставшийся 1% смысла рассматривать нет.
То есть хотя бы геттеры у нас все-таки публичные, уже хорошо. Собственно этого достаточно для выноса логики персистентности наружу без извращений, для поднятия из БД достаточно соответствующего конструктора.
Здравствуйте, Aikin, Вы писали:
A>Т.е. если убрать Наследование и Полиморфизм, то, ИМХО, ООП как было так и останется ООП. A>С Инкапсуляцией сложнее, так как она немедленно следует из самого понятия Объект.
Нет, все немного сложнее. ООП невозможно без инкапсуляции и полиморфизма. Инкапсуляция вполне возможна и без объектов, но не наоборот, то же самое и с полиморфизмом. Это если от этих терминов плясать. Наследование реализаций действительно в некотором роде рудимент и имеет довольно опосредованное отношение к ООП.
Здравствуйте, IB, Вы писали:
IB>1. Сериализовать. IB>2. Заниматься бизнес-логикой. IB>Следуя SRP мы должны сделать два объекта для этих двух обязанностей.
Да, точно! Что-то я туплю. Сорри.
IB>1. Какую проблему ты решаешь сначала закрывая доступ, а потом протаптывая дырки через рефлекшен?
Уменьшение сложности системы путем инкапсуляции логики изменения состояния объекта внутри него (напомню, я проектирую в стиле анемик-анемик-рич). Соответственно я запрещаю изменять состояние объекта в обход этой логики.
IB>2. У тебя объект ничем не занимается, кроме восстановления из БД? С другими подсистемами не взаимодействует?
Я запутался. Есть объект-сущность и объект-"персистер". Я говорю о первом. Сложности второго меня не сильно интересуют, если первый удобно использовать для выполнения его задачи.
Тем более, что принципы персистинга универсальны, а вот бизнес-правила уникальны.
A>>Не нужно преувеличивать. ReadOnly доступ в 99% случаев будет, оставшийся 1% смысла рассматривать нет. IB>То есть хотя бы геттеры у нас все-таки публичные, уже хорошо.
Да. Не вижу особого смысла в абсолютно приватном "данном".
IB>Собственно этого достаточно для выноса логики персистентности наружу без извращений, для поднятия из БД достаточно соответствующего конструктора.
Это если вручную писать, а если использовать инструменты, то они так же плохо дружат с конструкторами
Здравствуйте, IB, Вы писали:
A>>Т.е. если убрать Наследование и Полиморфизм, то, ИМХО, ООП как было так и останется ООП. A>>С Инкапсуляцией сложнее, так как она немедленно следует из самого понятия Объект. IB>Нет, все немного сложнее. ООП невозможно без инкапсуляции и полиморфизма. Инкапсуляция вполне возможна и без объектов, но не наоборот, то же самое и с полиморфизмом. Это если от этих терминов плясать.
Ага. Полиморфное поведение присуще объектам мира в котором мы живем: если это автомобиль, то вне зависимости от ее марки он будет "рулиться" так же как и другие.
Согласен, без Полиморфизма ООП сильно потерял бы и точно не стал бы мэйнстримом.
Но все равно, изначальный тезис не изменился: "людям тупо удобнее думать в категориях объектов и их взаимодействия". И я на нем настаиваю
Здравствуйте, dimgel, Вы писали:
D>Тезис собственно такой: единственная существенная польза от ООП, благодаря которой его все используют, — это полиморфизм.
Полиморфизм в конечном счёте сводится к косвенной адресации, которой в ФП соответствует ФВП, а в C простые указатели на функцию. В общем, ничего военного. Только не понятно, почему народ с таким усердием пытается сэмулировать ООП в pure FP языках, а я помниться, после пары лет применения ООП, когда меня заставили писать обратно на C первый параметер своих глобальных функций называл this.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT> Только не понятно, почему народ с таким усердием пытается сэмулировать ООП в pure FP языках, а я помниться, после пары лет применения ООП, когда меня заставили писать обратно на C первый параметер своих глобальных функций называл this.
Ну есть и обратный эффект, пописав на функциональных языках и возвращаясь к объектным, все равно пишешь немного в функциональном стиле и, надо заметить, как правило не плохо получается.
Здравствуйте, IB, Вы писали:
IB>Ну есть и обратный эффект, пописав на функциональных языках и возвращаясь к объектным, все равно пишешь немного в функциональном стиле и, надо заметить, как правило не плохо получается.
Мы это всё уже много раз пережевали. ООП и ФП никак не конфликтуют и отлично дополняют друг друга. Я вообще не понимаю о чём спор
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Только без этого рудимента почему-то не обходится ни одна приличная UI библиотека
Ну, как бы эта. Речь то не про обходиться без этого или нет, а про относится это к ООП или нет..
К тому же, если взять, например, тот же WPF, то при его использовании наследование нужно уже гораздо меньше, чем в winforms...
Здравствуйте, IB, Вы писали:
IT>>Только без этого рудимента почему-то не обходится ни одна приличная UI библиотека IB>Ну, как бы эта. Речь то не про обходиться без этого или нет, а про относится это к ООП или нет..
А к чему оно теперь относится?
IB>К тому же, если взять, например, тот же WPF, то при его использовании наследование нужно уже гораздо меньше, чем в winforms...
Тем не менее, делать свою кнопку (не говоря уже про грид) с нуля, используя только интерфейсы, тебе не захочется даже в страшном сне
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Aikin, Вы писали:
A>Соответственно я запрещаю изменять состояние объекта в обход этой логики.
То есть ты эту логику прописываешь на все случаи жизни?
А если надо добавить новую логику?
A>Это если вручную писать, а если использовать инструменты, то они так же плохо дружат с конструкторами
Это проблемы инструментов.
Здравствуйте, IT, Вы писали:
IT>А к чему оно теперь относится?
К особенностям реализации конкретных языков.
IT>Тем не менее, делать свою кнопку (не говоря уже про грид) с нуля, используя только интерфейсы, тебе не захочется даже в страшном сне
Что значит "с нуля"? Для произвольной кнопки в WPF достаточно XSAML-а.
Здравствуйте, IB, Вы писали:
IT>>А к чему оно теперь относится? IB>К особенностям реализации конкретных языков.
Особенностям реализации чего?
IT>>Тем не менее, делать свою кнопку (не говоря уже про грид) с нуля, используя только интерфейсы, тебе не захочется даже в страшном сне IB>Что значит "с нуля"? Для произвольной кнопки в WPF достаточно XSAML-а.
А XAML во что потом преобразуется, не в объекты ли WPF?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Особенностям реализации чего?
Языков.. )
IT>А XAML во что потом преобразуется, не в объекты ли WPF?
В объекты, но это уже дело WPF, а не мое.. Твой же концепт, что библиотека может быть сколь угодно ужасна, лишь бы внешний интерфейс был прекрасен — вот он в действии..
Здравствуйте, IB, Вы писали:
IB>В объекты, но это уже дело WPF, а не мое.. Твой же концепт, что библиотека может быть сколь угодно ужасна, лишь бы внешний интерфейс был прекрасен — вот он в действии..
Уххх, не удержался... сижу матерюсь на шаблон treeview, а тут вы
В общем чтоб вы всю жисть пытались изменять отдельные свойства в шаблонах WPF контролов как они сейчас есть!
С ViewStateManager оно попроще слекга будет. Когда он выйдет.
Нету сейчас в WPF "прекрасного внешнего интерфейса" для тонкого тюнинга стилей. Максимум что можно — сделать сампл/пообъявлять PART_'ы. Хотите свой фон у кнопочки — пишите template с нуля.
Сорри за резкость, задалбывают прекрасные поверхностные отзывы, особенно когда забурился в прекрасный внешний интерфейс по уши.
Здравствуйте, IB, Вы писали:
IT>>Особенностям реализации чего? IB>Языков.. )
Трактовка ООП теперь зависит от языков? Т.е. в C++ и в C# у нас два разных ООП'а? Интересно.
IT>>А XAML во что потом преобразуется, не в объекты ли WPF? IB>В объекты, но это уже дело WPF, а не мое.. Твой же концепт, что библиотека может быть сколь угодно ужасна, лишь бы внешний интерфейс был прекрасен — вот он в действии..
Мой концепт? В моих концептах слова "ужасна" нет вообще. Впрочем, "прекрасен" тоже
Если нам не помогут, то мы тоже никого не пощадим.
Мы уже победили, просто это еще не так заметно...
Если нам не помогут, то мы тоже никого не пощадим.
