Здравствуйте, 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
Здравствуйте, Sergey, Вы писали:
S>И что же в ней вредного, если не секрет? Использовать следует минимально S>достаточный интерфейс, поэтому если этот код компилируется после замены S>HashMap на Map, то не придирка это, а вполне разумное требование.
И в чем же смысл этого требования? Минусы вижу, а плюсы нет.
Правило очень простое — принимать в качестве параметра метода надо минимально достаточный интерфейс, а объявлять надо "честный" класс.
Re[18]: хотите развею мифы о работе в 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? Только те, которые используют его специфические функции, иначе это кривость интерфейса. Какие это специфические функции и где используются? Пример в студию, а то пустое обсуждение получается.
The God who walks is among us...
Re[19]: хотите развею мифы о работе в Microsoft, Redmond WA
Здравствуйте, Larm, Вы писали:
A>>Потому что они вызывают методы, объявленные в HashMap.
L>Так вопрос и стоит: какие функции принимают HashMap? Только те, которые используют его специфические функции, иначе это кривость интерфейса. Какие это специфические функции и где используются? Пример в студию, а то пустое обсуждение получается.
Ну откуда я знаю, какие функции принимают HashMap? Мы же, надеюсь, обсуждаем проблему в общем, а не конкретный пример с HashMap?
Здравствуйте, 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 лет. Хотя опыт, конечно, дело субъективное...
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!
Здравствуйте, Аноним, Вы писали:
А>Когда мне говорят, что вместо А>
А>HashMap myMap = new HashMap();
А>
А>надо писать А>
А>Map myMap = new HashMap();
А>
А>и при этом начинают прикрываться ОО-принципами, я это воспринимаю как придирку.
Смотря где. Эсли это некая наследуемая вещь, то возможно имеет смысл. Если это в private секции а тем более в процедуре что то локальное то руки прочь...
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Re[19]: хотите развею мифы о работе в Microsoft, Redmond WA
Здравствуйте, Larm, Вы писали:
L>Так вопрос и стоит: какие функции принимают HashMap? Только те, которые используют его специфические функции, иначе это кривость интерфейса. Какие это специфические функции и где используются? Пример в студию, а то пустое обсуждение получается.
а какая разница, какие функции? и при чем здесь кривость интерфейса? на основании чего в функцию нельзя передавать тип суперкласса?
пример:
у интерфейса I1 есть методы M1 и M2;
у класса, реализующего интерфейс, есть доп. метод M3.
мне нужно написать кусок кода (бАльшой), который использует серию вызовов метода M3 и оформить его в виде функции. есть ли в таком подходе какая-либо кривость?
Re[11]: хотите развею мифы о работе в Microsoft, Redmond WA
Здравствуйте, mikkri, Вы писали:
M>И правильно делают. Такой код — в жесткий рефакторинг.
довольно категорично , но, на мой взгляд, не совсем резонно.
M>А если вы решите переходить на другую реализацию Map, кто потом будет править твои HashMap повсеместно???
а подобный подход вообще не подразумевает перехода на другую реализацию Map, потому как если в проекте существует переход на другую реализацию какого-либо интерфейса, то создается фабрика.
M>Одно дело поменять в нескольких местах создание нового Map, совсем другое дело поменять повсеместно, где они используются. Собственно, советую подумать на причинами, по которым существуюет интерфейс Map. Надеюсь, тебе самому тогда станет понятно, что ты не прав.
а чем одно дело отличается от другого? и что нужно менять повсеместно, где используются? если я произвожу вызовы только методов интерфейса Map, а сам интерфейс не изменяется, то замена производится только в месте создания. если есть вызовы, специфические для HashMap (ну надо мне , то ни о каком переходе на новую реализацию Map не может быть и речи. если изменятся интерфейс Map, то все по-любому накрывается медным тазом.
и как на счет того, чтобы подумать над причинами, по которым класс HashMap является публичным? а над причинами существования интерфейса Map нужно думать не его пользователю, а его создателю и проектировщику. если реализация какого либо интерфейса будет изменятся, то его пользователь (напр., прикладной программист) ничего не должен знать об этом, равно как и о том, какие реализации вообще существуют.
И в
