Hello, !
You wrote on Wed, 16 Jun 2004 10:03:45 GMT:
M>> А если вы решите переходить на другую реализацию Map, кто потом будет M>> править твои HashMap повсеместно??? > Править придется в любом случае, HashMap создается явно, а не > вытаскивается из какого-нибудь factory и в этом случае я хочу видеть > объект такой, какой он есть, а не прикрытый всякими интерфейсами.
Угу, и разницы, в одном месте править, или в 10, ты тоже не видишь
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[11]: хотите развею мифы о работе в Microsoft, Redmond WA
Здравствуйте, mikkri, Вы писали:
M>И правильно делают. Такой код — в жесткий рефакторинг.
довольно категорично , но, на мой взгляд, не совсем резонно.
M>А если вы решите переходить на другую реализацию Map, кто потом будет править твои HashMap повсеместно???
а подобный подход вообще не подразумевает перехода на другую реализацию Map, потому как если в проекте существует переход на другую реализацию какого-либо интерфейса, то создается фабрика.
M>Одно дело поменять в нескольких местах создание нового Map, совсем другое дело поменять повсеместно, где они используются. Собственно, советую подумать на причинами, по которым существуюет интерфейс Map. Надеюсь, тебе самому тогда станет понятно, что ты не прав.
а чем одно дело отличается от другого? и что нужно менять повсеместно, где используются? если я произвожу вызовы только методов интерфейса Map, а сам интерфейс не изменяется, то замена производится только в месте создания. если есть вызовы, специфические для HashMap (ну надо мне , то ни о каком переходе на новую реализацию Map не может быть и речи. если изменятся интерфейс Map, то все по-любому накрывается медным тазом.
и как на счет того, чтобы подумать над причинами, по которым класс HashMap является публичным? а над причинами существования интерфейса Map нужно думать не его пользователю, а его создателю и проектировщику. если реализация какого либо интерфейса будет изменятся, то его пользователь (напр., прикладной программист) ничего не должен знать об этом, равно как и о том, какие реализации вообще существуют.
Re[19]: хотите развею мифы о работе в Microsoft, Redmond WA
Здравствуйте, Larm, Вы писали:
A>>Потому что они вызывают методы, объявленные в HashMap.
L>Так вопрос и стоит: какие функции принимают HashMap? Только те, которые используют его специфические функции, иначе это кривость интерфейса. Какие это специфические функции и где используются? Пример в студию, а то пустое обсуждение получается.
Ну откуда я знаю, какие функции принимают HashMap? Мы же, надеюсь, обсуждаем проблему в общем, а не конкретный пример с HashMap?
Здравствуйте, Аноним, Вы писали:
А>Когда мне говорят, что вместо А>
А>HashMap myMap = new HashMap();
А>
А>надо писать А>
А>Map myMap = new HashMap();
А>
А>и при этом начинают прикрываться ОО-принципами, я это воспринимаю как придирку.
Смотря где. Эсли это некая наследуемая вещь, то возможно имеет смысл. Если это в private секции а тем более в процедуре что то локальное то руки прочь...
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Re[12]: хотите развею мифы о работе в Microsoft, Redmond WA
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Аноним, Вы писали:
А>>Если это java А>Да
А>>Map определяет интерфейс для любых других "мапов", А>Да
А>>то замечание в общем-то справедливо. А>Вот это весьма сомнительно. А>А как ты отнесешься к А>
А>IDictionary myMap = new Hashtable();
А>
А>(C#), выглядит уже не так красиво.
Дело не в красивости.
В случае
Map map = new HashMap();
можно заменить HashMap на любой производный от Map класс. Например на TreeMap, если для объектов в контейнере стало сложно строить хэш-функцию.
А в твоём первоначальном примере это будет сделать не так просто. Особенно если и в остальных случаях ты используешь HashMap вместо Map.
Так что это не придирка а вполне уместное замечание.
То же самое и для C#.
Никогда не задумывался, зачем тим лиду нужны эти "придирки"?
Здравствуйте, Аноним, Вы писали:
А>А чтобы этого не было, нужна база для таких ревью — стандарты кодирования.
Это понятно, вопрос в объеме. Когда это превращается в бесконечный набор писаных и неписаных правил, становится тяжело.
А>Но в целом, я не знаю, что ты понимаешь под придирками к коду.
Когда мне говорят, что вместо
HashMap myMap = new HashMap();
надо писать
Map myMap = new HashMap();
и при этом начинают прикрываться ОО-принципами, я это воспринимаю как придирку.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Аноним, Вы писали:
А>>А чтобы этого не было, нужна база для таких ревью — стандарты кодирования.
А>Это понятно, вопрос в объеме. Когда это превращается в бесконечный набор писаных и неписаных правил, становится тяжело.
Согласен.
А>>Но в целом, я не знаю, что ты понимаешь под придирками к коду.
А>Когда мне говорят, что вместо А>
А>HashMap myMap = new HashMap();
А>
А>надо писать А>
А>Map myMap = new HashMap();
А>
А>и при этом начинают прикрываться ОО-принципами, я это воспринимаю как придирку.
Если это java (судя по тегам), то я в ней профан.
Но если Map определяет интерфейс для любых других "мапов",
то замечание в общем-то справедливо.
Re[10]: хотите развею мифы о работе в Microsoft, Redmond WA
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Аноним, Вы писали:
А>>А чтобы этого не было, нужна база для таких ревью — стандарты кодирования.
А>Это понятно, вопрос в объеме. Когда это превращается в бесконечный набор писаных и неписаных правил, становится тяжело.
А>>Но в целом, я не знаю, что ты понимаешь под придирками к коду.
А>Когда мне говорят, что вместо А>
А>HashMap myMap = new HashMap();
А>
А>надо писать А>
А>Map myMap = new HashMap();
А>
А>и при этом начинают прикрываться ОО-принципами, я это воспринимаю как придирку.
И правильно делают. Такой код — в жесткий рефакторинг.
А если вы решите переходить на другую реализацию Map, кто потом будет править твои HashMap повсеместно???
Одно дело поменять в нескольких местах создание нового Map, совсем другое дело поменять повсеместно, где они используются. Собственно, советую подумать на причинами, по которым существуюет интерфейс Map. Надеюсь, тебе самому тогда станет понятно, что ты не прав.
Re[13]: хотите развею мифы о работе в Microsoft, Redmond WA
Здравствуйте, postmaster, Вы писали:
P>Никогда не задумывался, зачем тим лиду нужны эти "придирки"?
В общем лиду надо еще уметь объяснять.
То как замечания высказываются — это тоже очень важно.
"Напрягаться" и пытаться понять друг друга надо обоим, и лиду и девелоперу.
Re[13]: хотите развею мифы о работе в Microsoft, Redmond WA
P>можно заменить HashMap на любой производный от Map класс. Например на TreeMap, если для объектов в контейнере стало сложно строить хэш-функцию. P>А в твоём первоначальном примере это будет сделать не так просто. Особенно если и в остальных случаях ты используешь HashMap вместо Map.
То есть идеально видимо object map = new HashMap();
?
Re[14]: хотите развею мифы о работе в Microsoft, Redmond WA
Здравствуйте, <Аноним>, Вы писали:
А>То есть идеально видимо object map = new HashMap();
нет. идеально так, как этот объект используется.
например у интерфейса Map есть методы A1, A2, A3.
HashMap реализует эти методы плюс имеет собственный A4
если в твоем случае созданный объект myMap использует базовые методы A1 — A3, то объявлять 100% надо как Map();
если A4 — то возможно резонно объявить и как A4, но это зависит от ситуации.
... << RSDN@Home 1.1.3 stable >>
Re[14]: хотите развею мифы о работе в Microsoft, Redmond WA
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, postmaster, Вы писали:
P>>В случае P>>
P>>Map map = new HashMap();
P>>
P>>можно заменить HashMap на любой производный от Map класс. А>Заменить на TreeMap можно будет без проблем в любом случае, это ведь локальная переменная, я еще понимаю если это параметр метода. А если мне понадобится какой-нибудь метод, который есть в HashMap, но нет в интерфейсе?
Ты же не написал, что это локальная переменная. Может это поле класса?
А так аккуратным нужно быть во всем — тебе же потом будет проще.
Re[15]: хотите развею мифы о работе в Microsoft, Redmond WA
Здравствуйте, mogadanez, Вы писали:
M>если в твоем случае созданный объект myMap использует базовые методы A1 — A3, то объявлять 100% надо как Map(); M>если A4 — то возможно резонно объявить и как A4, но это зависит от ситуации.
Нет, я вообще перестал что-то понимать в этом мире. Если объект является экземпляром класса A4 и кроме этого еще и использует специфический для A4 интерфейс, то его возможно резонно объявить как А4, да к тому же и "зависит от ситуации"?
Re[15]: хотите развею мифы о работе в Microsoft, Redmond WA
M>например у интерфейса Map есть методы A1, A2, A3. M>HashMap реализует эти методы плюс имеет собственный A4
M>если в твоем случае созданный объект myMap использует базовые методы A1 — A3, то объявлять 100% надо как Map();
С этим я тоже не согласен. Даже не то что не согласен насчет 100% (ну это совсем очевидно), но я бы сказал, что "в большинстве случаев имеет смысл объявлять как HashMap". Имплементация базовых методов может отличаться и я не хочу вводить в заблуждение и себя и людей, которые будут читать этот код впоследствии. Поменяется класс — компилятор крикнет и я поменяю код создания экземпляра (что тебе тоже придётся делать), вот и всё...
Re[16]: хотите развею мифы о работе в Microsoft, Redmond WA
Здравствуйте, Sergey, Вы писали:
S>И что же в ней вредного, если не секрет? Использовать следует минимально S>достаточный интерфейс, поэтому если этот код компилируется после замены S>HashMap на Map, то не придирка это, а вполне разумное требование.
И в чем же смысл этого требования? Минусы вижу, а плюсы нет.
Правило очень простое — принимать в качестве параметра метода надо минимально достаточный интерфейс, а объявлять надо "честный" класс.
Здравствуйте, Sergey, Вы писали:
A>> И в чем же смысл этого требования?
S>Смысл очень простой — во-первых, компилятор будет напоминать, если кто-то S>решит использовать специфичные для HashMap методы.
Ага, обычно это происходит так — компилятор напоминает, человек идёт на строчку,
где объявлен объект, думает "какой дурак так написал" и меняет тип на HashMap.
И что плохого в использовании методов HashMap???
S>Во-вторых, облегчается S>дальнейшее сопровождение этого кода — не придется гадать, что там на самом S>деле требуется — действительно нужен HashMap или достаточно использовать S>более общий Map.
Зачем гадать, если видно, что объект типа HashMap? Гадать, как раз, приходится
в случае "Map m = new HashMap()".
A>> Минусы вижу, а плюсы нет. S>Ну и в чем же минусы?
1) Непонятно, метод какого класса будет вызван — _нежелательный_ полиморфизм. Зачем
добавлять себе сложности, с которыми впоследствии придётся бороться?
Да и кроме того, это просто опасно — вдруг кто-то впоследствии добавит "map = MyBuggyMap()",
хотя, по замыслу автора, там _всегда_ должен был быть HashMap.
2) Зачем всегда ограничивать себя в использовании возможностей суперкласса? Бесспорно,
иногда это имеет право на существование, о чем я уже раньше говорил — например, если
предполагается, что этот класс будет полностью переписан, а останется только интерфейс.
Но принимать это правило (100%, как кто-то выше написал) в качестве догмы мне кажется
глупостью и псевдо-объектно-ориентированным подходом.
A>> Правило очень простое — принимать в качестве параметра метода надо A>> минимально достаточный интерфейс, а объявлять надо "честный" класс.
S>Да, через год, когда в этот код срочно надо будет добавить пару новых фич, S>причем заниматься этим будет человек, первый раз видящий этот код, он, S>несомненно, легко догадается, что там достаточно Map, а не HashMap И в S>параметры методов, которые он напишет, пойдет тоже Map, как минимально S>достаточный
Ему не нужно это угадывать, написано же — HashMap hm = new HashMap, куда уж проще?
И что будет ему мешать принимать в кач-ве параметров Map?
Да и практика моя показывает, что никаких проблем с этим не бывает — а у нас громадная библиотека,
написанная на С++ и C# за последние 10 лет. Хотя опыт, конечно, дело субъективное...
Re[11]: хотите развею мифы о работе в Microsoft, Redmond WA
От:
Аноним
Дата:
16.06.04 08:15
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Если это java
Да
А>Map определяет интерфейс для любых других "мапов",
Да
А>то замечание в общем-то справедливо.
Вот это весьма сомнительно.
А как ты отнесешься к
IDictionary myMap = new Hashtable();
(C#), выглядит уже не так красиво.
Re[13]: хотите развею мифы о работе в Microsoft, Redmond WA
От:
Аноним
Дата:
16.06.04 09:54
Оценка:
Здравствуйте, postmaster, Вы писали:
P>В случае P>
P>Map map = new HashMap();
P>
P>можно заменить HashMap на любой производный от Map класс.
Заменить на TreeMap можно будет без проблем в любом случае, это ведь локальная переменная, я еще понимаю если это параметр метода. А если мне понадобится какой-нибудь метод, который есть в HashMap, но нет в интерфейсе?
Re[11]: хотите развею мифы о работе в Microsoft, Redmond WA
От:
Аноним
Дата:
16.06.04 10:03
Оценка:
Здравствуйте, mikkri, Вы писали:
M>А если вы решите переходить на другую реализацию Map, кто потом будет править твои HashMap повсеместно???
Править придется в любом случае, HashMap создается явно, а не вытаскивается из какого-нибудь factory и в этом случае я хочу видеть объект такой, какой он есть, а не прикрытый всякими интерфейсами.
Здравствуйте, Sergey, Вы писали:
S>Угу, и разницы, в одном месте править, или в 10, ты тоже не видишь
Всё равно в 10 местах править придётся, ведь никакой фабрики нет
К тому же, не нужно опасным образом (даункастинг) приводить тип при передаче этого объекта в методы, принимающие HashMap. Вот здесь, действительно, компилятор уже не поможет при смене реального типа.
Собственно, я вообще считаю эту практику вредной. Не обижайтесь, но я часто это вижу у людей, недавно освоивших ООП и пытающихся впихнуть псевдо-объектно-ориентированный код в каждую строчку.
Re[14]: хотите развею мифы о работе в Microsoft, Redmond WA
Здравствуйте, Andy77, Вы писали:
A>Собственно, я вообще считаю эту практику вредной. Не обижайтесь, но я часто это вижу у людей, недавно освоивших ООП и пытающихся впихнуть псевдо-объектно-ориентированный код в каждую строчку.
Кстати если посмотреть как написан к примеру Tomcat, то там используется стиль ArrayList list = new ArrayList(); С другой стороны в Eclipse соглашения нет, используется оба стиля, так что ценность такого code review ничтожная, а лично для меня так и вовсе отрицательная.
Re[14]: хотите развею мифы о работе в Microsoft, Redmond WA
Hello, Andy77!
You wrote on Wed, 16 Jun 2004 16:41:13 GMT:
S>> Угу, и разницы, в одном месте править, или в 10, ты тоже не видишь
A> Всё равно в 10 местах править придётся, ведь никакой фабрики нет
В 2 — если писать HashMap myMap = new HashMap(); или в 1 — если писать Map
myMap = new HashMap();. Или в 10, если использовать специфичные для HashMap
методы.
A> К тому же, не нужно опасным образом (даункастинг) приводить тип при A> передаче этого объекта в методы, принимающие HashMap. Вот здесь, A> действительно, компилятор уже не поможет при смене реального типа.
Если там есть методы, требующие HashMap, тогда никакого разговора — писать
надо HashMap myMap. Если эти методы требуют на самом деле всего лишь Map, а
объявлены как требующие HashMap — тогда методы тоже надо переписать. Сразу,
как только это выяснилось.
A> Собственно, я вообще считаю эту практику вредной.
Какую конкретно практику?
A> Не обижайтесь, но я часто это вижу у людей, недавно освоивших ООП и A> пытающихся впихнуть псевдо-объектно-ориентированный код в каждую A> строчку.
Здравствуйте, Andy77, Вы писали:
A>Здравствуйте, Sergey, Вы писали:
S>>Угу, и разницы, в одном месте править, или в 10, ты тоже не видишь
A>Всё равно в 10 местах править придётся, ведь никакой фабрики нет
Нет.
Ты этот объект в 10-ти местах создаёшь? 10 раз написав "new HashMap()"?
Если да, то у тебя явные проблемы с качеством кодирования.
Если нет, то менять надо будет ровно в одном месте.
A>К тому же, не нужно опасным образом (даункастинг) приводить тип при передаче этого объекта в методы, принимающие HashMap. Вот здесь, действительно, компилятор уже не поможет при смене реального типа.
И TreeMap и HashMap реализуют интерфейс Map. Какие проблемы?
A>Собственно, я вообще считаю эту практику вредной. Не обижайтесь, но я часто это вижу у людей, недавно освоивших ООП и пытающихся впихнуть псевдо-объектно-ориентированный код в каждую строчку.
Ответь пожалуйста на вопрос: тебе нужен некий абстрактный Map, или тебе нужен конкретный HashMap?
Если тебе нужен именно HashMap, то позволь полюбопыствовать: какие методы, специфичные для HashMap, ты используешь?
Re[15]: хотите развею мифы о работе в Microsoft, Redmond WA
Здравствуйте, Sergey, Вы писали:
A>> Всё равно в 10 местах править придётся, ведь никакой фабрики нет
S>В 2 — если писать HashMap myMap = new HashMap(); или в 1 — если писать Map S>myMap = new HashMap();. Или в 10, если использовать специфичные для HashMap S>методы.
В общем, разницы никакой не вижу — исправить с
HashMap map = new HashMap
или
Map map = new HashMap
на
(Super)Map map = new SuperMap
Re[15]: хотите развею мифы о работе в Microsoft, Redmond WA
Здравствуйте, postmaster, Вы писали:
A>>К тому же, не нужно опасным образом (даункастинг) приводить тип при передаче этого объекта в методы, принимающие HashMap. Вот здесь, действительно, компилятор уже не поможет при смене реального типа.
P>И TreeMap и HashMap реализуют интерфейс Map. Какие проблемы?
Я же написал — "при передаче этого объекта в методы, принимающие HashMap"
Re[16]: хотите развею мифы о работе в Microsoft, Redmond WA
Hello, Andy77!
You wrote on Thu, 17 Jun 2004 14:49:20 GMT:
A>>> Собственно, я вообще считаю эту практику вредной.
S>> Какую конкретно практику?
A> То, что мы обсуждаем. A> Map map = new HashMap();
И что же в ней вредного, если не секрет? Использовать следует минимально
достаточный интерфейс, поэтому если этот код компилируется после замены
HashMap на Map, то не придирка это, а вполне разумное требование.
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[17]: хотите развею мифы о работе в Microsoft, Redmond WA
Hello, Andy77!
You wrote on Thu, 17 Jun 2004 15:40:05 GMT:
S>> И что же в ней вредного, если не секрет? Использовать следует S>> минимально достаточный интерфейс, поэтому если этот код компилируется S>> после замены HashMap на Map, то не придирка это, а вполне разумное S>> требование.
A> И в чем же смысл этого требования?
Смысл очень простой — во-первых, компилятор будет напоминать, если кто-то
решит использовать специфичные для HashMap методы. Во-вторых, облегчается
дальнейшее сопровождение этого кода — не придется гадать, что там на самом
деле требуется — действительно нужен HashMap или достаточно использовать
более общий Map.
A> Минусы вижу, а плюсы нет.
Ну и в чем же минусы?
A> Правило очень простое — принимать в качестве параметра метода надо A> минимально достаточный интерфейс, а объявлять надо "честный" класс.
Да, через год, когда в этот код срочно надо будет добавить пару новых фич,
причем заниматься этим будет человек, первый раз видящий этот код, он,
несомненно, легко догадается, что там достаточно Map, а не HashMap И в
параметры методов, которые он напишет, пойдет тоже Map, как минимально
достаточный
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[18]: хотите развею мифы о работе в Microsoft, Redmond WA
Здравствуйте, Andy77, Вы писали:
DG>>А зачем такие функции принимают HashMap? почему не Map?
A>Потому что они вызывают методы, объявленные в HashMap.
Так вопрос и стоит: какие функции принимают HashMap? Только те, которые используют его специфические функции, иначе это кривость интерфейса. Какие это специфические функции и где используются? Пример в студию, а то пустое обсуждение получается.
Hello, Andy77!
You wrote on Fri, 18 Jun 2004 16:24:49 GMT:
A> Ага, обычно это происходит так — компилятор напоминает, человек идёт на A> строчку, где объявлен объект, думает "какой дурак так написал" и меняет A> тип на HashMap.
Если в таком случае он думает "какой дурак так написал", то он сам дурак.
По-хорошему он должен прикинуть, что ему дает жесткая зависимость от HashMap
и стоит ли она отказа от общности.
A> И что плохого в использовании методов HashMap???
То, что завтра тебе может другой Map понадибитсья.
S>> Во-вторых, облегчается S>> дальнейшее A> сопровождение этого кода — не придется гадать, что там на S>> самом деле A> требуется — действительно нужен HashMap или достаточно S>> использовать A> более общий Map.
A> Зачем гадать, если видно, что объект типа HashMap? A> Гадать, как раз, A> приходится в случае "Map m = new HashMap()".
Не, не приходится. Все и так ясно — там может быть любой Map.
A>>> Минусы вижу, A> а плюсы нет. S>> Ну и в чем же минусы?
A> 1) Непонятно, метод какого A> класса будет вызван — _нежелательный_ полиморфизм.
Ну и чем же он нежелателен?
A> Зачем добавлять себе сложности, с которыми впоследствии A> придётся бороться?
Да нет здесь никаких сложностей.
A> Да и кроме того, это просто опасно — вдруг кто-то A> впоследствии добавит "map = MyBuggyMap()",
Именно для того, чтобы впоследствии можно было так написать, и следует
писать Map, а не HashMap.
A> хотя, по замыслу автора, там _всегда_ должен был быть A> HashMap.
Если бы автор мог обосновать, почему там должен быть HashMap, вопроса о
придирках бы не возникло
A> 2) Зачем всегда ограничивать себя в использовании возможностей A> суперкласса? Бесспорно, иногда это имеет право на существование, о чем я A> уже раньше говорил — например, если предполагается, что этот класс будет A> полностью переписан, а останется только интерфейс.
Это должно предполагаться по дефолту. Потому что как в дальнейшем будет
меняться код, никому не известно. Если есть возможность совершенно бесплатно
подложить соломки — то и надо ее подкладывать.
A> Но принимать это A> правило (100%, как кто-то выше написал) в качестве догмы мне кажется A> глупостью и псевдо-объектно-ориентированным подходом.
Ну а мне глупостью кажется надеятся на то, что код не будет меняться.
Итого, аргументов у тебя нет — только кажущийся нежелательным полиморфизм и
ощущение того, что пользоваться лишь достаточным минимумом возможностей —
глупость
S>> Да, через год, когда в этот код срочно надо будет добавить пару новых S>> фич, причем заниматься этим будет человек, первый раз видящий этот код, S>> он, несомненно, легко догадается, что там достаточно Map, а не HashMap S>> И в параметры методов, которые он напишет, пойдет тоже Map, как S>> минимально достаточный
A> Ему не нужно это угадывать, написано же — HashMap hm = new HashMap, куда A> уж проще?
Отсюда не следует, что там используется только интерфейс Map, хотя на самом
деле это так (в противном случае подобных "придирок" просто бы не было).
A> И что будет ему мешать принимать в кач-ве параметров Map?
Да ничего не помешает, если он напишет Map, а не HashMap. Только вот никто
не узнает, что там достаточен Map, если написать, как ты предлагаешь. А
разбираться обычно ни у кого нет ни времени, ни желания.
A> Да и практика моя показывает, что никаких проблем с этим не бывает — а у A> нас громадная библиотека, написанная на С++ и C# за последние 10 лет.
Потому к твоему коду и придираются, что не хотят развалить библиотеку
A> Хотя опыт, конечно, дело субъективное...
Вряд ли.
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[21]: хотите развею мифы о работе в Microsoft, Redmond WA
Hello, Andy77!
You wrote on Mon, 21 Jun 2004 16:04:18 GMT:
A> К моему коду никто не придирается, собственно, одна из моих функций на A> работе — составление Coding Guidelines
Значит, еще 10 лет ваша библиотека не протянет
With best regards, Sergey.
Posted via RSDN NNTP Server 1.9 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Аноним, Вы писали:
А>>А чтобы этого не было, нужна база для таких ревью — стандарты кодирования. А>Это понятно, вопрос в объеме. Когда это превращается в бесконечный набор писаных и неписаных правил, становится тяжело. А>>Но в целом, я не знаю, что ты понимаешь под придирками к коду.
А>Когда мне говорят, что вместо А>
А>HashMap myMap = new HashMap();
А>
А>надо писать А>
А>Map myMap = new HashMap();
А>
А>и при этом начинают прикрываться ОО-принципами, я это воспринимаю как придирку.
Я еще один контрпример придумал.
Пусть есть метод public Object convertMap(HashMap map);
Пусть у меня есть HashMap myMap;
Так вот, если я хочу защитить свой myMap от нежелательных изменений в методе convertMap (по идее, он не должен менять map, но кто знает, ведь это сторонний код), то я вызываю его как convertMap(Collections.unmodifiableMap(myMap));
Но что я получаю? Не возможность привести типы!!!
Так что Object convertMap(Map map) rulezz!
Re[19]: хотите развею мифы о работе в Microsoft, Redmond WA
Здравствуйте, Larm, Вы писали:
L>Так вопрос и стоит: какие функции принимают HashMap? Только те, которые используют его специфические функции, иначе это кривость интерфейса. Какие это специфические функции и где используются? Пример в студию, а то пустое обсуждение получается.
а какая разница, какие функции? и при чем здесь кривость интерфейса? на основании чего в функцию нельзя передавать тип суперкласса?
пример:
у интерфейса I1 есть методы M1 и M2;
у класса, реализующего интерфейс, есть доп. метод M3.
мне нужно написать кусок кода (бАльшой), который использует серию вызовов метода M3 и оформить его в виде функции. есть ли в таком подходе какая-либо кривость?
, то ни о каком переходе на новую реализацию Map не может быть и речи. если изменятся интерфейс Map, то все по-любому накрывается медным тазом.
