Здравствуйте, Sinix, Вы писали:
S>Сорри за резкость, задалбывают прекрасные поверхностные отзывы, особенно когда забурился в прекрасный внешний интерфейс по уши.
К сожалению UI один из наиболее сложных компонентов приложения, хуже всего поддающийся унификации. Соответственно и библиотеки UI делать сложно и придумать, а главное потом реализовать что-то выдающееся очень и очень сложно. WPF тоже не вершина эволюции, особенно в плане реализации. Это точно. И уж ещё более точно, что вершина эволюции 100% не будет построена на ООП, используя только наследование интерфейсов. Звучит красиво, но абсолютно нежизнеспособно.
Если нам не помогут, то мы тоже никого не пощадим.
Сгласен. Я дико извиняюсь, не хотел никого обидеть, просто пост попался в очень удачный момент. Для view сложного контрола на самом деле ничего кроме машины состояний не придумаешь — wpf team к ней и пришла с ViewStateManager.
А louse coupling для view контрола неизбежно превращается в страшные прыжки с просмотром visual tree.
Не пробовали допустим пополучать TreeItem у WPF TreeView? крайне занятная задача. Учитывая что новые узлы не появляются сразу после изменения списка — идёт пинок dispatcher'у и уже он в свободное время по возможности их добавляет.
Ещё забавней — подменить template без потери feyboard focus (обычный остаётся...). Нужно было для редактирования элементов прямо в TreeView (аля в винформс аналоге).
Здравствуйте, Sinix, Вы писали:
S>С ViewStateManager оно попроще слекга будет. Когда он выйдет.
На codeplex вроде есть.
S>Нету сейчас в WPF "прекрасного внешнего интерфейса" для тонкого тюнинга стилей. Максимум что можно — сделать сампл/пообъявлять PART_'ы. Хотите свой фон у кнопочки — пишите template с нуля.
Ну насчет "с нуля" не надо перегибать. Темплейты всех контролов в виде xaml доступы. Копипаст и смена только нужных частей решает все проблемы.
Здравствуйте, gandjustas, Вы писали:
G>На codeplex вроде есть.
У ViewStateManager есть баг с утечкой памяти. Месяц назад ещё не пофиксили. Как сейчас —
G>Ну насчет "с нуля" не надо перегибать. Темплейты всех контролов в виде xaml доступы. Копипаст и смена только нужных частей решает все проблемы.
Мдя, тут я перегнул. Но всё равно в плане саппорта извратом выглядит. Допустим шаблон меню для silver theme поменяли в .net 3.0 sp1 (был глюк с тенью). Согласитесь, необходимость перегенеривать шаблоны с каждым мелким фиксом — явный косяк дизайна.
P.S. Если что: мне WPF нравится куда больше винформсов. Ждём fw4, обещали пофиксить ряд багов с биндигом, да и с шаблонами попроще будет.
Здравствуйте, IT, Вы писали:
IT>Трактовка ООП теперь зависит от языков? Т.е. в C++ и в C# у нас два разных ООП'а?
Конечно. ООП — это сфероконь в вакууме, и говорить о чистом ООП имеет смысл, когда нужно разобраться с общей теорией и концептом.
А каждый конкретный язык реализует (интерпретирует, если угодно) ООП по своему. Например, ты же прекрасно знаешь, что в тру-ООП нет никаких виртуальных вызовов, а все происходит посредством обмена сообщениями, однако большинство современных языков реализовали это дело как вызовы методов. В смолтолке, ООП-нутее которого больше не было, в первых версиях никакого наследования не существовало, и так все работало в силу динамичности языка. Понадобилась статика — прикрутили наследование, чтобы полиморфизм получить, и так далее...
То же наличие интерфейсов в C# — уже другая интерпретация по сравнению с C++, где их нет.
Так что таки да, наследование реализаций — это конкретная интерпретация идей ООП в конкретных языках, вполне рабочая и бурно применяемая на практике, кто бы спорил...
И вообще ты меня не путай. Мы о другом немного, тут юноша заявил, что мол "это не ООП", причем использовал это в качестве аргумента непонятно в чем, и я уже устал у него вытягивать, что же он под ООП имеет ввиду и почему "это" не ООП.
Так что мы пока о теории, до практики пока не добрались, а тут ты со своими языками..
IT>Мой концепт? В моих концептах слова "ужасна" нет вообще. Впрочем, "прекрасен" тоже
Это уже детали реализации твоего концепта..
Здравствуйте, IB, Вы писали:
IB>То же наличие интерфейсов в C# — уже другая интерпретация по сравнению с C++, где их нет.
Как это нет, а как же народ пишет COM на плюсах?
IB>Так что таки да, наследование реализаций — это конкретная интерпретация идей ООП в конкретных языках, вполне рабочая и бурно применяемая на практике, кто бы спорил...
Ваня, интерфейсы немного из другой оперы, они имеют больше отношение к компонентности (откуда они и появились), чем к ООП. А ООП в свою очередь наследование никак не разделяет на интерфейс и реализацию, есть просто наследование. Можно, конечно, постоянно менять трактовки и терминологию, но так мы быстро придём к тому, что сделали джависты с ORM — создадим терминологию, в которой термин и то, что он обозначает это два совершенно разных человека. И будем потом объяснять, что true наследование, это наследование интерфейса, при условии наличия lazy loading и хранилища объектов. Иначе это что угодно, но не наследование.
IB>И вообще ты меня не путай. Мы о другом немного, тут юноша заявил, что мол "это не ООП", причем использовал это в качестве аргумента непонятно в чем, и я уже устал у него вытягивать, что же он под ООП имеет ввиду и почему "это" не ООП. IB>Так что мы пока о теории, до практики пока не добрались, а тут ты со своими языками..
Не-не-не-не. Вы там можете сколько угодно теоретизировать, но оставайтесь в рамках приличия. Не надо вносить ненужные опасные мутации в веками устоявшуюся терминологию.
IT>>Мой концепт? В моих концептах слова "ужасна" нет вообще. Впрочем, "прекрасен" тоже IB>Это уже детали реализации твоего концепта..
Реализация моего концепта предельно проста — всё должно быть предельно просто
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Как это нет, а как же народ пишет COM на плюсах?
Посредством COM интерфейсов.. =)
IT>Ваня, интерфейсы немного из другой оперы, они имеют больше отношение к компонентности (откуда они и появились), чем к ООП.
Опера все та же, просто в какой-то момент догадались эти два понятия разделить (контракт и реализацию), что ни разу не пошло во вред ООП.
IT> А ООП в свою очередь наследование никак не разделяет на интерфейс и реализацию, есть просто наследование.
Правильно, потому что наследование контрактов и наследование реализаций — это конкретные реализации концепции наследования... Какие-то языки поддерживают оба, какие-то только наследование реализаций, а какие-то вообще без наследования обходятся, что не мешает им быть ООП.
IT> Можно, конечно, постоянно менять трактовки и терминологию,
Трактовки и терминологию никто не меняет, за отсутствием таковых.
IT> Не надо вносить ненужные опасные мутации в веками устоявшуюся терминологию.
Какие мутации? Где эта устоявшаяся терминология?
IT>Реализация моего концепта предельно проста — всё должно быть предельно просто
Но не проще..
Здравствуйте, IB, Вы писали:
IT>>Как это нет, а как же народ пишет COM на плюсах? IB>Посредством COM интерфейсов.. =)
Так их же нет в плюсах
IT>> А ООП в свою очередь наследование никак не разделяет на интерфейс и реализацию, есть просто наследование. IB>Правильно, потому что наследование контрактов и наследование реализаций — это конкретные реализации концепции наследования... Какие-то языки поддерживают оба, какие-то только наследование реализаций, а какие-то вообще без наследования обходятся, что не мешает им быть ООП.
Ещё раз. Интерфейс — это атрибутика компонентности, а не ООП.
IT>> Не надо вносить ненужные опасные мутации в веками устоявшуюся терминологию. IB>Какие мутации? Где эта устоявшаяся терминология?
Твои мутации. Это твоё?
Наследование реализаций действительно в некотором роде рудимент и имеет довольно опосредованное отношение к ООП.
IT>>Реализация моего концепта предельно проста — всё должно быть предельно просто IB>Но не проще..
Нет, не проще
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Так их же нет в плюсах
Ну это же не значит, что в плюсах их нельзя эмулировать..
IT>Ещё раз. Интерфейс — это атрибутика компонентности, а не ООП.
Еще раз выделение контракта в отдельную сущность — это особенность реализации.
IT>Твои мутации. Это твоё?
У меня мутаций нет..
IT>
IT>Наследование реализаций действительно в некотором роде рудимент и имеет довольно опосредованное отношение к ООП.
Мое, тебе не понравилось "наследование реализаций"? Могу обобщить — "Наследование действительно в некотором роде рудимент и имеет довольно опосредованное отношение к ООП"
IT>Нет, не проще
Вооот.. )
Здравствуйте, IB, Вы писали:
IT>>Так их же нет в плюсах IB>Ну это же не значит, что в плюсах их нельзя эмулировать..
Т.е. они есть
IT>>Ещё раз. Интерфейс — это атрибутика компонентности, а не ООП. IB>Еще раз выделение контракта в отдельную сущность — это особенность реализации.
Реализации чего? Наследования или компонентности?
IT>>Твои мутации. Это твоё? IB>У меня мутаций нет..
Мутации есть у всех.
IT>>
IT>>Наследование реализаций действительно в некотором роде рудимент и имеет довольно опосредованное отношение к ООП.
IB>Мое, тебе не понравилось "наследование реализаций"? Могу обобщить — "Наследование действительно в некотором роде рудимент и имеет довольно опосредованное отношение к ООП"
Наследование — это один из столпов ООП, как оно может иметь к нему "довольно опосредованное отношение"?
IT>>Нет, не проще IB>Вооот.. )
Ага.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Т.е. они есть
В виде First Class Object нет, эмулировать можно. Мы в таком стиле долго продолжать можем... )
IT>Реализации чего? Наследования или компонентности?
Реализации наследования в конкретных языках.
IT>Наследование — это один из столпов ООП, как оно может иметь к нему "довольно опосредованное отношение"?
Не совсем так, "столпы ООП" — это инкапсуляция и полиморфизм, так как следуют напрямую из определения Кея. Наследование же, это один из вариантов получения полиморфизма, но настолько вкусный, что его тоже к столпам приписывают.
Собственно, в первых версиях смолтолка, как я уже говорил, наследования не было, и есть целый класс prototype-based языков, наследованием не оборудованных, которые, тем не менее, полноценные ОО языки.
Здравствуйте, IB, Вы писали:
IT>>Наследование — это один из столпов ООП, как оно может иметь к нему "довольно опосредованное отношение"? IB>Не совсем так, "столпы ООП" — это инкапсуляция и полиморфизм, так как следуют напрямую из определения Кея. Наследование же, это один из вариантов получения полиморфизма, но настолько вкусный, что его тоже к столпам приписывают.
Куда-то непонятно тебя занесло. Давай начнём с базовых определений Полиморфизм позволяет объекту выбирать правильный метод в зависимости от переданных параметров. А наследование — это механизм позволяющий пораждать новый класс на базе существующего. Они, конечно, связаны через реализацию, но это уже детали реализации.
IB>Собственно, в первых версиях смолтолка, как я уже говорил, наследования не было, и есть целый класс prototype-based языков, наследованием не оборудованных, которые, тем не менее, полноценные ОО языки.
Ну мало ли сколько недоязыков появилось пока концепция не приобрела стройный и законченный вид. Где все эти языки, где твой смолток? В музее. Вот там ему и место. И не стоит доставать его из пыльного шкафа и апеллировать к его исторически оправданным недостаткам. А то так можно договориться до того, что человеку надо поотрезать ухи и ноги, потому что их нет у амёбы.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, IB, Вы писали:
IT>>>Наследование — это один из столпов ООП, как оно может иметь к нему "довольно опосредованное отношение"? IB>>Не совсем так, "столпы ООП" — это инкапсуляция и полиморфизм, так как следуют напрямую из определения Кея. Наследование же, это один из вариантов получения полиморфизма, но настолько вкусный, что его тоже к столпам приписывают.
IT>Куда-то непонятно тебя занесло. Давай начнём с базовых определений Полиморфизм позволяет объекту выбирать правильный метод в зависимости от переданных параметров.
Это не так. http://www.rsdn.ru/forum/message/2853873.aspx
IT>А наследование — это механизм позволяющий пораждать новый класс на базе существующего. Они, конечно, связаны через реализацию, но это уже детали реализации.
Это если вводить понятие "класс", которое для ООП совершенно необязательно.
Эти базовые определения рассказывают студентам на первом курсе, взяты они в основномиз C++ и паскаля седьмой версии.
IB>>Собственно, в первых версиях смолтолка, как я уже говорил, наследования не было, и есть целый класс prototype-based языков, наследованием не оборудованных, которые, тем не менее, полноценные ОО языки.
IT>Ну мало ли сколько недоязыков появилось пока концепция не приобрела стройный и законченный вид. Где все эти языки, где твой смолток? В музее. Вот там ему и место. И не стоит доставать его из пыльного шкафа и апеллировать к его исторически оправданным недостаткам. А то так можно договориться до того, что человеку надо поотрезать ухи и ноги, потому что их нет у амёбы.
Понимание ООП в статически и динамически типизруемых языках может кардинально отличаться.
Здравствуйте, gandjustas, Вы писали:
IT>>Куда-то непонятно тебя занесло. Давай начнём с базовых определений Полиморфизм позволяет объекту выбирать правильный метод в зависимости от переданных параметров. G>Это не так. http://www.rsdn.ru/forum/message/2853873.aspx
Как это опровергает сказанное?
IT>>А наследование — это механизм позволяющий пораждать новый класс на базе существующего. Они, конечно, связаны через реализацию, но это уже детали реализации. G>Это если вводить понятие "класс", которое для ООП совершенно необязательно.
Замени "класс" на любое слово, которое тебе нравится и да будет тебе счастье. Аминь.
G>Эти базовые определения рассказывают студентам на первом курсе, взяты они в основномиз C++ и паскаля седьмой версии.
Странно, что через много лет работы программисты начинают в них путаться. Правда? Ваня вот похоже зациклился на нелюбви к наследованию реализации и как следствие перепутал виртуальные методы с наследованием.
G>Понимание ООП в статически и динамически типизруемых языках может кардинально отличаться.
Например?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT> Полиморфизм позволяет объекту выбирать правильный метод в зависимости от переданных параметров.
Прально! (правда метод — уже конкретика) И this, в случае наследования, у нас тоже параметр, который позволяет вызвать правильный перегруженный или базовый метод.
Конкретно данный механизм называется — неявный ad-hoc полиморфизм по первому аргументу, если ты точных определений хочешь..
IT> А наследование — это механизм позволяющий пораждать новый класс на базе существующего.
Угу, вопрос только "для чего"? Собственно, требования пораждать новый класс на базе существующего в ООП нет (как и классов), но это очень удобный и красивый механизм полиморфизма. Благодаря наследованию происходит неявный вызов перегруженного метода (исполнение нужной логики) у нужного наследника, совершенно прозрачно для вызывающего кода. Ради этого все и задумывалось — чтобы код, реализующий логику вызовов не нуждался в указании того, что именно он вызывает, а нужная логика подставлялась автоматически.
А то, что в следствии таких приседаний еще и вызовы не нужно дублировать, если не нужно базовую реализацию перегружать — приятный бонус. С другой стороны в прототипных языках и без этого с успехом обходятся и они не перестают быть ООП.
IT>Где все эти языки, где твой смолток? В музее.
Ну вот JScript не в музее ни разу.
IT> А то так можно договориться до того, что человеку надо поотрезать ухи и ноги, потому что их нет у амёбы.
Не увлекайся, я тоже много забавных аналогий придумать могу..
Здравствуйте, IT, Вы писали:
IT>Ваня вот похоже зациклился на нелюбви к наследованию реализации и как следствие перепутал виртуальные методы с наследованием.
Где? Это похоже ты зацикликлся, что я зациклился на нелюбви к наследованию реализации..
Здравствуйте, IB, Вы писали:
IB>Конкретно данный механизм называется — неявный ad-hoc полиморфизм по первому аргументу, если ты точных определений хочешь..
Ну понятно, т.е. особых возражений по этому поводу нет.
IT>> А наследование — это механизм позволяющий пораждать новый класс на базе существующего. IB>Угу, вопрос только "для чего"? Собственно, требования пораждать новый класс на базе существующего в ООП нет (как и классов), но это очень удобный и красивый механизм полиморфизма. Благодаря наследованию происходит неявный вызов перегруженного метода (исполнение нужной логики) у нужного наследника, совершенно прозрачно для вызывающего кода. Ради этого все и задумывалось — чтобы код, реализующий логику вызовов не нуждался в указании того, что именно он вызывает, а нужная логика подставлялась автоматически.
Это кто тебе сказал, что именно ради этого всё и задумывалось? Мне известно множество применений наследования без всяких виртуальных методов.
Всё же у меня создаётся стойкое впечатление, что ты где-то перепутал причину со следствием.
IB>А то, что в следствии таких приседаний еще и вызовы не нужно дублировать, если не нужно базовую реализацию перегружать — приятный бонус. С другой стороны в прототипных языках и без этого с успехом обходятся и они не перестают быть ООП.
Я в стиле ООП писал даже на С в своё время и ничего, работало. А ещё Борланд как-то умудрился запихнуть ООП в TASM. Прикольно было. Так что при желании любой паттерн можно реализовать на чём угодно. Только нужно ли?
IT>>Где все эти языки, где твой смолток? В музее. IB>Ну вот JScript не в музее ни разу.
ООП в джава-скрипте сделан, мягко скажем, через прототипизацию.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
IT>>>Куда-то непонятно тебя занесло. Давай начнём с базовых определений Полиморфизм позволяет объекту выбирать правильный метод в зависимости от переданных параметров. G>>Это не так. http://www.rsdn.ru/forum/message/2853873.aspx
IT>Как это опровергает сказанное?
Сказанное являтся очень частным случаем, полиморфизма.
IT>>>А наследование — это механизм позволяющий пораждать новый класс на базе существующего. Они, конечно, связаны через реализацию, но это уже детали реализации. G>>Это если вводить понятие "класс", которое для ООП совершенно необязательно. IT>Замени "класс" на любое слово, которое тебе нравится и да будет тебе счастье. Аминь.
В javascript нету ничего похожего на классы C++.
G>>Эти базовые определения рассказывают студентам на первом курсе, взяты они в основномиз C++ и паскаля седьмой версии. IT>Странно, что через много лет работы программисты начинают в них путаться. Правда? Ваня вот похоже зациклился на нелюбви к наследованию реализации и как следствие перепутал виртуальные методы с наследованием.
Похоже он неправльно объяснил свою мысль. Ведь виртуальные методы без наследования не очень то нужны.
G>>Понимание ООП в статически и динамически типизруемых языках может кардинально отличаться. IT>Например?
Например любой динамический язык (теже puthon и ruby) могут обходится без наследования для получения того же эффекта от полиморфизма (в частности виртуальных методов), как в статически типизируемых языках. А в javascript этого неследования и не было никогда.
Здравствуйте, IT, Вы писали:
IT>Ну понятно, т.е. особых возражений по этому поводу нет.
Ну, кроме того, что ты тут полиморфизм урезал..
IT>Это кто тебе сказал, что именно ради этого всё и задумывалось? Мне известно множество применений наследования без всяких виртуальных методов.
Конечно, но не без полиморфизма..
Вот смотри, глобально ты можешь использовать наследование для двух целей:
1. Перегрузить родительскую реализацию, то есть заиспользовать виртуальность. Как мы выяснили, это неявный ad-hoc полиморфизм — в зависимости от типа выполняется разный код.
2. Не трогая родительскую реализацию, расширить базовый класс новыми методами. Это параметрический полиморфизм — один и тот же код работает в разных классах (типах). Если бы параметрический полиморфизм не был нужен, то, с точки зрения ООП, нет смысла и наследоваться, с тем же успехом можно создать новый тип рядом, с дополнительным функционалом и при необходимость явно обращаться к нему. Таким образом, для чего бы ты наследование не использовал, оно все равно упирается в полиморфизм.
IT>Всё же у меня создаётся стойкое впечатление, что ты где-то перепутал причину со следствием.
Я ничего не путал, я просто в свое время потрудился разобраться откуда ноги растут.. Есть сложившийся стереотип, что наследование, это неотъемлемая часть ООП, но на поверку это не совсем так.
IT>ООП в джава-скрипте сделан, мягко скажем, через прототипизацию.
Но тем не менее, это полноценный ООП, без наследования.
Если нам не помогут, то мы тоже никого не пощадим.
Мы уже победили, просто это еще не так заметно...
