Здравствуйте, VladD2, Вы писали:
VD>В прочем, на самом деле нет особой нужды в Mutable-интерфейсах. Вот скажи, ты сам то часто на практике добавлял элементы через IList<T> или ICollection<T>? Я — ни разу.
А я постоянно. Никогда не объявляю переменную конкретного типа за исключением случаев, когда иначе нельзя. Всегда использую самый базовый тип, какой только возможно.
VD>Когда коллекция заполняется, то обычно работа идет с конкретными типами.
Прямо противоположный опыт. В общем ты сам испугался что интерфейсов много и решил оставить только readonly. Совсем не интересный вариант.
A>>Кроме того, что делать с ситуациями, когда доступно операции величина не постоянная? Вот скажем у меня коллекция связана с каким-то хранилищем (БД или что-то ещё) и менять её (писать в хранилище) можно только наложив блокировку. То есть в каких-то случаях (когда блокировки нет) IsReadOnly вернёт true, а Add(T) выбросит InvalidOperationException, а в каких-то других случаях IsReadOnly вернёт false и Add(T) отработает штатно. Как такие сценарии сочетаются с идеей fine grained interfaces?
VD>Это какая-то выдуманная фигня. Что ее разбирать то?
О да, гениальный аргумент. Вообще-то это абсолютно реальная ситуация взятая из рабочего проекта. Её действительно не надо разбирать, она имеет место быть и это надо принять как есть.
Здравствуйте, adontz, Вы писали:
A>А я постоянно. Никогда не объявляю переменную конкретного типа за исключением случаев, когда иначе нельзя. Всегда использую самый базовый тип, какой только возможно.
Зачем?
VD>>Когда коллекция заполняется, то обычно работа идет с конкретными типами.
A>Прямо противоположный опыт. В общем ты сам испугался что интерфейсов много и решил оставить только readonly. Совсем не интересный вариант.
Может стоит подумать над тем что и зачем ты делаешь?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>А я постоянно. Никогда не объявляю переменную конкретного типа за исключением случаев, когда иначе нельзя. Всегда использую самый базовый тип, какой только возможно. VD>Зачем?
Коллекция не всегда создаётся и заполняется в рамках одного метода, так что будьте знакомы — http://en.wikipedia.org/wiki/Interface_segregation_principle
VD>>>Когда коллекция заполняется, то обычно работа идет с конкретными типами. A>>Прямо противоположный опыт. В общем ты сам испугался что интерфейсов много и решил оставить только readonly. Совсем не интересный вариант. VD>Может стоит подумать над тем что и зачем ты делаешь?
Зачем я не сообщаю всем подряд тип класса конкретной реализации? Мне что, действительно придётся это объяснять?
Вообще-то конечно жить лучше своими мозгами, но все же ты бы прежде чем давать ссылку почитал бы ее. Это статья как раз о том почему в IList не должно быть Insert().
A>Зачем я не сообщаю всем подряд тип класса конкретной реализации? Мне что, действительно придётся это объяснять?
Зачем кому-то рассказывать о внутренней реализации?
ЗЫ
Есть один отличный принцип который я почерпнул из ФП. Если речь идет об обрабокте данных, то лучше стараться всегда делать ее так чтобы не изменять исходных данных. А к императиву прибегать только когда это оправдано соображениями производительности или иными весомыми соображениями. Тогда весь код по работе с коллекциями резко уходит в глубь методов, а на ружу начинают торчать списки (в немерле list[T]) и массивы (копии данных). При этом вопросов с абстрагированием или связанностью не возникает в принципе. Мы ведь всегда работаем с "отключенными" данными (копиями).
Так что если я вижу в коде передачу изменяемой коллекции (даже интерфейса) в другой метод, то это сразу же меня настораживает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, samius, Вы писали:
A>>Коллекция не всегда создаётся и заполняется в рамках одного метода, так что будьте знакомы — http://en.wikipedia.org/wiki/Interface_segregation_principle S>кстати, да, ISP — еще один довод против существующих интерфейсов. S>
S>Instead of one fat interface many small interfaces are preferred based on groups of methods, each one serving one submodule.
И саго, употреблённое не в меру, может причинить вред.
Здравствуйте, VladD2, Вы писали:
A>>Коллекция не всегда создаётся и заполняется в рамках одного метода, VD>Вот это у тебя косяк в дизайне, да. Старайся так не делать.
Аргументы будут?
A>> так что будьте знакомы — http://en.wikipedia.org/wiki/Interface_segregation_principle VD>Вообще-то конечно жить лучше своими мозгами, но все же ты бы прежде чем давать ссылку почитал бы ее. Это статья как раз о том почему в IList не должно быть Insert().
Вот давай без прыжков в сторону. Речь шла об использовании конкретного типа вместо интерфейса.
A>>Зачем я не сообщаю всем подряд тип класса конкретной реализации? Мне что, действительно придётся это объяснять? VD>Зачем кому-то рассказывать о внутренней реализации?
Вот именно, зачем?
VD>Есть один отличный принцип который я почерпнул из ФП. Если речь идет об обработке данных, то лучше стараться всегда делать ее так чтобы не изменять исходных данных. А к императиву прибегать только когда это оправдано соображениями производительности или иными весомыми соображениями. Тогда весь код по работе с коллекциями резко уходит в глубь методов, а наружу начинают торчать списки (в немерле list[T]) и массивы (копии данных). При этом вопросов с абстрагированием или связанностью не возникает в принципе. Мы ведь всегда работаем с "отключенными" данными (копиями). VD>Так что если я вижу в коде передачу изменяемой коллекции (даже интерфейса) в другой метод, то это сразу же меня настораживает.
Влад, как эти замечательные рассуждения коррелируют с каким-либо байндингом? А, ну да, никак. На Nemerle или ASP.Net мир клином не сошёлся. Бывает необходимо обмениваться изменяемыми коллекциями и это не всегда плохой дизайн, как ты почему-то думаешь.
Здравствуйте, adontz, Вы писали:
A>>>Коллекция не всегда создаётся и заполняется в рамках одного метода, VD>>Вот это у тебя косяк в дизайне, да. Старайся так не делать.
A>Аргументы будут?
Для меня это настолько очевидно, что я даже затрудняюсь найти доходчивое объяснение.
Пока мы меняем коллекцию внутри метода — это проблемы реализации одного метода. Когда мы растягиваем этот процесс по нескольким методам, то начинаем иметь дело с неинкапсулированным состоянием. А это уже не хорошо. Я конечно понимаю, что на языках где нет локальных функций подмывает разбить код (произвести его декомпозицию) на отдельные (хотя бы private) методы. Но все же это плохо. Решаем одну проблему — создаем другую.
A>>> так что будьте знакомы — http://en.wikipedia.org/wiki/Interface_segregation_principle VD>>Вообще-то конечно жить лучше своими мозгами, но все же ты бы прежде чем давать ссылку почитал бы ее. Это статья как раз о том почему в IList не должно быть Insert().
A>Вот давай без прыжков в сторону. Речь шла об использовании конкретного типа вместо интерфейса.
Какие прыжки? Изначально мы говорили о том, что интерфейсы коллекций в дотнете криво спроектированы. Ты дал ссылку на кошерное обоснование того, что интерфейсы должны быть маленькими и специализированными, а не толстыми и всеобъемлющими.
А вот про конкретные типы я там ничего не углядел.
Ты наверно перепутал этот принцип с простой идеей, что возвращать конекртные изменяемые коллекции из методов не кошерно. С этим я в общем-то согласен. Хотя тоже не вижу в этом ничего плохого, если возвращается копия.
A>>>Зачем я не сообщаю всем подряд тип класса конкретной реализации? Мне что, действительно придётся это объяснять? VD>>Зачем кому-то рассказывать о внутренней реализации?
A>Вот именно, зачем?
Дык ты это и предлагаешь. Причем думаешь, что если спрятать изменяемый индексируемый список за интерфейсом, то это решит проблему. Не решит. Ты конечно получишь гипотетический бенефит от того, что сможешь сменить реализацию коллекции не трогая другого кода. Но плюешь на куда более серьезную проблему размазывания императивного алгоритма по разным методам. Императив нужно инкапсулирвоать.
И кстати, если бы ты передавал именно IMutableList, то по сигнатуре метода уже можно было бы понять, что он будет менять этот список, а значит с данным методом нужно быть как можно акуратнее. А так ты передаешь IList и в те методы что просто нуждаются в списке, и в те, что собираются его изменять. Это явное использование абстракции на вред себе любимому. Это ничем не отличается от передачи IMutableList методу который не собирается менять данные.
VD>>Есть один отличный принцип который я почерпнул из ФП. Если речь идет об обработке данных, то лучше стараться всегда делать ее так чтобы не изменять исходных данных. А к императиву прибегать только когда это оправдано соображениями производительности или иными весомыми соображениями. Тогда весь код по работе с коллекциями резко уходит в глубь методов, а наружу начинают торчать списки (в немерле list[T]) и массивы (копии данных). При этом вопросов с абстрагированием или связанностью не возникает в принципе. Мы ведь всегда работаем с "отключенными" данными (копиями). VD>>Так что если я вижу в коде передачу изменяемой коллекции (даже интерфейса) в другой метод, то это сразу же меня настораживает.
A>Влад, как эти замечательные рассуждения коррелируют с каким-либо байндингом?
Зависит от реализации оного.
A>А, ну да, никак. На Nemerle или ASP.Net мир клином не сошёлся. Бывает необходимо обмениваться изменяемыми коллекциями и это не всегда плохой дизайн, как ты почему-то думаешь.
Дык и неизменяемыми структурами данных можно обмениваться без проблем. В конце концов любое изменение можно рассматривать как удаление старого объекта и вставку нового. Так что на входе имеем список с исходными объектами, на выходе новый где часть объектов старые, а часть новые (ставленные или замененные). При этом очень легко сделать между ними diff и получить третий список содержащий только изменения.
Потом на ГУИ свет клином не сошелся. ГУЯ не так много в серьезных задачах. Обработка данных обычно занимает куда больше места и времени (программиста). И тут вопросы биндига уже не будут актуальны.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Для меня это настолько очевидно, что я даже затрудняюсь найти доходчивое объяснение. VD>Пока мы меняем коллекцию внутри метода — это проблемы реализации одного метода. Когда мы растягиваем этот процесс по нескольким методам, то начинаем иметь дело с неинкапсулированным состоянием. А это уже не хорошо. Я конечно понимаю, что на языках где нет локальных функций подмывает разбить код (произвести его декомпозицию) на отдельные (хотя бы private) методы. Но все же это плохо. Решаем одну проблему — создаем другую.
Ты умудрился чудесно переврать мои слова. Давай ты попытаешься прочесть это предложение ещё раз — "Коллекция не всегда создаётся и заполняется в рамках одного метода".
VD>Какие прыжки? Изначально мы говорили о том, что интерфейсы коллекций в дотнете криво спроектированы. Ты дал ссылку на кошерное обоснование того, что интерфейсы должны быть маленькими и специализированными, а не толстыми и всеобъемлющими.
Вообще-то там ничего не говориться о больших или маленьких интерфейсах. Размер в ISP вообще не цель и характеристика. Речь там идёт о минимально необходимом интерфейсе.
VD>А вот про конкретные типы я там ничего не углядел.
Не воспринимай слово интерфейс слишком узко. Там не про ключевое слово языка C# говорится.
VD>Ты наверно перепутал этот принцип с простой идеей, что возвращать конекртные изменяемые коллекции из методов не кошерно. С этим я в общем-то согласен. Хотя тоже не вижу в этом ничего плохого, если возвращается копия.
Никакой путаницы нет, твоя простая идея есть элементарный вывод из существования ISP. Копирование и уточнение типа перпендикулярны.
VD>Дык ты это и предлагаешь. Причем думаешь, что если спрятать изменяемый индексируемый список за интерфейсом, то это решит проблему. Не решит. Ты конечно получишь гипотетический бенефит от того, что сможешь сменить реализацию коллекции не трогая другого кода. Но плюешь на куда более серьезную проблему размазывания императивного алгоритма по разным методам. Императив нужно инкапсулирвоать.
А кто тебе сказал что есть какое-либо размазывание?
VD>И кстати, если бы ты передавал именно IMutableList, то по сигнатуре метода уже можно было бы понять, что он будет менять этот список, а значит с данным методом нужно быть как можно акуратнее. А так ты передаешь IList и в те методы что просто нуждаются в списке, и в те, что собираются его изменять. Это явное использование абстракции на вред себе любимому. Это ничем не отличается от передачи IMutableList методу который не собирается менять данные.
Это весьма и весьма надуманная проблема. Метод Append меняет коллекцию, метод Print — нет. Смотреть в его параметры не обязательно. И ты ктати не упрощай, ты сейчас про IAddRemoveMutableList говорил или про IModifyMutableList?
VD>Дык и неизменяемыми структурами данных можно обмениваться без проблем. В конце концов любое изменение можно рассматривать как удаление старого объекта и вставку нового. Так что на входе имеем список с исходными объектами, на выходе новый где часть объектов старые, а часть новые (ставленные или замененные). При этом очень легко сделать между ними diff и получить третий список содержащий только изменения.
Ага, то есть стоимость изменения одного элемента массива — O(N). А потом говорят что .Net тормозит.
VD>Потом на ГУИ свет клином не сошелся. ГУЯ не так много в серьезных задачах. Обработка данных обычно занимает куда больше места и времени (программиста). И тут вопросы биндига уже не будут актуальны.
Ну не GUI, так службы. Я и не гвоорил только про GUI.
Здравствуйте, adontz, Вы писали:
A>Ты умудрился чудесно переврать мои слова. Давай ты попытаешься прочесть это предложение ещё раз — "Коллекция не всегда создаётся и заполняется в рамках одного метода".
И? Не, ну, я понимаю если твоя коллекция является состоянием некого объекта. Тогда она будет полем и тогда ее и передавать то никуда не надо будет. Хотя и тут я бы не стал заполнять ее во многих местах. Но зачем коллекции через параметры то передавать?
VD>>Какие прыжки? Изначально мы говорили о том, что интерфейсы коллекций в дотнете криво спроектированы. Ты дал ссылку на кошерное обоснование того, что интерфейсы должны быть маленькими и специализированными, а не толстыми и всеобъемлющими.
A>Вообще-то там ничего не говориться о больших или маленьких интерфейсах. Размер в ISP вообще не цель и характеристика.
Это вот от туда:
The ISP says that once an interface has gotten too 'fat' it needs to be split into smaller and more specific interfaces so that any clients of the interface will only know about the methods that pertain to them. In a nutshell, no client should be forced to depend on methods it does not use.
и это тоже:
Martin Fowler's name for smaller interfaces which only include the needed methods is 'Role Interface'.
или вот еще краткое определение: the notion that “many client specific interfaces are better than one general purpose interface
A>Речь там идёт о минимально необходимом интерфейсе.
Там речь о самих интерфейсах. Лучше иметь больше специализированных интерфейсов нежели один общего назначения.
Это как раз о том, что лучше иметь IImutableList и IMutableList нежели один общий IList.
VD>>А вот про конкретные типы я там ничего не углядел.
A>Не воспринимай слово интерфейс слишком узко. Там не про ключевое слово языка C# говорится.
Да я как раз его то воспринимаю совершенно адекватно. А вот ты явно понимаешь этот самый ISP как-то односторонне.
VD>>Ты наверно перепутал этот принцип с простой идеей, что возвращать конекртные изменяемые коллекции из методов не кошерно. С этим я в общем-то согласен. Хотя тоже не вижу в этом ничего плохого, если возвращается копия.
A>Никакой путаницы нет, твоя простая идея есть элементарный вывод из существования ISP. Копирование и уточнение типа перпендикулярны.
Что-то я совсем запутался в твой геометрии. Что кому перпендикулярно, а что параллельно?
VD>>Дык ты это и предлагаешь. Причем думаешь, что если спрятать изменяемый индексируемый список за интерфейсом, то это решит проблему. Не решит. Ты конечно получишь гипотетический бенефит от того, что сможешь сменить реализацию коллекции не трогая другого кода. Но плюешь на куда более серьезную проблему размазывания императивного алгоритма по разным методам. Императив нужно инкапсулирвоать.
A>А кто тебе сказал что есть какое-либо размазывание?
Ты же вроде бы коллекции между методами передавать предлагал. Нет?
VD>>И кстати, если бы ты передавал именно IMutableList, то по сигнатуре метода уже можно было бы понять, что он будет менять этот список, а значит с данным методом нужно быть как можно акуратнее. А так ты передаешь IList и в те методы что просто нуждаются в списке, и в те, что собираются его изменять. Это явное использование абстракции на вред себе любимому. Это ничем не отличается от передачи IMutableList методу который не собирается менять данные.
A>Это весьма и весьма надуманная проблема.
Ну, как знаешь. Приведенный тобой же пницип ISP как раз говорит, что в интерфейсе не должно быть не используемых методов.
A>Метод Append меняет коллекцию, метод Print — нет.
А вот это уже твое вооражение. Сколько раз я видел когда очевидные (казалось бы) предположения не подтверждались на практике. Твой ISP как раз говорит о том, что теорию лучше подкреплять железными мерами.
A>Смотреть в его параметры не обязательно.
Дык если все сделано по-человечески то и смотреть не надо будет. Если метод возвратил неизменяемый интерфейс, то можно быть уверенным, что никто его не попытается менять.
A>И ты ктати не упрощай, ты сейчас про IAddRemoveMutableList говорил или про IModifyMutableList?
Это какой-то странный выбор меду бредом и делириумом.
A>Ага, то есть стоимость изменения одного элемента массива — O(N). А потом говорят что .Net тормозит.
О! А вот и преждевременные оптимизации.
Кстати о них родных и за одно о парсере. Сегодня Ziaw опубликовал
свои тесты по которым выходит, что написанный на нашем PegGrammar за пару часов парсер джейсона оказался в полтора раза быстрее Json.NET в котором парсер джейсона написан на шарпе вручную. При этом наш парсер как не парадоксально написан в функциональном стиле (т.е., по-твоему, тормозно). Я уже не говорю о том, что их парсер — это тысяча с гаком строк код кода, в то время как немерловый описывается декларативной грамматикой.
A>Ну не GUI, так службы. Я и не гвоорил только про GUI.
Что за службы такие которым нужен биндинг?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это вот от туда: VD>The ISP says that once an interface has gotten too 'fat' it needs to be split into smaller and more specific interfaces so that any clients of the interface will only know about the methods that pertain to them. In a nutshell, no client should be forced to depend on methods it does not use. VD>и это тоже: VD>Martin Fowler's name for smaller interfaces which only include the needed methods is 'Role Interface'. VD>или вот еще краткое определение: VD>the notion that “many client specific interfaces are better than one general purpose interface A>>Речь там идёт о минимально необходимом интерфейсе. VD>Там речь о самих интерфейсах. Лучше иметь больше специализированных интерфейсов нежели один общего назначения.
Видимо прочесть "so that any clients of the interface will only know about the methods that pertain to them" ты не удосужился.
VD>Это как раз о том, что лучше иметь IImutableList и IMutableList нежели один общий IList.
Если есть клиенты требующие один из этих интерфейсов без другого, то да. Разделение не самоцель. Не путай ISP с SRP.
A>>Никакой путаницы нет, твоя простая идея есть элементарный вывод из существования ISP. Копирование и уточнение типа перпендикулярны. VD>Что-то я совсем запутался в твой геометрии. Что кому перпендикулярно, а что параллельно?
Для того чтобы передать копию данных нет необходимости явно предавать какой-то конкретный класс вместо интерфейса. Твоё желание пользоваться классами при изменении данных никак не может быть аргументировано необходимостью копирования.
A>>А кто тебе сказал что есть какое-либо размазывание? VD>Ты же вроде бы коллекции между методами передавать предлагал. Нет?
И что? Я обработал данные в одном месте, передал в другое, там тоже обработал, передал в третье... эти обработки могут быть совершенно не связаны, даже не знать друг о друге, даже не быть строго последовательными. Никакого размазывания логики тут нет. Много разных логик, общие данные.
A>>Это весьма и весьма надуманная проблема. VD>Ну, как знаешь. Приведенный тобой же пницип ISP как раз говорит, что в интерфейсе не должно быть не используемых методов.
Не примешивай ISP к вопросам семантики.
A>>Метод Append меняет коллекцию, метод Print — нет.
VD>Сколько раз я видел когда очевидные (казалось бы) предположения не подтверждались на практике.
Тоже самое можно сказать и о твоих словах. Тем не менее, по выразительности английский язык лучше иерархии интерфейсов. Кроме того, операции и данные не взаимно однозначны. И вообще, если твой подход работает, то почему нет константных аргументов как в Си++?
A>>И ты ктати не упрощай, ты сейчас про IAddRemoveMutableList говорил или про IModifyMutableList? VD>Это какой-то странный выбор меду бредом и делириумом.
О нет, это светлое будущее к которому ты призываешь!
A>>Ага, то есть стоимость изменения одного элемента массива — O(N). А потом говорят что .Net тормозит. VD>О! А вот и преждевременные оптимизации. VD>Кстати о них родных и за одно о парсере. Сегодня Ziaw опубликовал
свои тесты по которым выходит, что написанный на нашем PegGrammar за пару часов парсер джейсона оказался в полтора раза быстрее Json.NET в котором парсер джейсона написан на шарпе вручную. При этом наш парсер как не парадоксально написан в функциональном стиле (т.е., по-твоему, тормозно). Я уже не говорю о том, что их парсер — это тысяча с гаком строк код кода, в то время как немерловый описывается декларативной грамматикой.
А вообще к чему этот аргумент если AST — это дерево, элементы которого не модифицируются, а мы говорим про массив элементы которого модифицируются? Не, я рад что вы научились быстро разбирать Json, но какое это вообще имеет отношение к теме разговора?
A>>Ну не GUI, так службы. Я и не гвоорил только про GUI. VD>Что за службы такие которым нужен биндинг?
Observable Collections. На оповещения могут подписываться не только ЭУ.
