Работал в двух небольших компаниях, а сейчас работаю в большой.
Плюсы большой компании(скорее относится к компаниям, которые делают конечный продукт и продают, в меньшей степени относится к крупным аутсорсерам, т.к. по сути, они похожи на множество мелких компаний, и там чаще всего нужер результат, а не высокое качество и имя компании):
1) использования новейших технологий, и советов от людей с большим опытом.
2) структурирование разработки ПО (выпуск билда, проектирование, системы контроля версий, багтрэккеры, система учета времени, хороший менеджент)
3) по мимо результата, очень внимательно смотрят на качество кода, качество архитектуры, постоянный ревью кода и архитектуры от профессионалов, быстро учишься писать правельный и качественный код.
4) очень быстро набирается опыт
5) возможность сменить специализацию, перейти в другой проект, бесплатное образование и курсы внутри компании.
6) почти нету придела совершенствования.
Минусы больших компаний:
1) вы являетесь всего лишь маленьким колесиком, в большой системе
2) трудно расти вверх, все сильно зависит от проекта в котором вы работаете, и людей, которые работают в этом проекте. Часто случается, что в проекте работают одни профессионалы, и вы по сравнению с ними будете серой мышкой, и будете выполнять только не рискованные задачи. Или можно попасть на не значимый проект для компании, в котором руководство вас может не замечать.
Плюсы в маленьких компаниях:
1) если вы что-то умеете, то вас быстро замечают, и вы быстро растете
Следущие плюсы сильно зависят от компании, и людей, которые там работают
Минусы маленьких компаний:
1) часто менеджмент очень глупый, т, к. создатели компании без образования в IT сфере.(часто не поставлен процесс разработки, все делается на коленке)
2) часто в маленьких компаниях нету профессионала, который будет тянуть всех вперед
3) сложно набраться опыта, т.к. маленькие компания сильно узконаправленные.
4) часто проекты весьма простые, и где-то через год, понимаешь что уже знаешь все для работы в этой компании, и становится скучно.
P.S. лично мой вердикт — лучше всего работать в небольшой компании, которая занимается серьезными проектами, в которой по крайне мере есть один профессионал, который строит систему разработки ПО(и хочется тянуться к знаниям за ним). Но таких компаний ИМХО весьма мало.
Вы меня абсолютно не правильно поняли. Дело не в щупанье. Возьмите историю Гейтса, или Джобса, они создавали ПО, операционные системы, и т.д. Возьмите гугл, можно перечислять до бесконечности об инновациях, технологиях, и просто качественном поисковике, плюс куча сервисов, которые реально стали революционными.
А теперь возьмите Facebook — что они сделали кроме сервиса? ничего…
Я вам могу привести куча примеров, и прорывов аналогичных facebook'у, только более удачных:
например Ebay — акции которого торгуются на бирже, плюс это сервис приносит реально огромные деньги и это был прорыв в те времена, а не просто улучшенный интерфейс сервисов как в facebook(к примеру myspace был давно),
или к примеру Amazon тоже был прорыв в свое время.
Проблема в том, что многие рождения этих сервисов не застали, и для них популярность и рост facebook'а акт подражания, и гордости.
Но пока, все что смог facebook сделать, это привлечь домохозяек, которые как тут написали ниже, с горящими глазами проводят там куча времени… А посути это всего лишь площадка, для общения, и популярность ее прямопропорционально привлечению новых домохозяек, и времени. Я к примеру на тот же вконтакт уже почти не захожу, хотя раньше проводил там какое-то время.
Мне вспоминается эра популярности сайтов знакомств в рунете, так же там все проводили куча времени, и было весьма много пользователей, но эра прошла, и популярность закончилась. Сейчас если посмотреть все больше и больше появляются противников соц сетей, либо тех, кому они абсолютно нейтральны. А т.к. соц. сети, пока не научились производить никакой добавленной стоимости, кроме общения, то популярность вполне может сойти на нет через пару годиков.
А если кому-то интересно, то могут почитать эру дот комов 99-2001 год, и посмотреть, много ли сервисов и сайтов дожило с тех времен? а ведь тогда тоже было не мало революционных проектов и популярных проектов.
тоже абсолютно с этим согласен. Когда говорят, что он миллиардер, то сильно лукавят. Акции компании на биржах не торгуются, ибо IPO проводить глупо. Т.к. facebook оценивают в 16 млрд баксов, а дохода всего около 200млн(да и то, я не уверен что это чистый доход, на сколько я знаю это полный доход от рекламы), то с каких денег платить девиденды, если доходность всего около 10-12 процентов?
Единственное, что мне не нравится, это сравнение с Гейтсом, и Джобсом. Они производители инновационные продуктов для всех, а в частности для обычных смертных людей(IBM тогда думала, что домохозяйкам компьютеры не нужны...). Они производили реальные продукты, с реальной добавочной стоимостью. А теперь задайте вопрос, а что же такое Facebook? что он дает? кроме собранных данных в одном месте, и куча связных линков друзей. По сути этот продукт не произвел никакую революцию, он сделал просто некоторые вещи более удобными и все.
я конечно понимаю, что тут в основном веб разработчики сидят, но не забывайте, что java язык не только для веба. Поэтому серилизация — это мощнейший инструмент для передачи данных между серверами, rmi, java baen'ов и т.д. И ни о каких xml даже речи не идет, когда надо производительность.
Статья очень скудная, скорее описывает протокол(хоят это почитать было интересно).
Ни слова не сказано про подводные камни, и тоности, даже про ключевое слово transient ни слова.
Прочитайте внимательно что я писал выше, я говорил про знание языка программирования, а никак не умение программировать. Для этого можете пройти SCJD — очень интересный тест, точнее там даже тестов нету. Но опять же — там ни чего кардинально сложного нету.
А мой коммент был написан сугубо для тех, кто говорит, что можно изучить язык программирование за пару месяцев.
P.S. SCJP 1.5 значительно сложнее 1.4, т.к. появились совершенно новые типы заданий. Сдать на зачет легко, если не изменяет память, то выше 52% надо получить. Но у нас к примеру в фирме внутреннее требование в 90 % и выше. А для этого надо хотя бы недельку посидеть и поучиться. Особенно много в 1.5, возможно и в 1.6 многопоточности. А тут уже есть хоть какие-никакие азы прогарммирования, и начальные понимания многопоточности.
По веб технологиям не получал сертификаты, так что сказать ничего не могу. А вот SCJD весьма интересен.
ну во первых, чего тут смешного? и чем вы тут хвастаетесь? это всего лишь Fundamentals, где 50 % вопросов можно запустить в компилятор и проверить. И 96 % это не ваши балы, а всего лишь относительное положение ваших балов по сравнению с другими. Так что по балам я думаю около 85%, что вообщем-то для самого простого теста достаточно.
Более интересен тогда тест как миниум от Сана:
Sun Certified Programmer for the Java Platform, Standard Edition 6 (CX-310-065)
Да и то, эти тесты всего лишь показывают знание языка и все.
P.S. можете ради интереса тут дать свою транскрипцию из brainbench :)
Читаю коменты, и смотрю тут все великие программисты… толи я децл тормоз, толи занимаюсь чем-то не тем, но у меня уже года 3 не было моментов, когда я бы сказал — что это задача легкая, и каждый самоучка ее сделает…
Многие тут имеют сертификаты по «простым языка» прогарммирования вроде Java, c++,c#, .net, php? and etc? Попробуйте ради интереса зайти на brainbench.com, там бесплатно есть основной тест почти по всем современным языкам программирования, потмо можно ради интереса поискать Сановские, или майкрософтовские тесты, и оцените знания языка… Хороше ели хотя бы 20 % хабра наберут хотя бы 80 % в этих тестах…
Я конечно не уверен, но на сколько я знаю у электриков головная боль, куда деть электричество ночью. Даже цены на него ниже ночью. Поэтому ИМХО вполне возможно, что электрики будут очень радны ночной нагрузкой на сеть
Пример 1:
Автор не правильно понял утверждение.
$Result = array(); не являет строго локальной переменной, да и т.к. она возвращается, то область видимости переменной уже будет не локальная.
Поэтому пример наоборот показывает правильность определение возвращаемой переменной в самом начале кода. К этому примеру я бы еще добавил, что return должен быть всегда один(за редким исключением).
В изначальном утверждение имелось ввиду временные переменные для некоторых блоков функции, или циклов.
Пример 2:
Я уже лет 5-7 с пхп не имел дело, но какое там многопоточное программирование простите? Да и даже если оно было, то установка функция присвоения далеко не атомарна. Да и вообще тут метод get с локальной переменной, где тут concurrency?
Автор правильно подметил, что надо использовать обработку исключений.
Пример 3:
Тут думаю надо задуматься об ООП и архитектуре, потому что если есть те вопросы, которые там задаются, то зачем вообще тогда городить такой код ??? Да и опять причем тут многопоточность? где тут синхронизации(х3 возможны ли они в пхп ?) и присвоение переменной какого-либо значения не является атомарной во многих языках программирования.
пример Про дублирование данных:
любой дубликат кода в ООП исходит из плохой архитектуры(даже при оптимизации). только за редким исключением это не так.
К сожалению эта схема работает только с веб разработчиками. Не знаю какое соотношение веб разработчиков и разработчиков ПО(а их еще можно разделить на серверные и гуишные приложения), но вторым путь к личному бизнесу(считай фрилансерству) почти закрыт. У меня только пару знакомых так работают, но они давно нашли пару постоянных хороших заказчиков, и пишут небольшие программки, и признаюсь к примеру мне это абсолютно не интересно, скучно, и малопрофессионально. Можно конечно попробывать собрать команду, и пытаться отхватить хороший проект, за хорошие деньги, но это очень тяжело.
я работаю в области финансовых и бирживых систем. Где падение вообщем-то вообще должно быть невозможно. Руководители у нас даже не думаю нанимать красноглазиков. Средний возвраст работников в проекте 30-33 года(хотя я моложе). Обычно в таких системах руководители действительно профи, иначе это работать не будет. Представте себе падение биржевого сервера в активной фазе торгов ?:)
«Вопрос автору — а вы специально не затрагиваете производительность труда и, собственно, адекватность повышения зарплаты специалисту? У меня сложилось ощущение, что это автоматически подразумевается, и не только в данной статье. А это огромное допущение, без которого многие вопросы бессмысленны. А у вас есть основания полагать, что вы достойны зарабатывать больше? Не желаете, а действительно достойны? Почему компании выгоднее раздувать ваш фонд оплаты труда, а не взять более молодого, рвущегося в бой и беззвездного сотрудника?»
Я не автор, но попробую ответить :)
Есть такие области, в которой молодых и рвущихся в бой программистов лучше даже за километр не подпускать к проекту, ибо потом расхлебывать проблемы будет дороже…
Я говорю про софт уровня 24/365 (который работает 24 часа в сутки, 365 дней в году)
Сам озадачивался этой проблемой, но пока конкретного решения не нашел(я еще не достиг потолка)
Из вариантов я вижу следущие:
1) дополнительно зарабатывать на финансовых рынках — форекс, акции. У программистов такой склад ума, что вполне реально им реализоваться и в этом направлении. Или даже написать торгового робота, который сам будет торговать. Сам я этим занимался, и в докризисные времена весьма неплохо зарабатывал, частенько бывало что доход в месяц привышал в 3-5 раз ЗП за месяц. Но в кризисные времена у меня не получалось зарабатывать, я снял все деньги и купил неплохую машину. Поэтому этот вариант не совсем стабилен, и не каждому подойдет. но ИМХО считаю, что опыт тут тоже решает, и через какое-то время можно весьма неплохо зарабатывать. Из минусов — этот заработок не приносит никакой добавленной стоимости, и не создает никого продукта
2) сменить профессию на ту, которая нравится помимо программирования, но тут есть один минус: придется идти на понижение денег, и на низкую должность, так называемый низкий старт
3) уходить в менеджеры: тут есть некоторые нюансы, к примеру у нас в компании все менеджеры вышли из программистов, и сами менеджеры пишут код по мере загруженности.(специфика проектов, и компании, менеджеры обязаны знать теоретическуие и практические навыки), поэтому программирование никуда не пропадет.
4) уходить в бизнесс: тут надо начальный капитал, которого пока у меня нету, возможно если только в будущем.
Поскольку родовые типы реализуются практически полностью в компиляторе Java, а не в библиотеке время исполнения, практически вся информация о родовых типах «стирается» при генерации байткода. Другими словами, компилятор генерирует почти такой же код, который вы написали бы вручную без использования родовых типов и приведений типов, после проверки вашей программы на независимость от типа. В отличие от С++ List<Integer> и List<String> являются одним и тем же классом (хотя и имеют различные типы, являющиеся подтипами List<?> — отличие более важное в JDK 5.0, чем в предыдущих версиях языка).
Одним из побочных эффектов механизма стирания является неспособность класса реализовать оба интерфейса Comparable<String> и Comparable<Number>, поскольку оба они на самом деле являются одним и тем же интерфейсом, указывая на один и тот же метод compareTo(). Может показаться более благоразумным объявить класс DecimalString, совместимый как со Strings, так и с Numbers, но с точки зрения компилятора Java вы пытались бы объявить один и тот же метод дважды:
public class DecimalString implements Comparable<Number>, Comparable<String> {… } // нет
Еще одним следствием механизма стирания является бессмысленность использования приведений типов и instanceof с параметрами родовых типов. В следующем фрагменте кода независимость от типа совершенно не улучшается:
public <T> T naiveCast(T t, Object o) { return (T) o; }
Компилятор просто выдаст не отмеченное предупреждение о преобразовании, поскольку не знает о том, является приведение типов безопасным или нет. Метод naiveCast() фактически не выполняет какого-либо приведения типов. T просто замещается его «стирателем» (Object), а переданный объект будет приведен в Object — не то что задумывалось.
Механизм стирания также ответственен за описанные выше проблемы создания – вы не можете создать объект родового типа, поскольку компилятор не знает, какой конструктор вызвать. Если ваш родовой класс требует создания объектов, чей тип указан параметрами родового типа, его конструкторы должны принимать литерал класса (Foo.class) и сохранять его, для того чтобы экземпляры могли быть созданы отображением.
Поскольку родовые типы реализуются практически полностью в компиляторе Java, а не в библиотеке время исполнения, практически вся информация о родовых типах «стирается» при генерации байткода. Другими словами, компилятор генерирует почти такой же код, который вы написали бы вручную без использования родовых типов и приведений типов, после проверки вашей программы на независимость от типа. В отличие от С++ List и List являются одним и тем же классом (хотя и имеют различные типы, являющиеся подтипами List — отличие более важное в JDK 5.0, чем в предыдущих версиях языка).
Одним из побочных эффектов механизма стирания является неспособность класса реализовать оба интерфейса Comparable и Comparable, поскольку оба они на самом деле являются одним и тем же интерфейсом, указывая на один и тот же метод compareTo(). Может показаться более благоразумным объявить класс DecimalString, совместимый как со Strings, так и с Numbers, но с точки зрения компилятора Java вы пытались бы объявить один и тот же метод дважды:
public class DecimalString implements Comparable, Comparable {… } // нет
Еще одним следствием механизма стирания является бессмысленность использования приведений типов и instanceof с параметрами родовых типов. В следующем фрагменте кода независимость от типа совершенно не улучшается:
public T naiveCast(T t, Object o) { return (T) o; }
Компилятор просто выдаст не отмеченное предупреждение о преобразовании, поскольку не знает о том, является приведение типов безопасным или нет. Метод naiveCast() фактически не выполняет какого-либо приведения типов. T просто замещается его «стирателем» (Object), а переданный объект будет приведен в Object — не то что задумывалось.
Механизм стирания также ответственен за описанные выше проблемы создания – вы не можете создать объект родового типа, поскольку компилятор не знает, какой конструктор вызвать. Если ваш родовой класс требует создания объектов, чей тип указан параметрами родового типа, его конструкторы должны принимать литерал класса (Foo.class) и сохранять его, для того чтобы экземпляры могли быть созданы отображением.
Плюсы большой компании(скорее относится к компаниям, которые делают конечный продукт и продают, в меньшей степени относится к крупным аутсорсерам, т.к. по сути, они похожи на множество мелких компаний, и там чаще всего нужер результат, а не высокое качество и имя компании):
1) использования новейших технологий, и советов от людей с большим опытом.
2) структурирование разработки ПО (выпуск билда, проектирование, системы контроля версий, багтрэккеры, система учета времени, хороший менеджент)
3) по мимо результата, очень внимательно смотрят на качество кода, качество архитектуры, постоянный ревью кода и архитектуры от профессионалов, быстро учишься писать правельный и качественный код.
4) очень быстро набирается опыт
5) возможность сменить специализацию, перейти в другой проект, бесплатное образование и курсы внутри компании.
6) почти нету придела совершенствования.
Минусы больших компаний:
1) вы являетесь всего лишь маленьким колесиком, в большой системе
2) трудно расти вверх, все сильно зависит от проекта в котором вы работаете, и людей, которые работают в этом проекте. Часто случается, что в проекте работают одни профессионалы, и вы по сравнению с ними будете серой мышкой, и будете выполнять только не рискованные задачи. Или можно попасть на не значимый проект для компании, в котором руководство вас может не замечать.
Плюсы в маленьких компаниях:
1) если вы что-то умеете, то вас быстро замечают, и вы быстро растете
Следущие плюсы сильно зависят от компании, и людей, которые там работают
Минусы маленьких компаний:
1) часто менеджмент очень глупый, т, к. создатели компании без образования в IT сфере.(часто не поставлен процесс разработки, все делается на коленке)
2) часто в маленьких компаниях нету профессионала, который будет тянуть всех вперед
3) сложно набраться опыта, т.к. маленькие компания сильно узконаправленные.
4) часто проекты весьма простые, и где-то через год, понимаешь что уже знаешь все для работы в этой компании, и становится скучно.
P.S. лично мой вердикт — лучше всего работать в небольшой компании, которая занимается серьезными проектами, в которой по крайне мере есть один профессионал, который строит систему разработки ПО(и хочется тянуться к знаниям за ним). Но таких компаний ИМХО весьма мало.
А теперь возьмите Facebook — что они сделали кроме сервиса? ничего…
Я вам могу привести куча примеров, и прорывов аналогичных facebook'у, только более удачных:
например Ebay — акции которого торгуются на бирже, плюс это сервис приносит реально огромные деньги и это был прорыв в те времена, а не просто улучшенный интерфейс сервисов как в facebook(к примеру myspace был давно),
или к примеру Amazon тоже был прорыв в свое время.
Проблема в том, что многие рождения этих сервисов не застали, и для них популярность и рост facebook'а акт подражания, и гордости.
Но пока, все что смог facebook сделать, это привлечь домохозяек, которые как тут написали ниже, с горящими глазами проводят там куча времени… А посути это всего лишь площадка, для общения, и популярность ее прямопропорционально привлечению новых домохозяек, и времени. Я к примеру на тот же вконтакт уже почти не захожу, хотя раньше проводил там какое-то время.
Мне вспоминается эра популярности сайтов знакомств в рунете, так же там все проводили куча времени, и было весьма много пользователей, но эра прошла, и популярность закончилась. Сейчас если посмотреть все больше и больше появляются противников соц сетей, либо тех, кому они абсолютно нейтральны. А т.к. соц. сети, пока не научились производить никакой добавленной стоимости, кроме общения, то популярность вполне может сойти на нет через пару годиков.
А если кому-то интересно, то могут почитать эру дот комов 99-2001 год, и посмотреть, много ли сервисов и сайтов дожило с тех времен? а ведь тогда тоже было не мало революционных проектов и популярных проектов.
Статья очень скудная, скорее описывает протокол(хоят это почитать было интересно).
Ни слова не сказано про подводные камни, и тоности, даже про ключевое слово transient ни слова.
А мой коммент был написан сугубо для тех, кто говорит, что можно изучить язык программирование за пару месяцев.
P.S. SCJP 1.5 значительно сложнее 1.4, т.к. появились совершенно новые типы заданий. Сдать на зачет легко, если не изменяет память, то выше 52% надо получить. Но у нас к примеру в фирме внутреннее требование в 90 % и выше. А для этого надо хотя бы недельку посидеть и поучиться. Особенно много в 1.5, возможно и в 1.6 многопоточности. А тут уже есть хоть какие-никакие азы прогарммирования, и начальные понимания многопоточности.
По веб технологиям не получал сертификаты, так что сказать ничего не могу. А вот SCJD весьма интересен.
Более интересен тогда тест как миниум от Сана:
Sun Certified Programmer for the Java Platform, Standard Edition 6 (CX-310-065)
Да и то, эти тесты всего лишь показывают знание языка и все.
P.S. можете ради интереса тут дать свою транскрипцию из brainbench :)
Многие тут имеют сертификаты по «простым языка» прогарммирования вроде Java, c++,c#, .net, php? and etc? Попробуйте ради интереса зайти на brainbench.com, там бесплатно есть основной тест почти по всем современным языкам программирования, потмо можно ради интереса поискать Сановские, или майкрософтовские тесты, и оцените знания языка… Хороше ели хотя бы 20 % хабра наберут хотя бы 80 % в этих тестах…
Автор не правильно понял утверждение.
$Result = array(); не являет строго локальной переменной, да и т.к. она возвращается, то область видимости переменной уже будет не локальная.
Поэтому пример наоборот показывает правильность определение возвращаемой переменной в самом начале кода. К этому примеру я бы еще добавил, что return должен быть всегда один(за редким исключением).
В изначальном утверждение имелось ввиду временные переменные для некоторых блоков функции, или циклов.
Пример 2:
Я уже лет 5-7 с пхп не имел дело, но какое там многопоточное программирование простите? Да и даже если оно было, то установка функция присвоения далеко не атомарна. Да и вообще тут метод get с локальной переменной, где тут concurrency?
Автор правильно подметил, что надо использовать обработку исключений.
Пример 3:
Тут думаю надо задуматься об ООП и архитектуре, потому что если есть те вопросы, которые там задаются, то зачем вообще тогда городить такой код ??? Да и опять причем тут многопоточность? где тут синхронизации(х3 возможны ли они в пхп ?) и присвоение переменной какого-либо значения не является атомарной во многих языках программирования.
пример Про дублирование данных:
любой дубликат кода в ООП исходит из плохой архитектуры(даже при оптимизации). только за редким исключением это не так.
Я не автор, но попробую ответить :)
Есть такие области, в которой молодых и рвущихся в бой программистов лучше даже за километр не подпускать к проекту, ибо потом расхлебывать проблемы будет дороже…
Я говорю про софт уровня 24/365 (который работает 24 часа в сутки, 365 дней в году)
Из вариантов я вижу следущие:
1) дополнительно зарабатывать на финансовых рынках — форекс, акции. У программистов такой склад ума, что вполне реально им реализоваться и в этом направлении. Или даже написать торгового робота, который сам будет торговать. Сам я этим занимался, и в докризисные времена весьма неплохо зарабатывал, частенько бывало что доход в месяц привышал в 3-5 раз ЗП за месяц. Но в кризисные времена у меня не получалось зарабатывать, я снял все деньги и купил неплохую машину. Поэтому этот вариант не совсем стабилен, и не каждому подойдет. но ИМХО считаю, что опыт тут тоже решает, и через какое-то время можно весьма неплохо зарабатывать. Из минусов — этот заработок не приносит никакой добавленной стоимости, и не создает никого продукта
2) сменить профессию на ту, которая нравится помимо программирования, но тут есть один минус: придется идти на понижение денег, и на низкую должность, так называемый низкий старт
3) уходить в менеджеры: тут есть некоторые нюансы, к примеру у нас в компании все менеджеры вышли из программистов, и сами менеджеры пишут код по мере загруженности.(специфика проектов, и компании, менеджеры обязаны знать теоретическуие и практические навыки), поэтому программирование никуда не пропадет.
4) уходить в бизнесс: тут надо начальный капитал, которого пока у меня нету, возможно если только в будущем.
www.ibm.com/developerworks/ru/library/j-jtp01255/index.html
Одним из побочных эффектов механизма стирания является неспособность класса реализовать оба интерфейса Comparable<String> и Comparable<Number>, поскольку оба они на самом деле являются одним и тем же интерфейсом, указывая на один и тот же метод compareTo(). Может показаться более благоразумным объявить класс DecimalString, совместимый как со Strings, так и с Numbers, но с точки зрения компилятора Java вы пытались бы объявить один и тот же метод дважды:
public class DecimalString implements Comparable<Number>, Comparable<String> {… } // нет
Еще одним следствием механизма стирания является бессмысленность использования приведений типов и instanceof с параметрами родовых типов. В следующем фрагменте кода независимость от типа совершенно не улучшается:
public <T> T naiveCast(T t, Object o) { return (T) o; }
Компилятор просто выдаст не отмеченное предупреждение о преобразовании, поскольку не знает о том, является приведение типов безопасным или нет. Метод naiveCast() фактически не выполняет какого-либо приведения типов. T просто замещается его «стирателем» (Object), а переданный объект будет приведен в Object — не то что задумывалось.
Механизм стирания также ответственен за описанные выше проблемы создания – вы не можете создать объект родового типа, поскольку компилятор не знает, какой конструктор вызвать. Если ваш родовой класс требует создания объектов, чей тип указан параметрами родового типа, его конструкторы должны принимать литерал класса (Foo.class) и сохранять его, для того чтобы экземпляры могли быть созданы отображением.
Одним из побочных эффектов механизма стирания является неспособность класса реализовать оба интерфейса Comparable и Comparable, поскольку оба они на самом деле являются одним и тем же интерфейсом, указывая на один и тот же метод compareTo(). Может показаться более благоразумным объявить класс DecimalString, совместимый как со Strings, так и с Numbers, но с точки зрения компилятора Java вы пытались бы объявить один и тот же метод дважды:
public class DecimalString implements Comparable, Comparable {… } // нет
Еще одним следствием механизма стирания является бессмысленность использования приведений типов и instanceof с параметрами родовых типов. В следующем фрагменте кода независимость от типа совершенно не улучшается:
public T naiveCast(T t, Object o) { return (T) o; }
Компилятор просто выдаст не отмеченное предупреждение о преобразовании, поскольку не знает о том, является приведение типов безопасным или нет. Метод naiveCast() фактически не выполняет какого-либо приведения типов. T просто замещается его «стирателем» (Object), а переданный объект будет приведен в Object — не то что задумывалось.
Механизм стирания также ответственен за описанные выше проблемы создания – вы не можете создать объект родового типа, поскольку компилятор не знает, какой конструктор вызвать. Если ваш родовой класс требует создания объектов, чей тип указан параметрами родового типа, его конструкторы должны принимать литерал класса (Foo.class) и сохранять его, для того чтобы экземпляры могли быть созданы отображением.