Комментарии 443
Это в большинстве компаний сейчас так, к сожалению. Острый дефицит квалифицированных кадров, раздутые зарплаты, некомпетентные сотрудники, и, что самое печальное, никто не знает, что со всем этим делать.
С другой стороны, такая ситуация выгодна для квалифицированных сотрудников, которые будут на вес золота.
С другой стороны, такая ситуация выгодна для квалифицированных сотрудников, которые будут на вес золота.
По поводу высококлассных специалистов, думаю, вам будет интересна моя предыдущая статья.
Квалифицированные сотрудники часто зарабатывают меньше идиотов.
каждый сремится достичь уровня своей некомпетентности, а переход на каждый новый уровень (обычно) сопровождается повышением зарплаты.
1) Как определить когда этот самый переход произошел?
2) А уж тем более как заставить начальство понимать, что это произошло и что это надо как-то поощрять?
2) А уж тем более как заставить начальство понимать, что это произошло и что это надо как-то поощрять?
1) когда вас больше не повышают или, ещё хуже, повысили, а потом понизили
2) начальству есть смысл поощрять пока он не достигнут, когда достигнут — только удерживать и то не факт.
2) начальству есть смысл поощрять пока он не достигнут, когда достигнут — только удерживать и то не факт.
1) Я имел в виду что это за событие «переход на новый уровень»:)
2) Как я понял не так давно, не всякому начальство понимает что есть смысл поощрять. Мало того, некоторое начальство вообще имеет странную философию, а именно: «Почему вы думаете что зарплата человека со стажем и опытом должна расти?» У меня прям челюсть отвисла и понял что разговаривать тут больше не о чем.
2) Как я понял не так давно, не всякому начальство понимает что есть смысл поощрять. Мало того, некоторое начальство вообще имеет странную философию, а именно: «Почему вы думаете что зарплата человека со стажем и опытом должна расти?» У меня прям челюсть отвисла и понял что разговаривать тут больше не о чем.
1) когда знаете, что можете больше денег получать за ту же работу
2) А почему должна? Должна если увеличивается производительность при требуемом качестве. Да ещё если это повышение положительно отражается на прибыли фирме.
2) А почему должна? Должна если увеличивается производительность при требуемом качестве. Да ещё если это повышение положительно отражается на прибыли фирме.
1) Да человек то знает, а толку от его знания, если в компании на это могут просто закрывать глаза и сами не заикнутся о том что они знают:)
2) Я тут с Вами отчасти согласен. Но:
— с опытом растет качество работы(я сейчас говорю про хорошего разработчика а не пофигиста)
— Опытный человек становится учителем для новичков. А это твои новые обязанности
— Опытный человек участвует в отборе новых работников, отсеивая откровенно хреновый код и давая свою оценку.
— На этого разработчика с годами может сваливаться и другая работа. Т.е. он уже не просто разработчик, а и архитектор и разработчик и чуть ли не ПМ и тимлид и верстать сможет и области знаний у него шире и еще что-нибудь накинуть могут:)
А люди сверху как бы не замечают что на одном человеке много что держится, и он вроде на бумаге просто разработчик.
Это все к тому что с опытом в нашем ремесле должна и зарплата прибавляться. Начальство при этом прямого увеличения выхлопа в виде денег может и не замечать, потому что человек может делать много чего где прибыль посчитать невозможно, а работа его нужна.
2) Я тут с Вами отчасти согласен. Но:
— с опытом растет качество работы(я сейчас говорю про хорошего разработчика а не пофигиста)
— Опытный человек становится учителем для новичков. А это твои новые обязанности
— Опытный человек участвует в отборе новых работников, отсеивая откровенно хреновый код и давая свою оценку.
— На этого разработчика с годами может сваливаться и другая работа. Т.е. он уже не просто разработчик, а и архитектор и разработчик и чуть ли не ПМ и тимлид и верстать сможет и области знаний у него шире и еще что-нибудь накинуть могут:)
А люди сверху как бы не замечают что на одном человеке много что держится, и он вроде на бумаге просто разработчик.
Это все к тому что с опытом в нашем ремесле должна и зарплата прибавляться. Начальство при этом прямого увеличения выхлопа в виде денег может и не замечать, потому что человек может делать много чего где прибыль посчитать невозможно, а работа его нужна.
Постоянный рост ЗП работника негативно сказывается на его мотивации. Звучит парадоксально, но это факт. До определенного времени знания напрямую конвертируются в деньги, но потом каждый дополнительный уровень опыта приносит только косвенную прибыль, потому что время ограничено, и именно оно является бутылочным горлышком у опытного работника. Осознавая этот факт, работник начинает уменьшать рабочее время, которое он тратит на работу, чтобы еще больше максимизировать прибыль от продажи своего рабочего ресурса, таким образом попадая в ловушку собственной лени и снижения мотивации.
1) Под «знает» я имел в виду прежде всего что ему предлагают работу в другой фирме с теми же обязанностями, но большей зарплатой.
Вы умудрились обвинить много хороших людей в продажности, глупо.
Простите, а в чем суть работы? Не в том-ли, чтобы продавать своё время?
Не только и не для всех. Мне вот интересны задачи, чем сложнее задачи тем интереснее работа. Сложность задач. Объём работы. К примеру на основе сайтостроя:
1. Штамповать сайты конвейерно на бесплатной ЦМС, работа — вёрстка. Как правило почти все на 80% однотипны. Оклад + % в зависимости сколько десятков сайтов на штамповал в месяц.
2. Сложный портал/агрегатор/сервис. Тут уже полёт в усилении и развитии одного сайта. Развитие его, поиск стандартных и не стандартных решений. Новые технологии.
Да, если охото тупо денег за протирание штанов и выполнение механической работы. То первый вариант самое то.
1. Штамповать сайты конвейерно на бесплатной ЦМС, работа — вёрстка. Как правило почти все на 80% однотипны. Оклад + % в зависимости сколько десятков сайтов на штамповал в месяц.
2. Сложный портал/агрегатор/сервис. Тут уже полёт в усилении и развитии одного сайта. Развитие его, поиск стандартных и не стандартных решений. Новые технологии.
Да, если охото тупо денег за протирание штанов и выполнение механической работы. То первый вариант самое то.
Работа это прежде всего продажа своего времени. Формы оплаты могут быть разные, но суть — продажа квалифицированного (или не очень) времени. Нашли работодателя (или он вас нашёл), который требует за свои деньги решать задачи интересные вам — молодец (или повезло). Но это остаётся работой. А если человек говорит: «сделай проект с такой-то функциональностью за N дней — получишь M денег», то уже не работа по сути, а выполнение заказа.
Т.е., если я правильно вас понял, можно у п.2 отобрать зарплату и его производительность никак не поменяется (я уже не говорю, что он просто сбежит)?
Суть работы в том, чтоб что-то делать, за что и получаться какое-то вознаграждение. Если бы вы сказали, что любые сотрудники продают своё время, за сколько умудрились договориться на собеседовании, я бы прошел мимо (хотя и так не все гладко, я знаю много людей которые не торгуются вообще, будучи высококвалифицированными). Но вы сказали, что сотрудники продаются, не время продают, а сами продаются.
Быть может для вас нет разницы в этих формулировках, но для многих такая разница есть.
Быть может для вас нет разницы в этих формулировках, но для многих такая разница есть.
Честно, нет. Да, сейчас работа отличается от рабства. Появились плюшки, зарплата, смягчилось отношение к ресурсу, но в целом система работает. Вы работаете на кого-то, кто получает от вашей работы столько, что хватает вам заплатить, налоги и себе оставить. Это не продажа тела, но недалеко ушли от этого.
Возможно всё же формулировка некорректна.
Продавать свой труд — не то же самое, что продать себя (читай: свои принципы, убеждения, ценности). Бывает и такое, но всё же продажа рабочего времени или результатов труда — изначально этого не подразумевает.
Продавать свой труд — не то же самое, что продать себя (читай: свои принципы, убеждения, ценности). Бывает и такое, но всё же продажа рабочего времени или результатов труда — изначально этого не подразумевает.
Это от того, что умные сомневаются и колеблются, а идиоты самоуверенны. В том числе и при «продаже» себя на собеседовании.
А в Гугле продолжают задавать головоломки, и вроде у них все неплохо.
Всё таки те, кому задают головоломки — в подавляющем большинстве исполнители. Над которыми ещё есть несколько уровней людей, которые придумывают, что и как они будут писать.
Ерунду говорите.
Прочитайте произведение Айзека Азимова «Профессия»- возможно, это поможет вам понять zerkms
Если говорить в частности про Гугл, то это не так — никаких «нескольких уровней», решающих, что будут спрашивать интервьюверы на очных собеседованиях, не существует.
НЛО прилетело и опубликовало эту надпись здесь
Я очень рад за гугл. Но все чаще приходится по работе контактировать с людьми, которые охренительно решают головоломки, но не знают, как правильно работать с xml и чем в sql просто join отличается от left join. И обязательно на позицию senior. Потому что охренеть как классно решают головоломки. Ну просто мастерски.
А код потом писать некому.
А код потом писать некому.
ключевая часть фразы была ", и вроде у них все неплохо. "
Не секрет, что у гугла головоломки служат простой цели: отсечь лишний народ. Поскольку иначе они будут не в состоянии провести собственно техническое интервью.
Было бы хуже, если бы они вместо головоломок просто рандмно выбирали 1 резюме из 10 — большой вопрос.
Было бы хуже, если бы они вместо головоломок просто рандмно выбирали 1 резюме из 10 — большой вопрос.
Для отсечения лишнего народа есть телефонной скрининг и телефонное интервью. Головоломки для отсечения — очень странная методика, мне кажется.
Странная и неэффективная (как мне кажется). Но очень простая: даем девочке из HR пачку загадок с ответами — и получаем готового специалиста по первичному интервьюированию. Все при деле, отчетность в порядке.
Что до телефонного интервью, то лично мне надоело слышать в трубке стук клавиш собеседника, судорожно ищущего ответ в гугле. :) К тому же нормальное телефонное интервью — это минус 20 минут работы квалифицированногт специалиста. Что весьма накладно.
Что до телефонного интервью, то лично мне надоело слышать в трубке стук клавиш собеседника, судорожно ищущего ответ в гугле. :) К тому же нормальное телефонное интервью — это минус 20 минут работы квалифицированногт специалиста. Что весьма накладно.
По-моему, наличие фиксированных «ответов» уже убивает весь смысл такой загадки на корню, изначально. К слову, по опыту моего общения с гугловцами, они слишком адекватны, чтобы такое устраивать.
«Загадки», которые загадываются в гугле на интервью своей целью имеют не получение фиксированного ответа, а понимание того, как мыслит кандидат. Необязательно давать правильный ответ, достаточно продемонстрировать интересный, неочевидный ход мысли. И в этом, как раз есть смысл: научиться новому языку программирования можно очень быстро, а вот научиться мыслить — совсем не быстро.
Вместо пачки с вопросами про люки можно с тем же успехом дать пачку с вопросами про сложность добавления N элементов в конец vector-а/ArrayList-а. Для HR одна фигня, что спрашивать, а пользы на порядок больше.
На телефонном можно через гугло-док или любой IM, к примеру, простой код писать. А не задавать шаблонные вопросы, которые легко найти в поисковике. По времени получится сопоставимо, а по пользе, опять же, существенно лучше. Я когда работу подбирал, ряд зарубежных компаний этим походом пользовался.
На телефонном можно через гугло-док или любой IM, к примеру, простой код писать. А не задавать шаблонные вопросы, которые легко найти в поисковике. По времени получится сопоставимо, а по пользе, опять же, существенно лучше. Я когда работу подбирал, ряд зарубежных компаний этим походом пользовался.
На телефонном головоломок не было (на очное не пригласили). Для отсева был короткий блиц во время первого телефонного интервью с HR.
им бы только понедельники — взять и отменить (с)
А в чем проблема-то? Не срабатываетесь с человеком в течение месяца-двух — расставайтесь. Никто же не заставляет только по головоломке оценивать уровень и брать после этого человека навсегда. Сдается мне, проблема с некомпетентными сотрудниками берет корни не из-за головоломок, а из-за того, что с человеком после начала работы толком никто не контактирует, не следит за результатами, не помогает, не мотивирует и т.д.
Испытательный строк — он не для того, чтобы выяснять вещи, которые можно узнать за 30 минут на собеседовании, если не тратить их на головоломки. Да, за два месяца я могу научить тому, что мне нужно. Это будет стоить 120-150 часов моего рабочего времени (объяснения, наставления, ревью кода) и от 200 часов нового сотрудника. Не проще сразу взять того, кого не нужно учить элементарным вещам?
Кроме того, головоломки отсекают часть людей, которые вполне могли бы работать на этой позиции продуктивно с первого дня.
Кроме того, головоломки отсекают часть людей, которые вполне могли бы работать на этой позиции продуктивно с первого дня.
А я на собеседования не хожу потому что головоломки решать не умею, а вот про джойны знаю :) По крайней мере туда не хожу, где не хотят мне выслать тестовое задание предварительно.
Зря, IMHO. Тестовое задание вобще не всегда дается. Очень часто достаточно просто беседы.
Только несколько раз были околотехнические беседы или просили на бумажке или компе что-нибудь быстро написать. Куда чаще «Как должна рассчитываться зарплата таксиста? дворника? врача?», «почему люк круглый?», «почему вы выбрали нашу компанию?», «кем вы себя видите через 5 лет?» и т. п. Причём процентов 90 вопросов совпадают, особенно в веб-студиях, там близко к 100%.
У меня сложилось впечатление, что такие вопросы говорят ровно об одном: интервьюирующая сторона не в состоянии обеспечить настоящее техническое собеседование. Веб-студии — как раз очень характерный пример.
Народ у нас начитанный, все ознакомились с «Как сдвинуть гору Фудзи», каждая вторая веб-студия видит себя среди «ведущих мировых компаний».
Как должна рассчитываться зарплата таксиста, врача и дворника? Так, как скажет экономист. Я — программист. Сделаю, как он скажет.
Почему люк круглый? Люк круглый потому, что так написано в ГОСТе (есть такой, без балды). Почему его сделали круглым разработчики ГОСТа — нужно спрашивать у них.
Почему Вы выбрали нашу компанию? Потому, что только Вы были готовы встретитьс в 17:00. А в 15:00 и 19:00 у меня собеседования еще в 2 компаниях, которые я выбрал.
Кем Вы видите себя через 5 лет? Программистом с опытом работы +5 лет.
Народ у нас начитанный, все ознакомились с «Как сдвинуть гору Фудзи», каждая вторая веб-студия видит себя среди «ведущих мировых компаний».
Как должна рассчитываться зарплата таксиста, врача и дворника? Так, как скажет экономист. Я — программист. Сделаю, как он скажет.
Почему люк круглый? Люк круглый потому, что так написано в ГОСТе (есть такой, без балды). Почему его сделали круглым разработчики ГОСТа — нужно спрашивать у них.
Почему Вы выбрали нашу компанию? Потому, что только Вы были готовы встретитьс в 17:00. А в 15:00 и 19:00 у меня собеседования еще в 2 компаниях, которые я выбрал.
Кем Вы видите себя через 5 лет? Программистом с опытом работы +5 лет.
Слышал и другое объяснение: так они якобы проверяют мою соображалку — если есть, то быстро научусь всему, если нет — то не смогу справиться с их самописным фреймворком/CMS.
Бежать! Бежать от такой работы. Пусть сами разбираются в своем говнокоде, для понимания которого нужен программист, с ходу оценивающий количество тенисных мячиков, помещающихся в желудок дикобраза и стоимость автомобилей, выпущенных в Румынии в 2003 году. :)
В одну такую фирму я всё же устроился, но несмотря на то, что в вакансии в должностных обязанностях первым пунктом стояло «рефакторинг самописной CMS» (а я рефакторить говонокд люблю) за три месяца только проектно-специфичные костыли писал к ней, а по «мержил» свои и чужие костыли с «апстримом» (VCS не было).
> Почему Вы выбрали нашу компанию?
Вы идиот(ка), да? Я, как и все кандидаты до меня и после меня, направил резюме в десяток мест. Где устроюсь быстрее и выгоднее — там и хорошо.
> Кем Вы видите себя через 5 лет?
Если я буду настолько бездарен, чтобы остаться в вашей компании на 5 лет, то меня не стоит вообще на работу брать. Да и компания ваша… Вот вам встречный вопрос: какие планы компании на ближайшие 5/10/20 лет? Что? Нет таких. Так если вы сами не знаете, что с вами будет через 20 лет, будет ли компания и какую нишу она намеревается занимать, то мне-то откуда это знать?
Вы тут наркотики употребляете, не иначе.
© боян
Вы идиот(ка), да? Я, как и все кандидаты до меня и после меня, направил резюме в десяток мест. Где устроюсь быстрее и выгоднее — там и хорошо.
> Кем Вы видите себя через 5 лет?
Если я буду настолько бездарен, чтобы остаться в вашей компании на 5 лет, то меня не стоит вообще на работу брать. Да и компания ваша… Вот вам встречный вопрос: какие планы компании на ближайшие 5/10/20 лет? Что? Нет таких. Так если вы сами не знаете, что с вами будет через 20 лет, будет ли компания и какую нишу она намеревается занимать, то мне-то откуда это знать?
Вы тут наркотики употребляете, не иначе.
© боян
НЛО прилетело и опубликовало эту надпись здесь
Вообще говоря 15000 руб/мес для Иркутска и области это средний доход, грубо говоря половина народу у вас на них умудряется «заплатить квартплату, купить пожрать, купить тех же книг, записаться на курсы, оплатить транспорт, купить одежду». Они умудряются, а у вас не получается? Может всё же у вас запросы повышенные? Может потерпеть годик-другой и, скажем, одежду покупать на рынке китайскую, а не в фирменных магазинах (тоже китайскую :) )?
Ну это при условии наличия квартиры в собственности.
Если жильё снимать — 15 тыщ уже не хватит.
Если жильё снимать — 15 тыщ уже не хватит.
Тоже варианты есть обычно, например снять квартиру-комнату на двоих-троих-…
Вот с кого надо многим пример брать. Человек не ищет причины, а ищет возможности.
как это так? Выпускник вуза, дипломированный специалист будет жить еще с какими-то неудачниками?
Он сразу хочет квартиру, машину и зарплату 75 000 рублей, он же с дипломом, а то еще и с красным.
Veider, не в вашу сторону, а вообще про «специалистов», только вышедших из вузов или не закончивших их вообще.
Он сразу хочет квартиру, машину и зарплату 75 000 рублей, он же с дипломом, а то еще и с красным.
Veider, не в вашу сторону, а вообще про «специалистов», только вышедших из вузов или не закончивших их вообще.
НЛО прилетело и опубликовало эту надпись здесь
Да почему ныть, реальность такова, что большинство студентов еще думают, что будет как в школе. Или еще хуже, как в институте. Нет опыта, не социализированы, живут студенческими привычками и постоянно надеются на дядю. Мороки много, профит минимален.
Вы в универе учились для себя прежде всего, а дальше — байк, кино, ресторан и прочие прелести — это как в жизни повезет, ВУЗ никаких гарантий на хорошую жизнь не дает.
Все также понимают реальную цену этому красному диплому и реальным знаниям, выданным студенту в ВУЗе. Реально толковых — десятки, если не единицы.
Чтобы люди прямо в универе шли к тебе работать на неполный рабочий день — надо вложить очень много денег и еще больше времени. Оплатить учебный отпуск, сдачу сессий, налоги, внутреннее обучение и прочее прочее. Чтобы в итоге получить картонного инженера, которого опять придется обучать, по-своему, и выколачивать всяческие студенческие шалости из неокрепшей еще психики ))
Деньги платят не за диплом и никогда не будут платить за это в нормальных конторах. А за опыт и за пользу, которую этот работник приносит. Какую пользу приносит студент, у которого вообще ни на что времени нет, но еще хочется кабаков, любви и прочих радостей жизни? А работа. Да как на экзамене, на шару че-нить и проскочит ))
Я сейчас не беру сложные специальности, типа врача, микробиолога или физика-ядерщика.
Вы в универе учились для себя прежде всего, а дальше — байк, кино, ресторан и прочие прелести — это как в жизни повезет, ВУЗ никаких гарантий на хорошую жизнь не дает.
Все также понимают реальную цену этому красному диплому и реальным знаниям, выданным студенту в ВУЗе. Реально толковых — десятки, если не единицы.
Чтобы люди прямо в универе шли к тебе работать на неполный рабочий день — надо вложить очень много денег и еще больше времени. Оплатить учебный отпуск, сдачу сессий, налоги, внутреннее обучение и прочее прочее. Чтобы в итоге получить картонного инженера, которого опять придется обучать, по-своему, и выколачивать всяческие студенческие шалости из неокрепшей еще психики ))
Деньги платят не за диплом и никогда не будут платить за это в нормальных конторах. А за опыт и за пользу, которую этот работник приносит. Какую пользу приносит студент, у которого вообще ни на что времени нет, но еще хочется кабаков, любви и прочих радостей жизни? А работа. Да как на экзамене, на шару че-нить и проскочит ))
Я сейчас не беру сложные специальности, типа врача, микробиолога или физика-ядерщика.
НЛО прилетело и опубликовало эту надпись здесь
Не очень я понял ваш комментарий.
Руководству компании безразличен код, стаж, разные умения, глаза, дедлайны и прочее. Главный фактор — профит. Сейчас, к сожалению, от студентов профита почти нет. Как и от людей без опыта. С опытом, правда, еще решить как-то можно еще.
Студент на частичную занятость из шести оплаченных месяцев три будет отсутствовать, ему надо подобрать проект, который все же приносит денег, организовать рабочее место, обеспечить зп и социальные гарантии, выделить ментора. Со стороны студента зачастую имеем пофигительское отношение ко всему этому и также четкое утверждение, что ему все вокруг должны. Ну книгу-то он прочитал же и диплом красный корячится. А если в итоге не смог, то спрос маленький, два в зачетку — пересдача? Как теперь работодателю потраченное бабло отбить?
Мы бы брали студентов, и берем, но очень-очень мало. Основная масса так себя и ведет, к сожалению. Пока студенты не перестанут заявлять, что им все должны, парируя своим картонным дипломом и знаниями, которые невозможно приложить к практике, ситуация не изменится.
Руководству компании безразличен код, стаж, разные умения, глаза, дедлайны и прочее. Главный фактор — профит. Сейчас, к сожалению, от студентов профита почти нет. Как и от людей без опыта. С опытом, правда, еще решить как-то можно еще.
Студент на частичную занятость из шести оплаченных месяцев три будет отсутствовать, ему надо подобрать проект, который все же приносит денег, организовать рабочее место, обеспечить зп и социальные гарантии, выделить ментора. Со стороны студента зачастую имеем пофигительское отношение ко всему этому и также четкое утверждение, что ему все вокруг должны. Ну книгу-то он прочитал же и диплом красный корячится. А если в итоге не смог, то спрос маленький, два в зачетку — пересдача? Как теперь работодателю потраченное бабло отбить?
Мы бы брали студентов, и берем, но очень-очень мало. Основная масса так себя и ведет, к сожалению. Пока студенты не перестанут заявлять, что им все должны, парируя своим картонным дипломом и знаниями, которые невозможно приложить к практике, ситуация не изменится.
НЛО прилетело и опубликовало эту надпись здесь
А ещё студенты через полгода-год работы мнут себя «Синёрами» и пофигу сколько сил уже вложила фирма в его обучение. Легко срываются на другую работу с +$100-200 профита.
А вот тут фирма сама виновата, если договор соответствующим образом не заключила и/или пропустила момент, когда за полученные на фирме знания другие готовы платить больше.
Или изначально стала платить/вкладывать неоправданно много. Хотя я не знаю ситуацию на рынке и не могу сказать есть ли много людей, готовых работать на первых порах за знания и опыт, ну и «за еду» (причём ближе к «доширакам», чем к ресторанам) и работа которых хотя бы знания и «еду» компенсирует за месяц-другой.
Или изначально стала платить/вкладывать неоправданно много. Хотя я не знаю ситуацию на рынке и не могу сказать есть ли много людей, готовых работать на первых порах за знания и опыт, ну и «за еду» (причём ближе к «доширакам», чем к ресторанам) и работа которых хотя бы знания и «еду» компенсирует за месяц-другой.
НЛО прилетело и опубликовало эту надпись здесь
Кстати, встречал такой интересный ход: фирма организовывала «курсы» прямо у себя в рабочее время и типа давала стажерам типа займа на него. «Курсы» по сути заключались в том, что ведущий возился с этими стажерами, объясняя, например, плюсы и минусы разных вариантов реализаций, а не как бывает «на Фаулера и ГоФ — читай»), а их стоимость рассчитывалась как стоимость времени этого ведущего, потраченного на объяснения.
Мы пробовали делать что-то такое, только на халяву. Выпускники ничего не должны были платить за курсы, получали сколько-то даже, но после каждого месяца курсов менторы решали кого оставить. Так три круга Ада, как мы их прозвали. Те, кто прошли три месяца обучения и были одобрены менторами, получали предложение начать работать.
Но система себя не оправдала, сейчас точно не помню, но отсев был просто колоссальным.
Но система себя не оправдала, сейчас точно не помню, но отсев был просто колоссальным.
НЛО прилетело и опубликовало эту надпись здесь
А есть ли вообще приличные курсы, где можно поднять квалификацию программисту? Я вот сколько не искал ничего стоящего на глаза не попадолось — или явно для начинающих, или отзывы по типу «развод, маны пересказывают» при внешне интересно выглядящей программе.
НЛО прилетело и опубликовало эту надпись здесь
Посмотрел курсы на ZCE от «Специалист»:
В этом курсе рассматриваются особо сложные темы (выделено мною), такие как шаблоны проектирования (Design patterns) (Синглтон, Фабрика, Стратегия — добавлено мною), отражения (Reflection), PDO, шаблон MVC (Model-View-Controller), без овладения которыми немыслима профессиональная разработка приложений на PHP.
По окончании курса Вы будете уметь:
Использовать шаблоны проектирования
Использовать PDO для работы с базами данных
Использовать функционал Standard PHP Library
Применять шаблон проектирования MVC
Уметь отлаживать и тестировать PHP-код
Создавать и использовать документацию своего проекта
Использовать Регулярные выражения и Пространства имен PHP
Это пик того, что предлагается при подготовке, и курс с нуля до этого стоит 80к для организаций (128 часов аудиторных занятий). Платить за это 24к (если 30/70) как-то не хочется. За такие деньги я ожидал бы что-то вроде:
— нагрузочное тестирование, профилирование, выявление узких мест «достойных» оптимизации
— выбор политики кэширования (инструменты, уровни, алгоритмы инвалидации)
— горизонтальное масштабирование, распределение нагрузки, решение проблемы сессий, блокировок БД и других разделяемых ресурсов
— инструменты и методики эффективной командной работы (CI, всякие Agile и т. п.)
И «курсовик» с хорошим code review как выпускная работа. На подобный курс даже кредит бы взял в сотню тысяч за свой счёт и думаю проблем особых с «возвратом инвестиций» не было бы. Ничего подобного не встречали?
Английский да, полезная штука, но имхо, не английскому надо учить джуниора, который «не знает чем интерфейс отличается от абстрактного класса».
В этом курсе рассматриваются особо сложные темы (выделено мною), такие как шаблоны проектирования (Design patterns) (Синглтон, Фабрика, Стратегия — добавлено мною), отражения (Reflection), PDO, шаблон MVC (Model-View-Controller), без овладения которыми немыслима профессиональная разработка приложений на PHP.
По окончании курса Вы будете уметь:
Использовать шаблоны проектирования
Использовать PDO для работы с базами данных
Использовать функционал Standard PHP Library
Применять шаблон проектирования MVC
Уметь отлаживать и тестировать PHP-код
Создавать и использовать документацию своего проекта
Использовать Регулярные выражения и Пространства имен PHP
Это пик того, что предлагается при подготовке, и курс с нуля до этого стоит 80к для организаций (128 часов аудиторных занятий). Платить за это 24к (если 30/70) как-то не хочется. За такие деньги я ожидал бы что-то вроде:
— нагрузочное тестирование, профилирование, выявление узких мест «достойных» оптимизации
— выбор политики кэширования (инструменты, уровни, алгоритмы инвалидации)
— горизонтальное масштабирование, распределение нагрузки, решение проблемы сессий, блокировок БД и других разделяемых ресурсов
— инструменты и методики эффективной командной работы (CI, всякие Agile и т. п.)
И «курсовик» с хорошим code review как выпускная работа. На подобный курс даже кредит бы взял в сотню тысяч за свой счёт и думаю проблем особых с «возвратом инвестиций» не было бы. Ничего подобного не встречали?
Английский да, полезная штука, но имхо, не английскому надо учить джуниора, который «не знает чем интерфейс отличается от абстрактного класса».
Подвох простой — в любой день можно получить прощальное письмо. Это сразу отличает тех кто пришёл половить халяву, играя в косынку, и тех, кто заинтересован.
И это не курсы для сотрудников, это программа, которую хотели ввести для приёма людей, которые только — только встали на путь разработчиков (закончили колледж — graduate developer, как мы их называем).
И это не курсы для сотрудников, это программа, которую хотели ввести для приёма людей, которые только — только встали на путь разработчиков (закончили колледж — graduate developer, как мы их называем).
По-русски, кажется, квалификация «техник-программист» (среднее профессиональное образование).
Колледж — это высшее. Степень бакалавра. Хотя, возможно не всюду так.
Это, наоборот, исключение.
б) колледж — среднее специальное учебное заведение, реализующее основные профессиональные образовательные программы среднего профессионального образования базовой подготовки и программы среднего профессионального образования углубленной подготовки.
б) колледж — среднее специальное учебное заведение, реализующее основные профессиональные образовательные программы среднего профессионального образования базовой подготовки и программы среднего профессионального образования углубленной подготовки.
Это в российской системе образования. В нашей же всё наоборот:
In the United States and Ireland, «college» and «university» are loosely interchangeable
На пример PhD по робототехнике в великобританском колледже www.kcl.ac.uk/prospectus/research/index/name/robotics/alpha/ABC/header_search//keyword/computer-science
In the United States and Ireland, «college» and «university» are loosely interchangeable
На пример PhD по робототехнике в великобританском колледже www.kcl.ac.uk/prospectus/research/index/name/robotics/alpha/ABC/header_search//keyword/computer-science
Так у вас чисто обучение было или всё же текущие задачи они решали под чутким руководством старших товарищей?
Каждый день пол для обучение, вторая половина работа в командах над задачами, которые у нас уже решены, но мы не очень довольны результатами. Одновремено практива и потенциальная польза.
Была такая корыстная мысль, что кто-то из них случайно найдёт решение лучше. Не нашли.
Была такая корыстная мысль, что кто-то из них случайно найдёт решение лучше. Не нашли.
А причем тут я? )
Я просто констатирую факт на основе знакомства со многими такими вчерашними студиозами. Фирма тоже виновата, но от этого ЧСВ отдельных студентов меньше не становиться :)
Я просто констатирую факт на основе знакомства со многими такими вчерашними студиозами. Фирма тоже виновата, но от этого ЧСВ отдельных студентов меньше не становиться :)
У нас курсы до 100К размазывают равными долями на полгода, больше — на год.
Почти во всех договорах есть такой пунктик. Про возмещение стоимости потраченной на обучение сотрудника. Для себя решил что если вдруг «пошлют на курсы», то потребую какую — нибудь офф бумагу из бухгалтерии где будет четко прописано «сколько я должен компании за этот жизненно необходимый мне курс». А вообще считаю сей пункт большим свинством. Обучение сотрудников идет на пользу компании, по крайней мере они так думают ибо за просто так ничего бы не делали. А при увольнении удерживать деньги за эти самые курсы это нищебродство какое-то.
Ну а вдруг вы пройдёте курсы, получите сертификат и тут же уйдёте к конкурентам?
Не при увольнении, а при увольнении раньше срока, который вы определяете до обучения (и есть право отказаться же). Компания вас обучила — надо отработать. И это нормально.
Две недели, допустим, курсы — вам платят зп, хотя вы не работаете, за вас работает кто-то другой. Плюс подарок в виде месячной (двух, трех, четырех) зп в качестве оплаты за эти курсы.
Обучение идет на пользу в первую очередь вам. А как вы сумеете применить эти знания на пользу компании — это еще спорный вопрос. А вдруг не сумеете. Или вообще решите, что надо уволиться. Как же быть с этой зп, которая ни за что и с этим подарком?
Если сотрудник ценный и нужный, а его на старом месте держит лишь «курсовая кабала», то видел много примеров, когда новый работодатель просто проводит реструктуризацию долга и сам все выплачивает, зачастую безвозмездно.
Две недели, допустим, курсы — вам платят зп, хотя вы не работаете, за вас работает кто-то другой. Плюс подарок в виде месячной (двух, трех, четырех) зп в качестве оплаты за эти курсы.
Обучение идет на пользу в первую очередь вам. А как вы сумеете применить эти знания на пользу компании — это еще спорный вопрос. А вдруг не сумеете. Или вообще решите, что надо уволиться. Как же быть с этой зп, которая ни за что и с этим подарком?
Если сотрудник ценный и нужный, а его на старом месте держит лишь «курсовая кабала», то видел много примеров, когда новый работодатель просто проводит реструктуризацию долга и сам все выплачивает, зачастую безвозмездно.
Я именно для этого учился 5 лет в универе и пахал на работах по ночам чтобы оплатить учебу в перерывах читая книги по тер. веру и мат анализу, посадил зрение и заработал скалеоз
А кто вам виноват, что вы получали невостребованные на рынке знания или, хотя бы, не получили хоть какой-то опыт реальной работы по специальности? Вы определялись с тем какие знания нужны для желаемой работы? Проверяли выбранный вуз на то, даёт ли он эти знания? Получали ли «дельту» самостоятельно?
Вообще, положа руку на сердце, если вы учились на программиста (специальность «Программное обеспечение вычислительной техники и автоматизированных систем»), то способны были после получения диплома осуществлять «проектирование, разработку и производство программного обеспечения, как промышленной продукции, удовлетворяющей заданным функциональным, конструктивным и технологическим требованиям»? Я вот разрабатывать программное обеспечение худо-бедно могу, но не как промышленную продукцию. И потому периодически вместо зарабатывания денег ищу фирму, где могут этому научить в ходе работы, потому что не верю в способность нашего образования этому научить, включая и вузы, и многочисленные курсы а-ля «php за 24 часа». Деньги кончаются — ищу где бы денег заработать просто на разработке ПО, зарабатываю и по новой ищу где-бы научиться.
А кто вам виноват, что вы получали невостребованные на рынке знания или, хотя бы, не получили хоть какой-то опыт реальной работы по специальности? Вы определялись с тем какие знания нужны для желаемой работы? Проверяли выбранный вуз на то, даёт ли он эти знания? Получали ли «дельту» самостоятельно?
Вообще, положа руку на сердце, если вы учились на программиста (специальность «Программное обеспечение вычислительной техники и автоматизированных систем»), то способны были после получения диплома осуществлять «проектирование, разработку и производство программного обеспечения, как промышленной продукции, удовлетворяющей заданным функциональным, конструктивным и технологическим требованиям»? Я вот разрабатывать программное обеспечение худо-бедно могу, но не как промышленную продукцию. И потому периодически вместо зарабатывания денег ищу фирму, где могут этому научить в ходе работы, потому что не верю в способность нашего образования этому научить, включая и вузы, и многочисленные курсы а-ля «php за 24 часа». Деньги кончаются — ищу где бы денег заработать просто на разработке ПО, зарабатываю и по новой ищу где-бы научиться.
Промышленные подходы в разработке ПО на территории бывшего СНГ не преподаются. Просто некому.
То есть они вообще не используются в СНГ в принципе и я ищу чёрную кошку, которой нет?
Весь прикол в том, что промышленные подходы диктует не программирование, а экономика. Другими словами, необходимо прочитать базовый курс лекций по экономике, прежде чем приступать к принципам промышленной разработки. Иначе все слова будут совершенно непонятными для студентов.
Приведу простой пример, как коммандная разработка. Работа в комманде требует от реализации соблюдения определенных принципов, как соглашения о стиле кода, разделение ответственности через интерфейсы, создания формализованных протоколов обмена информацией, и так далее. Фактически, задачу можно сделать и без всех этих наворотов, просто реализовав ее в лоб. Но как только потребуется организовать процесс разработки, проблемы вылезут сами.
Резюмирую. Промышленная разработка требует соблюдения множества правил, которые продиктованы эффективностью производства кода и функционированию компании в целом
Приведу простой пример, как коммандная разработка. Работа в комманде требует от реализации соблюдения определенных принципов, как соглашения о стиле кода, разделение ответственности через интерфейсы, создания формализованных протоколов обмена информацией, и так далее. Фактически, задачу можно сделать и без всех этих наворотов, просто реализовав ее в лоб. Но как только потребуется организовать процесс разработки, проблемы вылезут сами.
Резюмирую. Промышленная разработка требует соблюдения множества правил, которые продиктованы эффективностью производства кода и функционированию компании в целом
Интуитивно я это понимаю. Подозреваю, что в фирмах типа Яндекса или Абби такая промышленная разработка имеет место быть. Знаю что, во многих веб-студиях ею не пахнет, по сути каждая задача решается в лоб, возможно с повторным использованием кода где-то, хорошо если VCS, но и всё пожалуй. Вот только не знаю как научиться той же работе в команде (не просто формально «нас 5 человек и мы делаем один продукт», а «правильной»).
в Воронеже хватит, например. Снял квартиру за 4к + коммунальные (при стандартной цене 7-8), хорошая квартира, только нет ни газа, ни горячей воды, ни душа (поэтому и спрос нулевой). Приобрел таз и кипятильник. 5к в общем выходит за квартиру. Год так прожил — купил бойлер, кладовку обили пластиком, поставили раковину ножную, провели трубы — заимел душ. Теперь за 5к имею квартиру с душем, короче, удобства.
Согласен, вариант утопический, чтоб его советовать, но еще куча квартир без душа, сделанных из старых гостиниц. Если вообще надо уложиться срочно в N < «малоденег», есть тоже куча бывших общаг, где сдают автономные комнаты, но душ там, например, общий на несколько комнат.
Но опять же, если не хватает денег — нужно утянуть пояс потребностей и искать варианты попроще, 15к для этого в большинстве городов России хватит.
Согласен, вариант утопический, чтоб его советовать, но еще куча квартир без душа, сделанных из старых гостиниц. Если вообще надо уложиться срочно в N < «малоденег», есть тоже куча бывших общаг, где сдают автономные комнаты, но душ там, например, общий на несколько комнат.
Но опять же, если не хватает денег — нужно утянуть пояс потребностей и искать варианты попроще, 15к для этого в большинстве городов России хватит.
>Снял квартиру за 4к + коммунальные (при стандартной цене 7-8)
Зависть, у меня просто коммунальные 6200 примерно.
Зависть, у меня просто коммунальные 6200 примерно.
4К, да даже 7-8 — люто завидую. При цене в 7-8К я бы снял квартиру поближе к работе, просто чтобы не тратить на дорогу деньги, а то через полгорода ездить тяжковато каждый раз.
По молодости снимали с женой жилье за 11К (2007й год) и это был еще хороший вариант. Жена правда работала в трех кварталах (потому и выбрали). А мне на работу минимум час добираться, так это был еще далеко не самый край географии. Двух з/п нам хватало в принципе. Не шиковали конечно, но и нужды особо не испытывали. Зато опыта набирались (оба работали на первых работах). Потом появилась машина и мы перебрались в пригород, где потише и подешевле все. До работы правда пришлось ездить 50км, зато с комфортом и без пробок почти.
Начинать всегда приходиться с малого. Такова жизнь.
По молодости снимали с женой жилье за 11К (2007й год) и это был еще хороший вариант. Жена правда работала в трех кварталах (потому и выбрали). А мне на работу минимум час добираться, так это был еще далеко не самый край географии. Двух з/п нам хватало в принципе. Не шиковали конечно, но и нужды особо не испытывали. Зато опыта набирались (оба работали на первых работах). Потом появилась машина и мы перебрались в пригород, где потише и подешевле все. До работы правда пришлось ездить 50км, зато с комфортом и без пробок почти.
Начинать всегда приходиться с малого. Такова жизнь.
50 км — за городом? Да это же вообще около 5-7 населенных пунктов между работой и домом. Или для ДС это норм?
Ну во-первых 50км это не от города до города, а от порога до порога. Во-вторых 50 около 25 по городу. И да, я три населенных пункта по пути миновал. Это кстати не ДС. Речь про Ростов-на-Дону. А жил я в Новочеркасске. У нас в компании трое оттуда ездили. При этом в силу специфики транспортной системы я доезжал быстрее, чем народ из других районов собственно Ростова, ибо пробки. У нас это довольно распространенное явление (как наверное во всех крупных городах). БольшАя часть населения городов и деревень в радиусе 30 км от города работает тут. У нас в компании около 30%, как бы сказали в ДС, замкадыши. Хотя все эти города и деревеньки официально считаются Ростовской агломерацией.
НЛО прилетело и опубликовало эту надпись здесь
Видимо, компании были недостаточно крупные. В достаточно крупных компаниях зарплата junior'а — это все-таки не 15к (правда, с тем, чем отличается абстрактный класс от интерфейса, придется разбираться до того, как идти на собеседование). И речь не только о Мск.
О, привет, земляк. Надо было стиснув зубы за 15 тыщ пару лет поработать. Все мои знакомые офигенные программеры так и начинали. И сейчас они — офигенные программеры с нормальной зарплатой в Иркутске. Я не в счет :)
Серьезно что ли? Ни одно головоломки на собеседовании я не услышал) А вот технические вопросы и хорошие рассуждения как сделать что-то – выше крыши.
Это называется «культ Карго». Почитайте в Гугле. Если вкратце — бездумное повторение, без понимания принципов.
В Гугле их уже несколько лет как не задают.
Что у них неплохо кроме поиска?
А там фокус в том, что сначала отсекают тех, кто не умеет писать код. Все равно больше, чем нужно. И уж *тогда* идут головоломки.
Что можно Юпитеру, то не дозволено быку. Мода играть с HRными финтами нынче повальна, а уровень проектов такой как у Гугла… хотя бы у 1 из 10 контор? )))
НЛО прилетело и опубликовало эту надпись здесь
У вас звездочка в последнем обсценном слове совсем не справляется со своей функцией
Учитывая то, что «хер» — это не обсценное слово, нормально.
Кстати, для многих становится открытием, что слово «хер» происходит от буквы Х (хер) кириллицы. Соответственно слова «похерить» или «перехерить» — обозначает что-то перечеркнуть, удалить. Употреблялось, например, выражение «перечеркнуть красным хером». Почему «хер» и другое слово из трех букв вдруг стали синонимами — неизвестно.
Кстати, для многих становится открытием, что слово «хер» происходит от буквы Х (хер) кириллицы. Соответственно слова «похерить» или «перехерить» — обозначает что-то перечеркнуть, удалить. Употреблялось, например, выражение «перечеркнуть красным хером». Почему «хер» и другое слово из трех букв вдруг стали синонимами — неизвестно.
Выражение «слово на букву хер» сократилось до «хер».
Где-то встречал тезис (был какой-то программист, много общавшийся с бухгалтерией), что похерить — это тоже самое, что покрыжить, только под углом 45 градусов.
Да, я когда от бухгалтеров услышал что галочка чекбокса — это «крыжик», очень веселился.
Вообще в бух учете «крыжить» означает ставить крестики или галочки при сверке документов. Как сюда угол можно применить?
Нашел таки ссылку на те записки. Вот этот фрагмент:
Разбирали с программистом бухгалтерский сленг. Пришлось даже залезть в Даля, чтобы выяснить происхождение некоторых слов. Выяснилось, что «крыжить» происходит от «крыж», то есть крест, и исходно значило «помечать крестом», хотя сейчас большинство бухгалтеров крыжат галочками. Заодно разобрали слово «херить», происходящее от «хер», старого названия буквы Х, и означающее по Далю перечеркивать или помечать косым крестом. Программист подумал и сделал вывод, что херить – это крыжить под углом пи на 4.
Крестик может быть вертикальным, а может быть повёрнытым :)
А я с первого раза прочитал, что это x* p — переменная-указатель p на тип x. И вроде вписалось в концепцию «абстрактные классы/интерфейсы» =)
Чем абстрактный класс отличается от интерфейса — это ещё ерунда…
На собеседованиях по PHP тогда нужно спрашивать, чем
Или на собеседованиях по JS спрашивать, как реализовать прототипное наследование…
Чем больше таких вот вопросов задается, чем больше у людей создается ощущение, что эти знания обязательно нужно использовать в повседневной работе, хотя всё как раз наоборот: чем меньше «наворотов» в коде и чем он проще — тем лучше, а не наоборот. Простой код легче писать, легче отлаживать и легче поддерживать. Знание тонкостей языка хорошо лишь тогда, когда требуется разобраться в проблеме, но не для того, чтобы писать новый код.
На собеседованиях по PHP тогда нужно спрашивать, чем
$arr1 + $arr2 отличается от array_merge($arr1, $arr2)Или на собеседованиях по JS спрашивать, как реализовать прототипное наследование…
Чем больше таких вот вопросов задается, чем больше у людей создается ощущение, что эти знания обязательно нужно использовать в повседневной работе, хотя всё как раз наоборот: чем меньше «наворотов» в коде и чем он проще — тем лучше, а не наоборот. Простой код легче писать, легче отлаживать и легче поддерживать. Знание тонкостей языка хорошо лишь тогда, когда требуется разобраться в проблеме, но не для того, чтобы писать новый код.
Такие сложные навороты, конечно, использовать в коде не нужно. Но именно эти навороты получше любых головоломок показывают на сколько граблей кандидат уже наступил и сколько опыта у него за плечами.
Для PHP я наверное не самый адекватный пример привел, но я имел в виду, что не нужно задавать типовые вопросы, если хочется понять, насколько человек опытен. Проблема с ними в том, что они ничего не показывают — человек может просто подготовиться к собеседованию и заучить ответы на типовые вопросы. Я бы не стал давать советы по тому, как надо правильно подбирать людей, но просто хотел озвучить те вещи, с которыми мне пришлось столкнуться, когда я искал работу.
Мы вообще плюнули на типовые вопросы и даем оплачиваемые тестовые задания на 3-5 рабочих дней. Естественно, подходит только тем, кто активно ищет работу и сейчас не работает, но в целом, позволяет гораздо лучше отсеивать людей. Собеседование при таком раскладе можно вообще провести в скайпе, а личную встречу сократить к минимальной необходимой, чтобы просто посмотреть на самого человека.
Само по себе собеседование требуется не для того, чтобы оценить уровень кандидата — для этого вполне подойдет испытательный срок — а для того, чтобы понять насколько человек впишется в команду.
Кроме совсем уж вопиющих случаев, я бы сказал, что это задача как раз для испытательного срока (впишется ли в команду). Можно, конечно, покорчить из себя психолога, но это все профанация, обычно.
Мое мнение — для проверки скилов — тестовое задание, для проверки, впишется ли в команду — испытательный срок. Принимать решение по обоим пунктам после собеседования имеет смысл только в случае, если нет возможности уделять кандидату много времени (или у него нет возможности тратить время на потенциального работодателя).
Мое мнение — для проверки скилов — тестовое задание, для проверки, впишется ли в команду — испытательный срок. Принимать решение по обоим пунктам после собеседования имеет смысл только в случае, если нет возможности уделять кандидату много времени (или у него нет возможности тратить время на потенциального работодателя).
Я прошу прощения, но «чем абстрактный класс отличается от интерфейса» всё-таки не «тонкость языка», а азбука ООП. Разве нет? (Я даже не программистом работаю, если что.)
Всё от контекста зависит. Главное уловить какой контекст имеет в виду собеседующий.
В случае с Java (или другими сильно ООП-языками) это наверное так. В случае с динамическими языками я бы не был так категоричен. Более того, это знание при программировании на том же PHP вам скорее всего понадобится очень нескоро.
У меня есть несколько вариантов ответа насчёт абстрактного класса и интерфейса (в зависимости от контекста), я примерно представляю себе как реализовывать прототипное наследование в JS и при наличии под рукой консольного интерпретатора JS или Firebug минут за 15 подберу рабочий синтаксис, с PHP я вообще никогда не работал, но и там есть несколько вариантов какие в принципе бывают варианты сложения/объединения двух массивов и какие могут возникнуть проблемы в обоих случаях.
Я полностью согласен с Вами в том, что писать простой код жизненно необходимо!
Тем не менее, что-то не даёт мне согласится с тем, что для написания простого кода знание тонкостей языка не нужно или даже вредно. Использовать эти тонкости — действительно зачастую не требуется, но знать их надо.
Безусловно, чтобы узнать эти тонкости — необходимо некоторое время их использовать. Я прекрасно помню то время, когда я изучал перл, и из всех сил искал возможности применить новые возможности в текущих проектах, даже там, где без этого можно было обойтись, и где эти новые возможности только всё излишне усложняли. Можно расценивать это как недостаток, но, на мой взгляд, это просто цена, которую неизбежно требуется платить за получение опыта и повышение квалификации.
Не зная тонкостей языка — нельзя знать и где их уместно применять, а где нет. А значит либо приходится искусственно ограничивать возможности своего основного инструмента (т.е. заведомо менее эффективно делать свою работу), либо применять всю мощь без реального понимания и оценки уместности и последствий.
Можно не знать тонкости языка, на котором пишешь мало и редко, но если квалифицированный профессионал (а ведь речь о них!) за несколько лет работы не удосужился разобраться в тонкостях языка, который все эти годы использовал — возникает вопрос, а квалифицированный ли он и профессионал ли?
На мой взгляд, есть громадная разница между двумя людьми, пишущими один и тот же идеальный код — если один его пишет так потому, что не умеет писать иначе, а другой потому, что может показать несколько альтернативных вариантов реализации этой же функциональности и аргументированно объяснить, почему в данном случае предпочтительнее именно этот вариант.
Резюмируя: знать тонкости используемых инструментов необходимо, если вы считаете себя квалифицированным профессионалом достойным интересной работы и высокой зарплаты. А вот использовать все эти тонкости в большинстве случаев действительно не требуется и даже вредно — но если вы настолько хороши, насколько сами думаете, то вы это и сами должны понимать. Поэтому задавать такие вопросы на собеседовании вполне уместно.
Я полностью согласен с Вами в том, что писать простой код жизненно необходимо!
Тем не менее, что-то не даёт мне согласится с тем, что для написания простого кода знание тонкостей языка не нужно или даже вредно. Использовать эти тонкости — действительно зачастую не требуется, но знать их надо.
Безусловно, чтобы узнать эти тонкости — необходимо некоторое время их использовать. Я прекрасно помню то время, когда я изучал перл, и из всех сил искал возможности применить новые возможности в текущих проектах, даже там, где без этого можно было обойтись, и где эти новые возможности только всё излишне усложняли. Можно расценивать это как недостаток, но, на мой взгляд, это просто цена, которую неизбежно требуется платить за получение опыта и повышение квалификации.
Не зная тонкостей языка — нельзя знать и где их уместно применять, а где нет. А значит либо приходится искусственно ограничивать возможности своего основного инструмента (т.е. заведомо менее эффективно делать свою работу), либо применять всю мощь без реального понимания и оценки уместности и последствий.
Можно не знать тонкости языка, на котором пишешь мало и редко, но если квалифицированный профессионал (а ведь речь о них!) за несколько лет работы не удосужился разобраться в тонкостях языка, который все эти годы использовал — возникает вопрос, а квалифицированный ли он и профессионал ли?
На мой взгляд, есть громадная разница между двумя людьми, пишущими один и тот же идеальный код — если один его пишет так потому, что не умеет писать иначе, а другой потому, что может показать несколько альтернативных вариантов реализации этой же функциональности и аргументированно объяснить, почему в данном случае предпочтительнее именно этот вариант.
Резюмируя: знать тонкости используемых инструментов необходимо, если вы считаете себя квалифицированным профессионалом достойным интересной работы и высокой зарплаты. А вот использовать все эти тонкости в большинстве случаев действительно не требуется и даже вредно — но если вы настолько хороши, насколько сами думаете, то вы это и сами должны понимать. Поэтому задавать такие вопросы на собеседовании вполне уместно.
Крик души.
Плюсую! Именно поэтому я собрал команду, и мы начали заниматься построением Community в Питере:
1. Мы перезапустили Java User Group — jug.ru и
2. cделали сообщество CodeFreeze — codefreeze.ru
Мы стараемся действовать именно в «хардкорном» стиле с минимумом плюшек и максимумом полезного.
Почти одновременно с нами девчонки из DataArt запустили в питере IT-Talk: it-talk.spb.dataart.ru/?page_id=9
Они чуть менее хардкорны, зато у них народу пока побольше. Мы дружим с ними и обмениваемся опытом.
Короче, работа ведётся. В Питере — нами. В планах поднять/реанимировать не только JUG, но и другие User Groups.
Кстати, если кто-то из хабровчан хочет заняться Community-работой — пишите мне: подскажу направление, дам пинок etc.
1. Мы перезапустили Java User Group — jug.ru и
2. cделали сообщество CodeFreeze — codefreeze.ru
Мы стараемся действовать именно в «хардкорном» стиле с минимумом плюшек и максимумом полезного.
Почти одновременно с нами девчонки из DataArt запустили в питере IT-Talk: it-talk.spb.dataart.ru/?page_id=9
Они чуть менее хардкорны, зато у них народу пока побольше. Мы дружим с ними и обмениваемся опытом.
Короче, работа ведётся. В Питере — нами. В планах поднять/реанимировать не только JUG, но и другие User Groups.
Кстати, если кто-то из хабровчан хочет заняться Community-работой — пишите мне: подскажу направление, дам пинок etc.
Проблема еще и в том, что — таки да — в наших краях как правило software engineer-ами называют «слесарей от IT», а вовсе не инженеров. Тех, кто знают свой «станок» (Java, Linux, etc.), но не Computer Science. Спрос на них — это нормально, ведь бОльшая часть нашего оффшор-девелопмента занимается несложными и достаточно рутинными задачами «по накатанной».
Но при этом очень глупо набирать людей, используя подходы Гугла. Гугл ищет CS инженеров со знанием искусственого интеллекта, матстатистики, анализа алгоритмов etc. Таких имеет смысл спрашивать про головоломки и проверять соображалку. Но это совершенно не работает в наших краях.
В очередной раз имеем Культ Карго — копирование внешнего вида без понимания содержания и целей.
Но при этом очень глупо набирать людей, используя подходы Гугла. Гугл ищет CS инженеров со знанием искусственого интеллекта, матстатистики, анализа алгоритмов etc. Таких имеет смысл спрашивать про головоломки и проверять соображалку. Но это совершенно не работает в наших краях.
В очередной раз имеем Культ Карго — копирование внешнего вида без понимания содержания и целей.
Жаль кармы мало чтобы поставить плюсик. Поэтому одобрю комментом:
> В наших краях как правило software engineer-ами называют «слесарей от IT», а вовсе не инженеров. Тех, кто знают свой «станок» (Java, Linux, etc.), но не Computer Science.
Вот это я себе, наверное, в рамочку повешаю. Самое точно определение проблемы с инженерами, которых в наших краях нет вообще или их штучные количества. В лучшем случае есть разработчики. И всё больше банальных кодеров, которые сидят и пальцы гнут как они круты и что компании должны крутиться вокруг них, а не наоборот.
И когда встаёт задача сделать какую-нибудь систему N, какой-нибудь там фоновый демон или сокет-сервер, тогда начинаются такие пляски с бубном вокруг «любимого и крутейшего PHP» (или чего там ещё любимого и крутейшего), что у меня уже виски поседели на всё это смотреть.
А потом ещё заявляют что, де, «я программист на XXX, а свой YYY можете в жопу засунуть, я на нём делать ничего не буду, и точка»; где XXX — что-нибудь этак из 1970-ых.
Наболело, в общем.
PS: Моё личное желание «свалить» на красивом красном тракторе, кстати, вызвано не столько политическими диктаторскими замашками всяких там национальных лидеров, как у многих, сколько вот этим вакуумом достойных собеседников и соперников на техническом поприще. Хочется уже немного challenge'а.
> В наших краях как правило software engineer-ами называют «слесарей от IT», а вовсе не инженеров. Тех, кто знают свой «станок» (Java, Linux, etc.), но не Computer Science.
Вот это я себе, наверное, в рамочку повешаю. Самое точно определение проблемы с инженерами, которых в наших краях нет вообще или их штучные количества. В лучшем случае есть разработчики. И всё больше банальных кодеров, которые сидят и пальцы гнут как они круты и что компании должны крутиться вокруг них, а не наоборот.
И когда встаёт задача сделать какую-нибудь систему N, какой-нибудь там фоновый демон или сокет-сервер, тогда начинаются такие пляски с бубном вокруг «любимого и крутейшего PHP» (или чего там ещё любимого и крутейшего), что у меня уже виски поседели на всё это смотреть.
А потом ещё заявляют что, де, «я программист на XXX, а свой YYY можете в жопу засунуть, я на нём делать ничего не буду, и точка»; где XXX — что-нибудь этак из 1970-ых.
Наболело, в общем.
PS: Моё личное желание «свалить» на красивом красном тракторе, кстати, вызвано не столько политическими диктаторскими замашками всяких там национальных лидеров, как у многих, сколько вот этим вакуумом достойных собеседников и соперников на техническом поприще. Хочется уже немного challenge'а.
> где XXX — что-нибудь этак из 1970-ых.
Так а даже если из 2010-х — нет никакой разницы. Языки программирования, фреймворки, технологии — это просто инструменты. Возводить инструмент в ранг религии — абсурд. Никто же не станет закручивать шурупы молотком, потому что «у него такая офигенная ручка, намного круче, чем у отвертки». А в IT такое — сплошь и рядом.
По-хорошему, над инструментами должна быть алгоритмика. И труъ-инженер должен быть специалистом как раз в алгоритмике — для решения сложных задач.
Но когда сложных задач нет и не предвидется, и алгоритмика простая как двери, все что остается — канонизация технологий :-(
Так а даже если из 2010-х — нет никакой разницы. Языки программирования, фреймворки, технологии — это просто инструменты. Возводить инструмент в ранг религии — абсурд. Никто же не станет закручивать шурупы молотком, потому что «у него такая офигенная ручка, намного круче, чем у отвертки». А в IT такое — сплошь и рядом.
По-хорошему, над инструментами должна быть алгоритмика. И труъ-инженер должен быть специалистом как раз в алгоритмике — для решения сложных задач.
Но когда сложных задач нет и не предвидется, и алгоритмика простая как двери, все что остается — канонизация технологий :-(
Нормальные специалисты есть, их много, они хорошо получают и редко меняют работу в виду отсутствия такой необходимости. И если Вы не встречаете вызовов, советую поменять место работы…
Когда надо написать демон или сервер, я спрашиваю у заказчика согласен ли он ждать (и частично оплачивать) пока я разберусь скажем с, C++ или лучше быстро (и дешевле) написать на PHP. Не один ждать не захотел.
Мир полон языков гораздо более высокого уровня, позволяющих быстрое прототипирование (в чём PHP несомненно хорош), но работающих за рамках подхода «request-response» без костылей (ну, почти). Python тот же. Его даже в убунтах всяких используют для GUI местами. Erlang. Ruby. А на C/C++ сейчас решают только сверх-специфичные задачи, типа мега-гига-нагрузок или мини-нано-памяти или чего-то такого.
Собственно, вы сами привели пример такого «слесаря от IT», который кроме свеого любимого и прекрасного культового языка ничего учить не хочет, и находит отмазки почему бы это не делать далее. Без обид.
Собственно, вы сами привели пример такого «слесаря от IT», который кроме свеого любимого и прекрасного культового языка ничего учить не хочет, и находит отмазки почему бы это не делать далее. Без обид.
Веб-интерфейсы я прототипирую на рельсах, GUI и CLI утилитки пишу на Python, Erlang с Nitrogen, каюсь, не осилил, если что-нибудь одно, то может и смог, а то захотел сразу и язык, и фреймворк, да и мотивации особой не было. И вовсе не считаю PHP, который был, кажется седьмым моим языком, если не считать диалекты и хелловорлды, прекрасным и любимым — он начал меня раздражать 10+ лет назад своим синтаксисом и слишком большой свободой при обращении с типами, но привлёк инфраструктурой. Ещё был вариант Perl изучать, но уж больно он мне write only показался, а PHP почти как любимый (тогда) Си, да и литературы на русском по PHP тогда больше было. Резюме я свои посылаю практически на все Junior вакансии независимо от языка, если не требуется опыт работы и в/о (не закончил, потому что понял, что программировать меня учить не будут, не в тот поток попал), а в «сопроводиловке» прошу выслать тестовое задание на день-два.
Вы душка. Но тогда странно что демон или сервер предлагаете заказчику писать на PHP.
Это единственный язык, на котором я могу писать без постоянного подглядывания в гугл/маны. Язык для которого я гуглю не «как сделать то-то», а «сделал то-то так-то, но работает не так как вроде следует из манов». В конце-концов язык, приложение на котором я разверну на голом сервере опять же без гугла и более-менее понимая что каждая введенная строчка или исправленная в php.ini делает. Я почти не сомневаюсь в своей способности написать демон или сервер на ruby/python/c#/java/js/c/c++, но это явно займёт больше времени из-за поверхностного знания синтаксиса и полного незнания даже стандартных библиотек, не говоря о сторонних. И очень сомневаюсь в своей способности за разумное время самостоятельно разобраться с грамотным деплоем на «голый» сервер, а не дай бог ещё не debian-based. А разворчивать production по хаутушечкам, не понимая что делаю, я отвык лет 10 назад, когда прочитал где-то «поставьте права 777 чтоб работало» и попал на пару тысяч долларов (тогда однушка в Питере 6 стоила).
НЛО прилетело и опубликовало эту надпись здесь
Слишком эмоционально отношусь — отправляю, а потом каждую минуту почту проверяю, день, другой, неделю, потом в депрессию.
Тю, у меня нет ВО, и я по этому поводу абсолютно не комплексую. Обычно я спрашиваю, вам нужно чтобы диплом работал, или человек? Если диплом, то мне с вами не по пути
Там где не написано требования в/о, так редко речь о нём заходит, если только вскользь "- Учились где? — ЛЭТИ, ФАВТ — Хороший вуз — Ага". А где написано так там обычно ещё и требование профильного, а у меня 3 курса да ещё «железячной» специальности, по программированию в вузе максимум «paint» делал на MFC/C++ и «edit» на ассемблере. Ту же теорию алгоритмов, СУБД, ОС, компиляторы и прочее SC не изучали.
Но ведь и ваш годовой доход не так велик?
Последнее время количество вакансий в которых в/о вообще фигурирует стремится к нулю, по крайней мере складывается такое ощущение, ибо постоянным мониторингом не занимаюсь. Зато вот опыт 3-5 лет требуют практически везде.
И приходят потом джуниоры в другие компании, и молвят, что хотят получать (не зарабатывать) $2К… И берут их на работу, потому что лучше плохенький джуниор в офисе, чем профи в Cloud'e…
Печально это все, печально…
Печально это все, печально…
Ага, недавно на работе думали что делать с кодом, который такие решатели головоломок налабали — для примитивной задачи, которую можно было на голом PL/SQL написать — сделано 5 (ПЯТЬ) уровней наследования и все через ORMы с понятным быстродействием.
Хм… а может вы против OOP потому что он «медленный и память жрёт»? 5 уровней для примитивной задачи много, но с другой стороны в обход архитектуры можно много чего индусить «быстро и просто». Кто знает, возможно это вы недооценили задачу (потому что головоломки не решаете :-P)
Если примитивная задача делается в рамках проекта, в котором есть сложившаяся архитектура требующая пяти уровней наследования и использования ORM то все сделано правильно.
5 уровней это не страшно. Если код хороший и некоторые уровни не требуются от слова совсем — их убрать должно быть достаточно просто.
А вот попался мне недавно проектик на 400 000 строчек, которй в течении 10 лет быдлокодили… 3 раздельных системы для учета денег, 6 вариантов отправки писем, 150 табличек в БД, причем на одну сущность иногда встречается до 8 табличек, завязанные через 3-4 уровня связей, 3 админки с разным функционалом. Местами присутствуют классы. есть 4 разных класса с одним именем и три почти одинаковых класса с разными именами.
Работает достаточно быстро, но разобраться в этом достаточно сложно.
А вот попался мне недавно проектик на 400 000 строчек, которй в течении 10 лет быдлокодили… 3 раздельных системы для учета денег, 6 вариантов отправки писем, 150 табличек в БД, причем на одну сущность иногда встречается до 8 табличек, завязанные через 3-4 уровня связей, 3 админки с разным функционалом. Местами присутствуют классы. есть 4 разных класса с одним именем и три почти одинаковых класса с разными именами.
Работает достаточно быстро, но разобраться в этом достаточно сложно.
Мне кажется, вы слишком политкорректны :)
С одной стороны, звучит как ппц, а с другой стороны всё-таки мало того что «работает, так ещё и „работает быстро“… Сколько проектов с хорошей архитектурой не могут этим похвастаться?
Ни одного. Если проект не работает быстро или просто не работает — у него плохая архитектура. В данном случае архитектура плохая, потому что проект изменять адски сложно. Его можно только дописывать, увеличивая нагромождение кода. Любая правка выливается в то, что «тут сменили, а тут, тут и вон там — нет. А еще вот тут вот телефон написан, от которого уже 5 лет как отказались».
Единственная причина, почему его нельзя выкинуть — оно работает. Если бы не работало. сразу бы ушло в корзину.
к большому сожалению, такое положение дел можно наблюдать практически в любой индустрии.
Так это… чем абстрактный класс отличается от интерфейса? ;)
так написано же — никто не знает
Тогда где мои теннисные столы, футболка, айпад и звание Senior`a?
За вышивание крестиком сеньора не дают ;)
Senior Krestik Vishivatel.
Знает всё в области вышивания крестиком. Обучает джуниор вышивателей. Распределяет задания и холст между обычными вышивателями. В принципе, обычные вышиватели знают тоже, что и сеньёр вышиватель, но сеньёр несёт ответственность за общую красоту и прочность холста, за скорость выполнения и адекватность выбора соответствующих нитей и иголок.
Знает разницу между целлофановой калькой-интерфейсом для вышивания рисунка и абстрактным холстом-заготовкой, и очень этим гордится. Иногда сам создаёт как кальки, так и заготовки. Джуниоры вышивают без заготовок — сразу в лоб и с нуля, пришивая к холсту деревянную рамку, собственный рукав, галстук и сдерживающий рисунок скотч, иногда получая за это в тык.
Знает всё в области вышивания крестиком. Обучает джуниор вышивателей. Распределяет задания и холст между обычными вышивателями. В принципе, обычные вышиватели знают тоже, что и сеньёр вышиватель, но сеньёр несёт ответственность за общую красоту и прочность холста, за скорость выполнения и адекватность выбора соответствующих нитей и иголок.
Знает разницу между целлофановой калькой-интерфейсом для вышивания рисунка и абстрактным холстом-заготовкой, и очень этим гордится. Иногда сам создаёт как кальки, так и заготовки. Джуниоры вышивают без заготовок — сразу в лоб и с нуля, пришивая к холсту деревянную рамку, собственный рукав, галстук и сдерживающий рисунок скотч, иногда получая за это в тык.
Интрефейс есть совокупностость методов, описывающая взаимодействие с объектом, и подходит для множественного наследования.
А абстрактный класс, это уже всё-таки класс, который может содержать не только абстрактные методы, но и поля, операторы, шаблонные методы.
А абстрактный класс, это уже всё-таки класс, который может содержать не только абстрактные методы, но и поля, операторы, шаблонные методы.
Интерфейс — класс в котором все методы абстрактные.
Это частный случай, например в С++, т.к. там нет отдельных конструкций для описания интерфейсов. Более того, в С++ достаточно хотя бы одного pure virtual метода, чтобы класс стал абстрактным.
В Java тоже достаточного одного abstract метода, что бы бы класс стал абстрактным и что? Собственно то что меня тут минусуют хорошо показывает, кругозор людей. Хорошо хоть один человек нашелся, который знает что такое C++ и его особенности. Да в C++ есть множественное наследование и нет необходимости в ключевом слове interface как в Java, но сути это не меняет. Интерфейс и есть полностью абстрактный класс, то есть ни один из его методов не имеет реализации.
Мне кажется имелся ввиду более академический (ГОФ/Макконнелл) подход к определениям: любой класс обладает интерфейсом, в то же время полностью абстрактный класс — некоторое его выражение на уровне кода, потому что по смыслу совпадает со стоим интерфейсом.
Вообще вопрос не стоит выделанного яйца и выполняет в статье символическую роль.
Вообще вопрос не стоит выделанного яйца и выполняет в статье символическую роль.
В Java достаточно назвать класс abstract. А вот abstract метод в обычном классе — это ошибка компиляии, да
Собственно то, что вас минусуют, хорошо показывает, что с кругозором у людей, слава аллах-акбару, пока ещё всё в порядке. Ибо вы дали чисто техническое отличие, а вопрос предполагал скорее концептуальное.
«Велосипед — это мотоцикл, у которого отсутствует глушитель»
«Велосипед — это мотоцикл, у которого отсутствует глушитель»
Наверное поэтому и родилась обсуждаемая статья ;-)
Я сформулировал кратко и по-делу. Тот кто не понимает пишет кучу слов о сущности описании сущности и прочие, и прочие, и прочие… Я так тоже могу, но зачем умничать?
И у велосипеда, таки ДА, нет выхлопной трубы ;-)
Я сформулировал кратко и по-делу. Тот кто не понимает пишет кучу слов о сущности описании сущности и прочие, и прочие, и прочие… Я так тоже могу, но зачем умничать?
И у велосипеда, таки ДА, нет выхлопной трубы ;-)
Дело в том, что ваше краткое техническое описание — это всего лишь следствие концепции.
Мое краткое описание — констатация факта. То что куча хабравчан минусует это, лишь доказывает обоснованность обсуждаемой статьи, вот и все.
Да уж, заминусовали аж до -2 :)
А минусуют, думаю, из-за того, что ваша констатация факта отвечает не на тот вопрос, который подразумевается большинством, в том числе и людьми, принимающими собеседования.
И вопрос этот — в чём концептуальная разница между интерфейсами и абстрактными классами? В каких случаях нужно использовать одно, а в каких другое?
И вот в процессе ответа на эти вопросы, ваше краткое техническое описание обычно должно всплыть в разговоре само собой.
А минусуют, думаю, из-за того, что ваша констатация факта отвечает не на тот вопрос, который подразумевается большинством, в том числе и людьми, принимающими собеседования.
И вопрос этот — в чём концептуальная разница между интерфейсами и абстрактными классами? В каких случаях нужно использовать одно, а в каких другое?
И вот в процессе ответа на эти вопросы, ваше краткое техническое описание обычно должно всплыть в разговоре само собой.
Ну вот нет в C++ ключевого слова interface и при этом понятие интерфейса во всю используется C++ разработчиками. Это возможно лишь понимая суть, и как раз понимание того, что интерфейс — полностью абстрактный класс и дает возможность в C++ использовать понятие интерфейса.
А по поводу ожидаемых ответов на собеседовании могу лишь написать большое такое «ОЙ». Прискорбно, если на хабре большинство сидит лишь для того, что бы наблатыкавшись умными словами, успешно пройти собеседование.
А по поводу ожидаемых ответов на собеседовании могу лишь написать большое такое «ОЙ». Прискорбно, если на хабре большинство сидит лишь для того, что бы наблатыкавшись умными словами, успешно пройти собеседование.
И нет свойств/полей/переменных тогда уж.
Дайте я тоже попробую.
Интерфейс — если по сути — всего лишь набор функциональных требований к классам. Плюс в ряде языков интерфейс может служить контейнером для констант.
Интерфейс — если по сути — всего лишь набор функциональных требований к классам. Плюс в ряде языков интерфейс может служить контейнером для констант.
Интерфейс — абстрактный класс, в котором вообще нет реализации, только сигнатуры методов.
Ключевой момент в том, что интерфейс это не класс
В языках где интерфейсов нет как элемента синтаксиса они реализуются через абстрактные классы без свойств и только с абстрактными методами. Интерфейсы — частный случай абстрактных классов, сахар.
А почему не наоборот? По всей логике как раз абстрактные классы — частный случай. Вот прикиньте сколько языков с интерфейсами как отдельными сущностями, и сколько в виде абстрактных классов.
Интерфейс содержит только абстрактные методы., абстрактный класс может содержать и не абстрактные. Интерфейс не может содержать свойства, абстрактный класс — может. Абстрактный класс, если угодно, наследник интерфейса. Что является частным случаем чего?
И вроде во всех мэйнстрим ООП языках либо есть и интерфейсы, и абстрактные классы, либо только абстрактные классы, либо вообще просто классы, а за их абстрактностью и интерфейсностью предлагается следить разработчику.
И вроде во всех мэйнстрим ООП языках либо есть и интерфейсы, и абстрактные классы, либо только абстрактные классы, либо вообще просто классы, а за их абстрактностью и интерфейсностью предлагается следить разработчику.
Можно наследоваться только от одного абстрактного класса, но можно реализовать несколько интерфейсов. То есть, на абстрактные классы наложены более жёсткие ограничения.
В языках, где есть полноценные интерфейсы и полноценные абстрактные классы, это два разных понятия, ни одно из которых не является частным случаем второго.
В языках, где есть полноценные интерфейсы и полноценные абстрактные классы, это два разных понятия, ни одно из которых не является частным случаем второго.
Вы не с той стороны подходите к вопросу. Интерфейс это не синтаксический сахар, это концепция в рассматриваемой парадигме. С точки зрения реализации в конкретном языке интерфейс может быть специальной конструкцией, которая описывает именно интерфейс, либо роль интерфейса выполняет например абстрактный класс. Но при этом само понятие интерфейса никак не является классом само по себе. Абстрактный класс это другая сущность, похожая по функциональным возможностям, и в частных случаях их заменяющая. Если брать в расчет конкретные реализации данной концепции, то никак нельзя сказать, что интерфейс это класс, ибо там где он есть это не класс.
> «Интерфейс не может содержать свойства»
Это еще почему? Что вы называете свойствами?
Это еще почему? Что вы называете свойствами?
Переменные в классе. Это уже реализация.
Поля (fields) и свойства (properties) — разные вещи. Поля это переменные класса, а вот свойства реализованы через два метода: геттер и сеттер.
Это все в терминах C#, но, насколько я знаю, это общепринятая терминология. По крайней мере, в языках, где проперти вообще реализованы.
Это все в терминах C#, но, насколько я знаю, это общепринятая терминология. По крайней мере, в языках, где проперти вообще реализованы.
Там где отдельного сахара для этого нет — синонимами считаются де-факто. Тогда можно переформулировать: «в интерфейсах не может быть полей и реализации свойств», реализации методов естественно тоже быть не может :)
Я думаю, что в интерфейсе вообще не должно быть реализаций по умолчанию, даже для вырожденных случаев типа:
Причина: интерфейс всего лишь говорит о том, что должен делать объект, а предлагать для этого различные реализации (отвечая на вопрос «как») должны абстрактные («как это делают представители данного рода») и обыкновенные («как это делают представители данного вида») классы.
virtual int GetA() = 0;
virtual int GetB() = 0;
virtual int GetAPlusB() {
return GetA() + GetB();
}
Причина: интерфейс всего лишь говорит о том, что должен делать объект, а предлагать для этого различные реализации (отвечая на вопрос «как») должны абстрактные («как это делают представители данного рода») и обыкновенные («как это делают представители данного вида») классы.
Речь не о конкретной реализации — а именно о свойствах о конструкции, неявно использующей getter и setter, как указал Shedal. Выставить наружу часть состояния объекта, или даже дать возможность его изменения — полностью укладывается в концепцию интерфейса. Да, на каком-то уровне это «сахар», но на каком-то уровне все абстрактно.
Кроме public-свойств интерфейс, вполне может определять индексаторы, для обращения к объекту, как к массиву и содержать public-события, на которые можно подписаться. Все это не мешает интерфейсу быть интерфейсом.
Кроме public-свойств интерфейс, вполне может определять индексаторы, для обращения к объекту, как к массиву и содержать public-события, на которые можно подписаться. Все это не мешает интерфейсу быть интерфейсом.
Что является частным случаем чего? Ничто, абстрактный класс и интерфейс существуют параллельно, и решают они разные задачи.
Задачи решаемые интерфейсом можно возложить на абстрактный класс? Имхо, можно (опустим для ясности невозможность множественного наследования в популярных языках где интерфейсы есть). Есть какое-то действие, которое можно произвести с интерфейсом, но нельзя с абстрактным классом?
Интерфейс — один из способов использования абстрактного класса. Соответственно, абстрактный класс — один из способов реализации интерфейса (там, где это возможно). Так что они (точнее, их воплощения в нашем мире) пересекаются, но не более того.
Так нельзя же опускать столь важную деталь. Это часть концепции интерфейса. И если это не реализовано на уровне языка, то должно быть конвенцией.
О, теперь и я вижу тот ответ, который мне импонирует. В моем понимании интерфейсом является декларация возможностей или унифицированный «язык» общения между объектами/модулями/компонентами. Интерфейс можно использовать даже не в ООП языках.
Это скорее «контракт» или есть различия?
Не, именно декларация. Например, парикмахерская в своем прейскуранте указывает, что она предоставляет услуги стрижки, укладки, маникюра. Это их интерфейс. Не важно кто именно там работает парикмахером и как именно стрижет, количество услуг не изменяется.
В прейскуранте она ещё указывает цену, плюс есть различные пост- и предусловия, инварианты и т. п. (какую валюту принимают, касса, защита прав потребителя и т. п.). Это, имхо, именно контракт, который парикмахерская предлагает заключить клиенту. Интерфейс же декларируется где-то в «правилах оказания услуг»
Не, это все возникает, когда начинают работать другие интерфейсы. Цена — частный объект в интерфейсе «оплата услуг». Защита прав потребителя — свой собственный интерфейс, или часть интерфейса «законные действия».
Парикмахер может работать бесплатно, предоставлять еще и услуги психолога и быть хорошим дизайнером. Но это все не влияет на суть самой парикмахерской, которая декларирует, что они могут сделать прическу любому потребителю. Это и есть суть интерфейса.
Парикмахер может работать бесплатно, предоставлять еще и услуги психолога и быть хорошим дизайнером. Но это все не влияет на суть самой парикмахерской, которая декларирует, что они могут сделать прическу любому потребителю. Это и есть суть интерфейса.
На самом деле выбор того что использовать зависит от задачи, опыта и личных предпочтений разработчика. Например, в публичных библиотеках могут быть удобнее интерфейсы, т.к. они делают код стороннего приложения более независимым от конкретной реализации (= этой библиотеки) и позволяют скрыть от посторонних собственные внутренности (повышает дуракоустойчивость и понижает требования к коду). В закрытых проектах с небольшим деревом классов могут быть удобнее абстрактные классы, т.к. они позволяют избавиться от лишних сущностей (= интерфейсов) и тем самым еще более упростить код (это работает только до определенного момента, не всегда и не везде).
Ну и реальный пример: в приложении нужен платежный шлюз (ПШ), который должен уметь проводить платежи через несколько платежных систем (ПС). Вопрос как лучше реализовать?
1) Возможность расширения плагинами не предполагается: В этом случае наиболее рационально и просто реализовать класс Абстрактной ПС (АПС), от которой будут наследоваться все остальные ПС и переопределять необходимые методы (но вот часть методов логично расположить именно в АПС, поскольку они будут одинаковыми для всех ПС). Сам ПШ будет оперировать только АПС.
2) Решили дать возможность плагинам добавлять свои ПС: Можно оставить предыдущую модель, но в этом случае сторонним разработчикам придется разбираться в вашей реализации (в большом старом приложении 100% будет куча подводных камней в АПС, да и сам код, скорее всего, будет закрыт). Поэтому вместо этого логичнее вынести общие для всех ПС методы из АПС в Интерфейс ПС (ИПС) и заставить все ПС реализовывать его (фактически только АПС, которая в этом случае никуда не денется). Сам же ПШ вместо АПС станет оперировать ИПС.
ЗЫ: А данном контексте: публичный — совместно используемая библиотека; закрытый — конечный проект (код нигде повторно не используется).
Ну и реальный пример: в приложении нужен платежный шлюз (ПШ), который должен уметь проводить платежи через несколько платежных систем (ПС). Вопрос как лучше реализовать?
1) Возможность расширения плагинами не предполагается: В этом случае наиболее рационально и просто реализовать класс Абстрактной ПС (АПС), от которой будут наследоваться все остальные ПС и переопределять необходимые методы (но вот часть методов логично расположить именно в АПС, поскольку они будут одинаковыми для всех ПС). Сам ПШ будет оперировать только АПС.
2) Решили дать возможность плагинам добавлять свои ПС: Можно оставить предыдущую модель, но в этом случае сторонним разработчикам придется разбираться в вашей реализации (в большом старом приложении 100% будет куча подводных камней в АПС, да и сам код, скорее всего, будет закрыт). Поэтому вместо этого логичнее вынести общие для всех ПС методы из АПС в Интерфейс ПС (ИПС) и заставить все ПС реализовывать его (фактически только АПС, которая в этом случае никуда не денется). Сам же ПШ вместо АПС станет оперировать ИПС.
ЗЫ: А данном контексте: публичный — совместно используемая библиотека; закрытый — конечный проект (код нигде повторно не используется).
Первый абзац порезался :( (читать сначала этот комментарий, а потом тот что выше)
Отличие у них всего одно — концептуальное: интерфейс это «поведение» без реализации; абстрактный класс — частичная реализация какого-либо поведения (конкретная реализация переложена на плечи потомков). Из этого отличия как раз и вытекают все свойства интерфейсов: реализация методов в них бессмысленна (и противоречит концепции), т.к. автоматически превращает интерфейс в абстрактный класс (обратное тоже верно — абстрактный класс содержащий только абстрактные методы можно считать интерфейсом); множественная реализация интерфейсов, в отличие от множественного наследования, разрешена т.к. не может породить конфликтов реализаций; и т.д.
Про выбор читаем выше.
Отличие у них всего одно — концептуальное: интерфейс это «поведение» без реализации; абстрактный класс — частичная реализация какого-либо поведения (конкретная реализация переложена на плечи потомков). Из этого отличия как раз и вытекают все свойства интерфейсов: реализация методов в них бессмысленна (и противоречит концепции), т.к. автоматически превращает интерфейс в абстрактный класс (обратное тоже верно — абстрактный класс содержащий только абстрактные методы можно считать интерфейсом); множественная реализация интерфейсов, в отличие от множественного наследования, разрешена т.к. не может породить конфликтов реализаций; и т.д.
Про выбор читаем выше.
А при чем реализация к интерфейсу?
А почему без свойств? Если свойство — это открытое «наружу» состояние — интерфейс (концептуально) вполне может его содержать.
Интерфейс — это прежде всего набор правил (с точки зрения ООП) взаимодействия с тем или иным объектом.
В этом смысле любой класс, обладает интерфейсом.
Тем не менее, интерфейс классом считать нельзя, т.к. интерфейс — это не абстрактная реализация, а набор правил.
В этом смысле любой класс, обладает интерфейсом.
Тем не менее, интерфейс классом считать нельзя, т.к. интерфейс — это не абстрактная реализация, а набор правил.
Интерфейс — класс в котором все методы абстрактные.
Раз все так серьезно. Тогда:
Интерфейс — класс в котором только методы и только абстрактные.
Абстрактный класс — класс в котором хотя бы один абстрактный метод.
Ну и применение у них разное. И если его не считать, то интерфейсы — подмножество абстрактных классов.
Интерфейс — класс в котором только методы и только абстрактные.
Абстрактный класс — класс в котором хотя бы один абстрактный метод.
Ну и применение у них разное. И если его не считать, то интерфейсы — подмножество абстрактных классов.
Интерфейс — это не подвид класса.
Вы путаете определение со свойством.
То, что в некоторых языках программирования классы, у которых все методы абстрактные, могут выполнять роль интерфейсов, не означает, что интерфейс — это класс у которого все методы абстрактные.
Если я могу забивать гвозди микроскопом, то это не значит, что молоток — это крепкий микроскоп с удобной ручкой.
Вы путаете определение со свойством.
То, что в некоторых языках программирования классы, у которых все методы абстрактные, могут выполнять роль интерфейсов, не означает, что интерфейс — это класс у которого все методы абстрактные.
Если я могу забивать гвозди микроскопом, то это не значит, что молоток — это крепкий микроскоп с удобной ручкой.
Нет, это лишь значит, что микроскоп это штука, которой можно забивать гвозди. Этой штукой может быть молоток, может быть камень, может быть кусок металлической трубы.
Когда вы проектируете класс, вы сначала описываете, то как он взаимодействует с внешним миром (интерфейс), а затем реализацию этого интерфейса. Но вот реализацию можно не делать и останется только интерфейс, вот и все.
Поэтому, и у микроскопа и у молотка суперкласс — штука. Какой-нибудь абориген незнакомый с классами молоток и микроскоп будет общаться с ними как со штукой, вот и все.
Вот кто-нибудь из спорщиков может мне привести пример задачи, которую я не смогу решить, или сильно усложниться решение если я буду придерживаться мнения: «Интерфейс — полностью абстрактный класс»?
Когда вы проектируете класс, вы сначала описываете, то как он взаимодействует с внешним миром (интерфейс), а затем реализацию этого интерфейса. Но вот реализацию можно не делать и останется только интерфейс, вот и все.
Поэтому, и у микроскопа и у молотка суперкласс — штука. Какой-нибудь абориген незнакомый с классами молоток и микроскоп будет общаться с ними как со штукой, вот и все.
Вот кто-нибудь из спорщиков может мне привести пример задачи, которую я не смогу решить, или сильно усложниться решение если я буду придерживаться мнения: «Интерфейс — полностью абстрактный класс»?
> Вот кто-нибудь из спорщиков может мне привести пример задачи, которую я не смогу решить, или сильно усложниться решение если я буду придерживаться мнения
Я не спорщик но позвольте попробовать: в большинстве императивных ЯП класс может реализовывать несколько интерфейсов, но может быть отнаследован лишь от одного класса.
С этой позиции ваше решение «усложнится» (точнее говоря — вообще станет невозможным), если вы продолжите придерживаться своего мнения.
Я не спорщик но позвольте попробовать: в большинстве императивных ЯП класс может реализовывать несколько интерфейсов, но может быть отнаследован лишь от одного класса.
С этой позиции ваше решение «усложнится» (точнее говоря — вообще станет невозможным), если вы продолжите придерживаться своего мнения.
Интерфейс — не класс. Методы интерфейса — не абстрактные методы. Само понятие «абстрактный метод» подразумевает метод с абстрактной реализацией. В то время как метод интерфейса — это всего лишь правило, но никак не реализация.
Изначально стоит упоминать, с какой именно точки зрения вы смотрите на этот вопрос. Если с точки зрения конкретной реализации в конкретном языке — возможно, вы правы. Но имхо, это очень упрощённый взгляд на вещи.
Изначально стоит упоминать, с какой именно точки зрения вы смотрите на этот вопрос. Если с точки зрения конкретной реализации в конкретном языке — возможно, вы правы. Но имхо, это очень упрощённый взгляд на вещи.
Интерфейс определяет, что можно делать с сущностью, а абстрактный класс — к какому общему классу сущностей принадлежит что-то.
Пример:
интерфейс «стучабельность» — по всему, что его реализует, можно стукнуть (независимо от того, к какому классу эта вещь принадлежит)
абстрактный класс «дерево» — не определяет, что конкретно растёт на этом дереве, но говорит, что в общем у него есть корни, ствол и ветки. Конкретные реализации могут определять наличие\отсутствие веток, плодов, поддержку каких-то интерфейсов и т.д.
Пример:
интерфейс «стучабельность» — по всему, что его реализует, можно стукнуть (независимо от того, к какому классу эта вещь принадлежит)
абстрактный класс «дерево» — не определяет, что конкретно растёт на этом дереве, но говорит, что в общем у него есть корни, ствол и ветки. Конкретные реализации могут определять наличие\отсутствие веток, плодов, поддержку каких-то интерфейсов и т.д.
Ну, и как дополнение, хотя и достаточно очевидное после вашего объяснения, — в большинстве современных ОО-языков, класс может реализовывать несколько интерфейсов, но наследоваться может только от одного класса (абстрактного или обычного.)
Ну наконец, правильный концептуальный ответ. Я пока все комментарии выше вашего прочитал, у меня волосы дыбом встали от того, что и правда никто ж не знает. Спасибо за вернувшуюся веру в хабр и его обитателей.
А не понятно какого ответа в каком контексте ждут.
Исчерпывающего. Да и дело не в ответах на вопросы. Речь ведь в статье шла не столько о собеседованиях, сколько об отсутствии понимания базовых принципов в процессе работы. А в работе важно понимать не только технические нюансы интерфейсов и абстрактных классов, но и семантические — то есть, в каких общих ситуациях что применяется и почему, с точки зрения архитектуры и проектирования.
Концептуально интерфейс — это набор правил взаимодействия. Важно понимать, что любой класс обладает интерфейсом. Так что концептуально сравнивать интерфейс с классом некорректно. Аналогично можно спрашивать, чем отличается ТК РФ от зарплаты.
Так что в исходном вопросе стоит уточнить, о чём мы говорим: о концепции или о конкретной реализации в разных языках программирования.
Так что в исходном вопросе стоит уточнить, о чём мы говорим: о концепции или о конкретной реализации в разных языках программирования.
Это объяснение (принимаемое как правильное, судя по заплюсованности) говорит о восприятии человеком двух этих сущностей. То есть чисто психологически интерфейс человеку говорит одно, а класс — другое.
По сути в конкретной реализации конкретного языка интерейс и асбтрактный класс могут не иметь вообще никаких функциональных различий при написании программы (кроме очевидноц разницы провозглашения). Именно поэтому меня всегда напрягали такие вопросы. Класс таких вопросов. Особенно с учетом того, что два архитектора на мое памяти никогда не могли полностью договориться о терминах. И задавая тебе вопрос, человек на деле хочет, чтобы ты угадал ответ из его головы.
До обсуждаемых головоломок были популярны именно такие не менее дурацкие вопросы про ООП. Отличия абстрактного класса и интерфейса, перечеслиение механизмов ООП или Паттернов программирования (с большой буквы).
О… Паттерны это была религия одно время. Если не знаешь названия паттернов — считай не программист. Сейчас поутихло. Все как и раньше пользуют MVC, singletone, factory и какие ещё нужны, но уже не раздуваются от гордости по этому поводу.
Кстати далеко не сразу, а только со временем интервьюеры выучили, что паттернов неограниченое количество, что это не 10 заповедей, и стали добавлять к вопросу «какие знаете» или «самые популярные», при этом все равно подразумевая своё. «Как же на счет фасада/прокси/еще паттерна, про который я вчера прочитал на хабре»
В этих вопросах не больше понимания сути, чем в головоломках. Один идиотизм сменился на другой. А автор статьи — большой молодец. Отлично продемонстрировал хабру, что ругая эти головоломки, как дурацкий подход, люди все так же падки на этот подход, когда он выражен в другой ипостаси.
А между тем, чем отличается интерфейс от абстрактного класса, сродни вопросу про то, чем похожи ворон и письменный стол из загадки сумасшедшего шляпника из Алисы в Стране Чудес. Не суть чем они похожи или чем они отличаются. Суть в том — для чего тебе ответ на этот вопрос. Если для того, чтобы пройти интервью — ты что-то делаешь не так.
По сути в конкретной реализации конкретного языка интерейс и асбтрактный класс могут не иметь вообще никаких функциональных различий при написании программы (кроме очевидноц разницы провозглашения). Именно поэтому меня всегда напрягали такие вопросы. Класс таких вопросов. Особенно с учетом того, что два архитектора на мое памяти никогда не могли полностью договориться о терминах. И задавая тебе вопрос, человек на деле хочет, чтобы ты угадал ответ из его головы.
До обсуждаемых головоломок были популярны именно такие не менее дурацкие вопросы про ООП. Отличия абстрактного класса и интерфейса, перечеслиение механизмов ООП или Паттернов программирования (с большой буквы).
О… Паттерны это была религия одно время. Если не знаешь названия паттернов — считай не программист. Сейчас поутихло. Все как и раньше пользуют MVC, singletone, factory и какие ещё нужны, но уже не раздуваются от гордости по этому поводу.
Кстати далеко не сразу, а только со временем интервьюеры выучили, что паттернов неограниченое количество, что это не 10 заповедей, и стали добавлять к вопросу «какие знаете» или «самые популярные», при этом все равно подразумевая своё. «Как же на счет фасада/прокси/еще паттерна, про который я вчера прочитал на хабре»
В этих вопросах не больше понимания сути, чем в головоломках. Один идиотизм сменился на другой. А автор статьи — большой молодец. Отлично продемонстрировал хабру, что ругая эти головоломки, как дурацкий подход, люди все так же падки на этот подход, когда он выражен в другой ипостаси.
А между тем, чем отличается интерфейс от абстрактного класса, сродни вопросу про то, чем похожи ворон и письменный стол из загадки сумасшедшего шляпника из Алисы в Стране Чудес. Не суть чем они похожи или чем они отличаются. Суть в том — для чего тебе ответ на этот вопрос. Если для того, чтобы пройти интервью — ты что-то делаешь не так.
Черт с ними, с интерфейсом и абстрактным классом — выяснили же уже, что никто не знает точно, в чём отличие. Но если на собеседовании не задавать задачки на логику, не спрашивать основы ООП и паттерны — то о чём вообще говорить? Как Спартак вчера сыграл? Где на рынке лучше мясо покупать?
Ответы на задачки и разговор об ООП хотя-бы даёт представление о общей логике человека, попытках думать, показывает его неравнодушие к теме и какие-никакие знания. Есть мысли, что нужно спрашивать?
Ответы на задачки и разговор об ООП хотя-бы даёт представление о общей логике человека, попытках думать, показывает его неравнодушие к теме и какие-никакие знания. Есть мысли, что нужно спрашивать?
Мне сразу вспоминает начало одной из замечательных книг Брюса Эккеля «Философия C++»
Картинка оттуда:
Думаю не сложно догадаться, что является абстрактынм классом, а что интерфейсом.
Картинка оттуда:
Думаю не сложно догадаться, что является абстрактынм классом, а что интерфейсом.
`абстрактным' конечно же
И что? «Фигура» может быть абстрактным классом, может быть интерфейсом (не в C++ конечно), а может быть абстрактным классом «реализующим» интерфейсы Colorable, Drawable и Movable :)
Если это UML диаграмма, то на ней изображены только классы и обобщения (наследование) без интерфейса(ов). Абстрактных классов на ней тоже нет.
НЛО прилетело и опубликовало эту надпись здесь
Пишу в контексте языка PHP.
Во-первых, тем же (всем), что и класс вообще от интерфейса. Как класс отличается от переменной, так и массив отличается от функции и переменная от трейта. ПРосто разные вещи.
Во-вторых, наследовать можно только от одного класса, но зато от нескольких интерфейсов.
В-третьих, интерфейс не может содержать логику (код).
В-четвёртых, интерфейс обязует написать некоторые методы, а абстрактный класс позволяет их опустить вообще.
В-пятых, изменение абстрактного класса влияет на логику и ход работы программы. Изменение интерфейса может привести только к ошибкам на этапе запуска.
В-шестых, и самое главное, говоря упрощённо, абстрактный класс — это класс, который не может иметь экземпляров (от него только наследуются), а интерфейс — это некий список методов, которые класс обязан реализовывать.
В-седьмых, класс, наследуемый от абстрактного, может не содержать методов (исключение — абстрактные методы). Класс, наследуемый от непустого интерфейса, обязан содержать методы.
Вообще, более интересные вопросы:
1. Чем абстрактный класс, все методы которого абстрактные, отличается от интерфейса?
2. Что общего между абстрактным классом и интерфейсом?
Во-первых, тем же (всем), что и класс вообще от интерфейса. Как класс отличается от переменной, так и массив отличается от функции и переменная от трейта. ПРосто разные вещи.
Во-вторых, наследовать можно только от одного класса, но зато от нескольких интерфейсов.
В-третьих, интерфейс не может содержать логику (код).
В-четвёртых, интерфейс обязует написать некоторые методы, а абстрактный класс позволяет их опустить вообще.
В-пятых, изменение абстрактного класса влияет на логику и ход работы программы. Изменение интерфейса может привести только к ошибкам на этапе запуска.
В-шестых, и самое главное, говоря упрощённо, абстрактный класс — это класс, который не может иметь экземпляров (от него только наследуются), а интерфейс — это некий список методов, которые класс обязан реализовывать.
В-седьмых, класс, наследуемый от абстрактного, может не содержать методов (исключение — абстрактные методы). Класс, наследуемый от непустого интерфейса, обязан содержать методы.
Вообще, более интересные вопросы:
1. Чем абстрактный класс, все методы которого абстрактные, отличается от интерфейса?
2. Что общего между абстрактным классом и интерфейсом?
Насколько я понимаю, интерфейс — ничто иное, как протокол взаимодействия, некоторый набор свойств. А вот абстрактный класс — это тот же протокол, но нагруженный частичной реализацией.
И интерфейсы, и абстрактные классы позволяют работать с деревом потомков как с единым типом. Не это ли суть ООП?
Как советуют сильные мира сего, следует использовать интерфейсы везде, где только возможно, а абстрактные классы — только в случае крайней необходимости (ну, например, при реализации паттерна проектирования Template Method). Хотя это весьма спорный момент, но время идёт, а базовые концепции ООП пересматриваются.
В C++ интерфейсов нет, хотя они и достаточно просто реализуются средствами языка. Но так как их нет, они и не используются особо. Java же вынуждает реализовывать интерфесы в тех случаях, когда необходим аналог «множественного наследования».
И интерфейсы, и абстрактные классы позволяют работать с деревом потомков как с единым типом. Не это ли суть ООП?
Как советуют сильные мира сего, следует использовать интерфейсы везде, где только возможно, а абстрактные классы — только в случае крайней необходимости (ну, например, при реализации паттерна проектирования Template Method). Хотя это весьма спорный момент, но время идёт, а базовые концепции ООП пересматриваются.
В C++ интерфейсов нет, хотя они и достаточно просто реализуются средствами языка. Но так как их нет, они и не используются особо. Java же вынуждает реализовывать интерфесы в тех случаях, когда необходим аналог «множественного наследования».
Ну, насколько я могу судить (не читая особо углубленно про эту тему) из чистой практики использования интерфейсов и абстрактных классов:
Интерфейс — есть выражение того, как объект (инициализированная сущность класса) ОБЯЗАН выглядеть для окружающего кода, то бишь какими методами он будет гарантированно обладать (если проверять объект на принадлежность именно к нужному интерфейсу) и свойствами (пример из IRL: есть интерфейс чайник, да, с моей колокольни именование предмета чайником — есть обозначение принадлежности предмета к интерфейсу Чайник, что имеется ввиду под названием Чайник? Он должен уметь кипятить воду, не важно как, просто должен кипятить/разогревать, и все, а наличие отверстия для выливания жидкости уже другой интерфейс равно как и наличие ручки у него так же совершенно другой интерфейс).
Абстрактный класс — есть потенциал потомков этого класса, то бишь это нечто гораздо большее, по своим возможностям, чем интерфейс, но не является таковым, ведь мы можем просто объявить класс-наследник от абстрактного абсолютно пустым, но он будет уметь все то же, что и абстрактный родитель, в отличии от интерфейса.
Интерфейс — есть выражение того, как объект (инициализированная сущность класса) ОБЯЗАН выглядеть для окружающего кода, то бишь какими методами он будет гарантированно обладать (если проверять объект на принадлежность именно к нужному интерфейсу) и свойствами (пример из IRL: есть интерфейс чайник, да, с моей колокольни именование предмета чайником — есть обозначение принадлежности предмета к интерфейсу Чайник, что имеется ввиду под названием Чайник? Он должен уметь кипятить воду, не важно как, просто должен кипятить/разогревать, и все, а наличие отверстия для выливания жидкости уже другой интерфейс равно как и наличие ручки у него так же совершенно другой интерфейс).
Абстрактный класс — есть потенциал потомков этого класса, то бишь это нечто гораздо большее, по своим возможностям, чем интерфейс, но не является таковым, ведь мы можем просто объявить класс-наследник от абстрактного абсолютно пустым, но он будет уметь все то же, что и абстрактный родитель, в отличии от интерфейса.
Скорее «Чайник» это должен быть абстрактный класс, реализующий интерфейсы «Кипятибельный», «Выливабельный», «Держабельный». А уже от него наследуются конкретные типы чайников «Чайник алюминиевый артикул 123456» или «Чайник электрический Example модель SuperBoiler 178» (возможно через другие абстрактные классы типа «Чайник металлический» или «Чайник электрический»). Если, конечно, домен требует работы с конкретными экземплярами чайников конкретных моделей.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо вам! Дочитав пост взял книжку и разобрался таки, чем абстрактный класс отличается от интерфейса. :) На всякий случай — книга Java2 Том 1. Основы Хорстманна и Корнелла.
Три с половиной раза написать «чем абстрактный класс отличается от интерфейса»… это сильно. Так чем же простите, с точки зрения реализации? Просто удобный сахарок. Да и то, удобство весьма сомнительно.
Так вообще-то все языки, начиная с базового синтаксиса, через ключевые слова и конструкции, и заканчивая стандартными библиотеками — не более чем «сахарок» над тру-хардкорным ассемблером. А то, знаете ли, можно и сайты на ассемблере писать, причём на ООП, ибо Virtual Method Table — не такая уж и сложная вещь на на уровне реализации.
Утрировать не стоит.
Нет в языке интерфейсов, значит будет применяться upcasting. Без расслоения и прочих ужасов. И абсолютно никаких различий между интерфейсом и абстрактным классом.
Есть интерфейсы, значит будут использоваться они. Тогда действительно будет различие, но на уровне реализации ООП в рамках рассматриваемого языка.
Нет в языке интерфейсов, значит будет применяться upcasting. Без расслоения и прочих ужасов. И абсолютно никаких различий между интерфейсом и абстрактным классом.
Есть интерфейсы, значит будут использоваться они. Тогда действительно будет различие, но на уровне реализации ООП в рамках рассматриваемого языка.
В некоторых языках где есть интерфейсы нет множественного наследования. А значит не всегда можно тупо заменить интерфейс на абстрактный класс. Частный случай, конечно, но имеет место быть.
ООП и без виртуальных функций бывает.
Хм… Да? Интересно. Можно пример реализации полиморфизма без виртуальных функций?
Сами представить не в состоянии? Назову один из примитивных способов — switch
Табличная реализация (vtable) — просто частный случай.
Табличная реализация (vtable) — просто частный случай.
Ну вообще-то не очень в состоянии. Switch нарушает инкапсуляцию: это кто-то другой знает о том, какую фукнционал вызывать для данного класса в зависимости от его типа или (хуже) от его данных. Да, в общем-то, и наследование он слегка нарушает. Что делает такой подход не-ООП'шным. Ну или я просто не понял схему со switch.
Хотя вот почитал википедию, там ещё есть какой-то особый полиморфизм в функциональных языках. Не самая моя любимая парадигма, так что я не понял.
В любом случае, изначальный вопрос был про фразу «ООП и без виртуальных функций бывает». Я пытаюсь представить себе как именно.
Хотя вот почитал википедию, там ещё есть какой-то особый полиморфизм в функциональных языках. Не самая моя любимая парадигма, так что я не понял.
В любом случае, изначальный вопрос был про фразу «ООП и без виртуальных функций бывает». Я пытаюсь представить себе как именно.
это кто-то другой знает о том, какую фукнционал вызывать для данного класса в зависимости от его типа или (хуже) от его данных.
Не очень понял, но выглядит примерно так:
Не очень понял, но выглядит примерно так:
class SomeClass
{
public function __construct($arg)
{
switch (getype($arg)) {
case 'integer':
// integer argument
break;
case 'string':
// string argument
break;
default:
// other cases
}
}
public function someMethod()
{
switch (func_num_args()) {
case 0:
// no argument
break;
case 1:
// one argument
break;
default:
// other cases
}
}
}
$obj = new SomeClass(1); // integer behavior of constructor
$obj->someMethod(2); // one argument behavior
Первое (конструктор) — это не ООП. Если именно integer/string рассматриваются как «как бы полиморфные без виртуальных функций».
А если сам SomeClass — то вообще к полиморфизму и ООП этот пример отношения не имеет, и является примером ручной перегрузки конструктора разнотипными параметрами.
Второе (функция) — пример динамического набора параметров; в лучшем случае — тоже про перегрузку функции. Тоже не про «ООП без виртуальных функций».
А если сам SomeClass — то вообще к полиморфизму и ООП этот пример отношения не имеет, и является примером ручной перегрузки конструктора разнотипными параметрами.
Второе (функция) — пример динамического набора параметров; в лучшем случае — тоже про перегрузку функции. Тоже не про «ООП без виртуальных функций».
Ну да, перегрузка — частный случай полиморфизма. Мне в холиварах часто «плюсанутые» указывали на этот недостаток PHP (отсутствие перегрузки по сигнатурам, вернее по количеству/типу параметров), а «мою» перегрузку называли грязным костылём, но потом переходили на невозможность перегрузки операторов. Полиморфизм через наследование в PHP тривиален, если, конечно, класс/метод не объявлен как final. Но ключевого слова virtual нет :) Теперь кажется понял про что вы. Когда-то (когда в PHP ООП не было вообще, а после C++ мне его сильно не хватало) делал вот так примерно:
Написано на коленке в буквальном смысле слова, прямо в инпуте хабра, но думаю идея понятна. Подобное можно реализовать и на Си, только карты надо будет реализовать и «методы» по указателю назначать и вызывать. И кто скажет, что это не ООП :)
Кучка быдлокода
function constructObject($class, $args) {
global $classes;
$constructor_name = "{$class}_construct";
if (isset($classes[$class]['parent']) {
$object['__class'] = array_merge($classes[$class]['parent'], $classes[$class]);
} else {
$object['__class'] = $classes[$class];
}
$constructor_name(&$object, $args);
return $object;
}
function invokeObjectMethod(&$object, $method, $args) {
$method_name = $object['__class']['name']
. '_'
. $object['__class']['methods']['method'];
return $method_name($object, $args);
}
function someClass_construct($this, $args) {
// ...
}
function someClass_someMethod($this, $args) {
// ...
}
$classes = array(
'someClass' => array(
'name' => 'someClass'
, 'methods' => array (
'someMethood' => 'someMethod'
)
)
);
$obj = constructObject('someClass', array('someParam'));
invokeObjectMethod($obj, 'someMethod', array('onterParam'));
Написано на коленке в буквальном смысле слова, прямо в инпуте хабра, но думаю идея понятна. Подобное можно реализовать и на Си, только карты надо будет реализовать и «методы» по указателю назначать и вызывать. И кто скажет, что это не ООП :)
> перегрузка — частный случай полиморфизма
Только если полиморфным объектом является сама перегружаемая функция. Каким образом класс, содержащий перегружаемую функцию, является полиморфным, я не понял. Точнее, не так… Класс-то может и полиморфен, но вот наследования из него уже не родишь, а значит ООП не получится.
> И кто скажет, что это не ООП :)
Это ООП. Причём это VMT и есть. Вот чистая голимая VMT:
А перенеси вы хождение по parent из constructObject() в invokeObjectMethod(), то получилась бы DMT (Dynamic Method Table). Это из Object Pascal & K.
PS: Такой же фигнёй сейчас занимаются JS'ры, которые пытаются сделать «красивый ООП как у других». LOL :-)
Только если полиморфным объектом является сама перегружаемая функция. Каким образом класс, содержащий перегружаемую функцию, является полиморфным, я не понял. Точнее, не так… Класс-то может и полиморфен, но вот наследования из него уже не родишь, а значит ООП не получится.
> И кто скажет, что это не ООП :)
Это ООП. Причём это VMT и есть. Вот чистая голимая VMT:
$classes = array(
'someClass' => array(
'methods' => array (
'someMethood' => 'someMethod'
)
)
);
А перенеси вы хождение по parent из constructObject() в invokeObjectMethod(), то получилась бы DMT (Dynamic Method Table). Это из Object Pascal & K.
PS: Такой же фигнёй сейчас занимаются JS'ры, которые пытаются сделать «красивый ООП как у других». LOL :-)
но вот наследования из него уже не родишь, а значит ООП не получится.
Можно и наследование сделать, в свитче вызываем протектед функции вроде some_method_noarg/one_arg, которые можем переопределить в наследнике по одной, то есть для наследника переопределить вызов метода с одним аргументом не трогая другие случаи, благо LSB есть.
Это ООП. Причём это VMT и есть.
Надо же, опять велосипед изобрёл, а ведь так гордился :)
то получилась бы DMT (Dynamic Method Table)
Первая реализция у меня была с полностью динамическим вычислением имени функций типа
PS: Такой же фигнёй сейчас занимаются JS'ры,
Ну хоть не только PHPшников будут велосипедистами называть. Для нас это пройденный лет 10 назад этап :)
Можно и наследование сделать, в свитче вызываем протектед функции вроде some_method_noarg/one_arg, которые можем переопределить в наследнике по одной, то есть для наследника переопределить вызов метода с одним аргументом не трогая другие случаи, благо LSB есть.
Это ООП. Причём это VMT и есть.
Надо же, опять велосипед изобрёл, а ведь так гордился :)
то получилась бы DMT (Dynamic Method Table)
Первая реализция у меня была с полностью динамическим вычислением имени функций типа
$func_name = $class.'_'.$method; $func_name($obj, $args);, потом по каким-то причинам сделал «таблицу» — это тоже DMT? PS: Такой же фигнёй сейчас занимаются JS'ры,
Ну хоть не только PHPшников будут велосипедистами называть. Для нас это пройденный лет 10 назад этап :)
Видимо речь все же шла о случае, когда виртуальные функции не реализуются языком разработки.
Напрмер, в JavaScript ООП нет, но эта парадигма реализуется уже программно (например, в ExtJS). Так что формально виртуальных функций (или все-таки полиморфных? а то ведь термин скорее относится именно к C++) нет. А по факту — ООП в конечном продукте используется.
ООП — это парадигма. Есть в нем идея полиморфизма, а уж как она будет реализоваться — с помощью VMT или с помощью прототипного наследования или switch'ей по массиву указателей на функции — это уже детали.
Напрмер, в JavaScript ООП нет, но эта парадигма реализуется уже программно (например, в ExtJS). Так что формально виртуальных функций (или все-таки полиморфных? а то ведь термин скорее относится именно к C++) нет. А по факту — ООП в конечном продукте используется.
ООП — это парадигма. Есть в нем идея полиморфизма, а уж как она будет реализоваться — с помощью VMT или с помощью прототипного наследования или switch'ей по массиву указателей на функции — это уже детали.
В какой-то классификации 10-летней давности JavaScript чётко помечался как не объектно-ориентированный язык, а просто объектный. В том смысле что в нём есть объекты, но вот объектной ориентированности с её четырьмя столпами нет (в особенности наследования и полиморфизма). Сейчас, как я смотрю по вики, это уже типа ООП-язык, хотя и с оговоркой на prototype-based.
И, если уж речь зашла про JavaScript и prototype-based, то вообще-то способ переопределения методов с помощью перезадания значений полей, хранящих ссылку на функции, и есть реализация этой самой VMT чуть не в чистом виде. Но этот фокус возможен только в языках, где функция — first-class citizen. А всякие там синтаксические конструкции наследования, слова class, virtual, etc (не в JS) — просто ещё один уровень «сахара».
Так что в JavaScript'е, принимая его за ООП-язык, самые что ни есть виртуальные функции. Поэтому вопрос об «ООП без виртуальных функций» всё ещё актуален. Я не вижу как можно сделать ООП без оных.
И, если уж речь зашла про JavaScript и prototype-based, то вообще-то способ переопределения методов с помощью перезадания значений полей, хранящих ссылку на функции, и есть реализация этой самой VMT чуть не в чистом виде. Но этот фокус возможен только в языках, где функция — first-class citizen. А всякие там синтаксические конструкции наследования, слова class, virtual, etc (не в JS) — просто ещё один уровень «сахара».
Так что в JavaScript'е, принимая его за ООП-язык, самые что ни есть виртуальные функции. Поэтому вопрос об «ООП без виртуальных функций» всё ещё актуален. Я не вижу как можно сделать ООП без оных.
1. Как говорится, «Я отрицаю обувь» (с) :)
Не могу согласиться с вики, что JavaScript — ООП язык. Наличие прототипа само по себе не дает ни полиморфизма ни наследования в привычном виде.
2. Виртуальная функция — один из вариантов реализации полиморфизма. ООП ничего не говорит о виртуальных функциях, есть только аспекты полиморфных методов, как их реализовать и на каком уровне — дело десятое.
Не могу согласиться с вики, что JavaScript — ООП язык. Наличие прототипа само по себе не дает ни полиморфизма ни наследования в привычном виде.
2. Виртуальная функция — один из вариантов реализации полиморфизма. ООП ничего не говорит о виртуальных функциях, есть только аспекты полиморфных методов, как их реализовать и на каком уровне — дело десятое.
Вот я и хочу получить какой-нибудь пример ООП без виртуальных функций, как упомянул тов. burjui. Для кругозора. Пока что мой кругозор подразумевает что если есть ООП, то есть виртуальные функции в том или ином виде (но не наоборот).
Полиморфизм в этой беседе участвует лишь как переходное звено от ООП до виртуальных функций. Можно и без него.
Полиморфизм в этой беседе участвует лишь как переходное звено от ООП до виртуальных функций. Можно и без него.
Наверное, надо поступать так же, как при реализации run-time полиморфизма по более, чем одному аргументу. В функции, реализующей, скажем, операцию сложения, держать хэш-табличку реализаций для каждой пары типов, для которых эта реализация есть. Заполнять табличку при инициализации.
Виртуальными функциями в их классическом понимании это не будет — ни один из классов, например, «комплексное число» и «рациональная функция над Q» не знает про другой класс, и не может предоставить функцию сложения этих объектов — эту функцию должен предоставить кто-то, знающий про оба класса.
В общем, делать в runtime то, что в случае compile-time полиморфизма (или перегрузки?) делает компилятор. С учетом наследования это может быть еще мохнатее, но реализуемо. И иногда, наверное, даже нужно. Для тех же библиотек символьных вычислений, например.
Но я не уверен, что это ООП.
Виртуальными функциями в их классическом понимании это не будет — ни один из классов, например, «комплексное число» и «рациональная функция над Q» не знает про другой класс, и не может предоставить функцию сложения этих объектов — эту функцию должен предоставить кто-то, знающий про оба класса.
В общем, делать в runtime то, что в случае compile-time полиморфизма (или перегрузки?) делает компилятор. С учетом наследования это может быть еще мохнатее, но реализуемо. И иногда, наверное, даже нужно. Для тех же библиотек символьных вычислений, например.
Но я не уверен, что это ООП.
А при чём здесь реализация? Чай не для машин пишем, а для людей.
Всё правда. Но в статье ни слова о том, что вы предлагаете, чтобы изменить сложившуюся ситуацию.
Что?
Что?
«Теперь у нас все знают почему люки круглые»,
Я не знал, но гугл помог:
"… круглыми они делаются лишь по той причине, что от круглой дырки(когда наши умельцы умудряются крышку люка стырить) колеса автомобилей повреждаются меньше чем от форм с углами, тоже касается и травм людей"
Я не знал, но гугл помог:
"… круглыми они делаются лишь по той причине, что от круглой дырки(когда наши умельцы умудряются крышку люка стырить) колеса автомобилей повреждаются меньше чем от форм с углами, тоже касается и травм людей"
А я думал, потому, что круглый люк круглый люк ну никак не провалится в отверстие, как бы криво его не пытались установить.
чепуха.
просто круглая крышка не может упасть внутрь
просто круглая крышка не может упасть внутрь
Гулпость какая :)
1. Люки круглые потому тогда крышка, как бы она не повернулась вокруг любой оси, не падает внутрь.
2. Люки кругые потому что дырки круглые, а дырки круглые потому что трубы круглые, а трубы круглые потому что их так проще делать и транспортировать, да и давление лучше выдерживают.
3. Кто вообще сказал что люки круглые? Я видел много, очень много квадратных и прямоугольных люков. Особенно этим грешат телекоммуникационщики. Поэтому сам вопрос «почему люки круглые» — неправильный; он изначально подразумевает какое-то положение как аксиоматичное, что не соответствует реальности.
1. Люки круглые потому тогда крышка, как бы она не повернулась вокруг любой оси, не падает внутрь.
2. Люки кругые потому что дырки круглые, а дырки круглые потому что трубы круглые, а трубы круглые потому что их так проще делать и транспортировать, да и давление лучше выдерживают.
3. Кто вообще сказал что люки круглые? Я видел много, очень много квадратных и прямоугольных люков. Особенно этим грешат телекоммуникационщики. Поэтому сам вопрос «почему люки круглые» — неправильный; он изначально подразумевает какое-то положение как аксиоматичное, что не соответствует реальности.
А ещё, кстати, у меня в запасе есть такой ответ:
4. Люки круглые чтобы было о чём разговаривать на собеседованиях с HR'ом.
4. Люки круглые чтобы было о чём разговаривать на собеседованиях с HR'ом.
Простите за поздний комментарий, но еще такой вариант:
5. Потому что по стандарту положены круглые люки. А почему по стандарту положены, это уже другой вопрос.
Как К.О. могу только сказать, что это вопрос не имеющий единственного верного варианта решения, спрашивающий лишь хочет оценить ответы и полет фантазии отвечающего.
5. Потому что по стандарту положены круглые люки. А почему по стандарту положены, это уже другой вопрос.
Как К.О. могу только сказать, что это вопрос не имеющий единственного верного варианта решения, спрашивающий лишь хочет оценить ответы и полет фантазии отвечающего.
5. Площадь круглого люка (а следовательно ее вес и стоимость) меньше чем квадратного / прямоугольного при том же минимальном размере лаза (если не ошибаюсь, по стандарту около 600 мм).
именно так и отвечал, а товарищи из HR настаивали, что это неверный ответ.
То есть круглый люк не может провалиться внутрь, но не проваливается сам и под нагрузкой он благодаря тому что есть специальный паз, диаметр люка больше, чем диаметр отверстия. Квадратный с таким же пазом, не провалится.
Антивандальные соображения? Ну да, это «for fun» поднимать тяжеленные квадратные люки, ставить по диагонали, чтобы уронить внутрь. А вот круглый можно поднять и укатить на ближайший прием металлолома.
То есть круглый люк не может провалиться внутрь, но не проваливается сам и под нагрузкой он благодаря тому что есть специальный паз, диаметр люка больше, чем диаметр отверстия. Квадратный с таким же пазом, не провалится.
Антивандальные соображения? Ну да, это «for fun» поднимать тяжеленные квадратные люки, ставить по диагонали, чтобы уронить внутрь. А вот круглый можно поднять и укатить на ближайший прием металлолома.
Как же неверный ответ?
Размер лаза примем = 600 мм
Площадь круглого: 0.3 * 0.3 * 3.14 = 0.28 м²
Площадь квадратного: 0.6 * 0.6 = 0.36 м²
В итоге экономия ~ 28-29% металла.
Прямая польза!
Размер лаза примем = 600 мм
Площадь круглого: 0.3 * 0.3 * 3.14 = 0.28 м²
Площадь квадратного: 0.6 * 0.6 = 0.36 м²
В итоге экономия ~ 28-29% металла.
Прямая польза!
Квадратный провалится, если его разместить по диагонали :)
конечно, правда не на плоскости, а нужно повернуть крышку перпендикулярно люку, и разместить по диагонали, что случайно маловероятно. А так не будут проваливаться любые фигуры, у которых разница между минимальным и максимальным радиусом (от геометрического центра) не больше ширины паза. при ширине паза == 0 — это только круг.
и разместить по диагонали, что случайно маловероятно.
Да нет, под действием силы тяжести такая крышка вполне может и повернуться, если ее неудачно подкатывать.
это только круг
В люк не провалится любая фигура постоянной ширины. Круг — фигура постоянной ширины. Еще можно вспомнить треугольник Релло, и множество других подобных фигур.
Еще преимущество фигур без углов в отсутствии точек концентрации напряжения — трещин меньше будет.
Асфальт вокруг люка без углов (круглого) не будет трескаться. По аналогии с иллюминаторами.
Моветон отвечать самому себе, но очевидно на хабре не хватает тэгов <юмор> и </юмор>
Люк круглый, потому что лаз под ним круглый, если бы лаз был квадратный, то и люк был бы квадратен.
Ну хоть кто-то наконец-то написал это. Спасибо!
А что делать с этим — это не решается ни одним человеком, ни одной компанией, к сожалению.
А что делать с этим — это не решается ни одним человеком, ни одной компанией, к сожалению.
Когда я* говорил… все остальные делали.
Теперь никто не знает чем отличается интерфейс от абстрактного класса, все хотят халявной пицци, программисты зажрались и все прочие беды…
Но это — работает — проекты строятся, задачи выполняются, деньги зарабатываются…
А я* — я* продолжаю говорить.
Теперь никто не знает чем отличается интерфейс от абстрактного класса, все хотят халявной пицци, программисты зажрались и все прочие беды…
Но это — работает — проекты строятся, задачи выполняются, деньги зарабатываются…
А я* — я* продолжаю говорить.
Чем интерфейс отличается от абстрактного класса выяснили, теперь осталось узнать чем же Java отличается от JavaScript'a :)
Слог занятный, но упор на «чем абстрактный класс отличается от интерфейса» — бессмысленный.
«Ибо ничем. Я на C++ пишу.»
«Ибо ничем. Я на C++ пишу.»
Ну, у вас там и структуры от классов не отличаются :) Понятно, что вопрос этот не про C++.
Знаете, вот именно такой странной привязкой общих определений к конкретному языку меня и поразили комментаторы из треда выше. Что же теперь, получается, начальные знания ООП, если они не относятся к вашему текущему языку, можно вовсе игнорировать?
Технический (правда тут к сожалению одни гуманитарии собрались как я заметил) интерфейсы были сделаны во многих языках лишь для упрощения механизма реализации множественного наследования. Компилятор и получаемый им код сильно усложнялся при использовании множественного наследования. Поэтому кстати в Embedded C++ множественного наследования и нету.
Можно долго летать в облаках каких-то там концепций, но от реализации всего это «в железе» ни куда в конечном счете не уйдешь. Это я вам могу сказать как человек пишущий на Plain C, C++ и Java для embedded'а;
Можно долго летать в облаках каких-то там концепций, но от реализации всего это «в железе» ни куда в конечном счете не уйдешь. Это я вам могу сказать как человек пишущий на Plain C, C++ и Java для embedded'а;
Дело в том, что в парадигму ООП разделение интерфейсов и абстрактных классов попросту не входит. Таким образом — этот вопрос, просто привязка к конкретным языкам, где нет честного множественного наследования. Если человек устраивается как специалист узкого профиля — ему это знать не нужно, не обязательно игнорировать специально, но есть существенная вероятность, что пока он с этими вопросами и не сталкивался.
> хер*во.
отлично зашифровано :)
отлично зашифровано :)
Ага, теперь я знаю как правильно писать хуёв* :)
как говорится, использовать звездочки в матерных словах — все равно что делать минет на площади и прикрывать рот ладошкой :)
ну вот, теперь я известен)) bash.im/quote/417549
кто это сделал? не я же автор высказывания, нечестно, однако
кто это сделал? не я же автор высказывания, нечестно, однако
Я ему всё время говорю: хватить говорить! Пойди уже что ни будь сделай! :)
Можете минусовать, но я просто обязан выяснить с целью борьбы с неграмотностью. Чем отличается абстрактный класс от интерфейса? с примером для практикующего C++ программиста :) Заранее спасибо!
Ну на плюсах особо, конечно, ничем, ибо там ни того ни того в явном нет, а есть только чисто виртуальные методы, которые делают класс абстрактным, и не дают создать объект такого типа.
Но, одно отличие важно есть и в плюсах: когда я вижу, что класс называется IComparable или CompareInterface я точно знаю, что можно применять множественное наследование и не париться — у них не должно быть (ПО ДОГОВОРЕННОСТИ, но так почти все в плюсах) полей. А когда я вижу абстрактный класс, я знаю только то, что дожен переопределить часть методов, но множественное наслледование может привести к проблеме ромба и нужно думать.
А философские отличия — описаны выше в коментариях
Но, одно отличие важно есть и в плюсах: когда я вижу, что класс называется IComparable или CompareInterface я точно знаю, что можно применять множественное наследование и не париться — у них не должно быть (ПО ДОГОВОРЕННОСТИ, но так почти все в плюсах) полей. А когда я вижу абстрактный класс, я знаю только то, что дожен переопределить часть методов, но множественное наслледование может привести к проблеме ромба и нужно думать.
А философские отличия — описаны выше в коментариях
спасибо за развернутый ответ, просто в реальной жизни редко встречаюсь с сложным наследованием и про проблему ромба помню только в теоретическом смысле :)
(шепотом, по секрету). Да никто особо не пользуется в плюсах абстрактными классами, кроме редких хоршо продокументированных случаев. Ровно как и непримитивным множественным наследованием.
А интерфейсы встречаются, да. Хотя я больше на шаблонах люблю все писать.
А интерфейсы встречаются, да. Хотя я больше на шаблонах люблю все писать.
Вы точно о плюсах говорите?
Вы часто в плюсах используете абстрактные классы?
Возмонжо, конечно, я и мой круг общения — довольно низкоуровневые библиотеки и там это просто не принято, но и в стл они есть разве что в iostream, который, строго говоря и не является частью stl, а просто часть стандартной библиотеки.
Возмонжо, конечно, я и мой круг общения — довольно низкоуровневые библиотеки и там это просто не принято, но и в стл они есть разве что в iostream, который, строго говоря и не является частью stl, а просто часть стандартной библиотеки.
>Вы часто в плюсах используете абстрактные классы?
Не сказать, чтобы на каждом шагу, но использую, но меня больше смутила фраза «А интерфейсы встречаются, да».
>не является частью stl, а просто часть стандартной библиотеки.
А тут мой мозг ушел в бесконечный цикл. Это вообще как? Что такое по Вашему STL?
Не сказать, чтобы на каждом шагу, но использую, но меня больше смутила фраза «А интерфейсы встречаются, да».
>не является частью stl, а просто часть стандартной библиотеки.
А тут мой мозг ушел в бесконечный цикл. Это вообще как? Что такое по Вашему STL?
Ха… А вот тут начинается маленькая тайна.
1) в Стандарте нигде не употребляется термин «STL». STL это библиотека, реализованная Алексом Степановым в 90-х и включенная в Стандарт.
2) ::std::string и iostream не являлись частью STL, как и некоторые другие классы.
3) Сейчас уже границы размыты, но под STL я подразумеваю набор контейнеров и алгоритмов, которые работают через итераторы (то есть без bind, regexp, shared_ptr и многого другого), но без iostream и string.
1) в Стандарте нигде не употребляется термин «STL». STL это библиотека, реализованная Алексом Степановым в 90-х и включенная в Стандарт.
2) ::std::string и iostream не являлись частью STL, как и некоторые другие классы.
3) Сейчас уже границы размыты, но под STL я подразумеваю набор контейнеров и алгоритмов, которые работают через итераторы (то есть без bind, regexp, shared_ptr и многого другого), но без iostream и string.
Тьфу, самое главное не написал.
STL — это одна из библиотек, являющаяся часть Standard C++ Library.
Именно поэтому майкрософт сокращает везде до SCL в коде, а книга называется The C++ Standard Library
STL — это одна из библиотек, являющаяся часть Standard C++ Library.
Именно поэтому майкрософт сокращает везде до SCL в коде, а книга называется The C++ Standard Library
Ну тогда не употребляйте термины, которые сами же и оспариваете. Никакой тут тайны нет, границы STL не просто размыты, их просто нет, потому как нет и STL, если уж говорить точно.
Что касается абстрактных классов, в плюсовом коде они встречаются нередко, взять тот же COM, или например библиотеку OPAL, и еще кучу других.
Насчет интерфейсов, которые Вам встречаются, Вы так и не ответили.
Что касается абстрактных классов, в плюсовом коде они встречаются нередко, взять тот же COM, или например библиотеку OPAL, и еще кучу других.
Насчет интерфейсов, которые Вам встречаются, Вы так и не ответили.
Ах, понял, в чем ошибся, вам не понравилась вот эта фраза:
>> и в стл они есть разве что в iostream, который, строго говоря и не является частью stl,
Да, лажанул.
Ну в COM есть, а в boost нет и stl нет. Много еще где нет (с тем, с чем я работал за последние несколкьо лет), а где-то есть. Я же не сказал, что их совсем нет.
НУ а что вам ответить?
То же самое — где-то они есть, встречал их чаще, но тоже далеко не везде. В основном все с чем я работал (возможно, мне везло) на шаблонах — так больше принято ввиду отсутствия оверхеда на рантайме.
Нравятся вам интерфейс — используйте, и множественное наследование тоже, кто ж запрещает?)
>> и в стл они есть разве что в iostream, который, строго говоря и не является частью stl,
Да, лажанул.
Ну в COM есть, а в boost нет и stl нет. Много еще где нет (с тем, с чем я работал за последние несколкьо лет), а где-то есть. Я же не сказал, что их совсем нет.
НУ а что вам ответить?
То же самое — где-то они есть, встречал их чаще, но тоже далеко не везде. В основном все с чем я работал (возможно, мне везло) на шаблонах — так больше принято ввиду отсутствия оверхеда на рантайме.
Нравятся вам интерфейс — используйте, и множественное наследование тоже, кто ж запрещает?)
С большой долей вероятности, если вы пишете свою объектную модель, а не вписываете обработчики нажатий кнопок в каком-нить ОО фреймворке, то там будут абстрактные классы.
Я НЕ занимаюсь кнопочками на C++ (в основном я пишу серверные части приложений), для этого есть прекрасный и быстрый в разработке C# (пожалуйста, не надо про переносимость кода начинать).
Давайте прекратим, а?
C++ довольно распространенный язык с больший функционалом. Естественно, каждый работает в своей области и видит свое подмножество. Кто-то абстрактные классы, полноценный ООП и паттерны.
Другой пишет больше на шаблонах и считает такты (образно, понятно, что речь скорее о секундах).
Третий пишет под QT.
Давайте прекратим, а?
C++ довольно распространенный язык с больший функционалом. Естественно, каждый работает в своей области и видит свое подмножество. Кто-то абстрактные классы, полноценный ООП и паттерны.
Другой пишет больше на шаблонах и считает такты (образно, понятно, что речь скорее о секундах).
Третий пишет под QT.
Ох… среди разработчиков это ещё не так заметно. Ну то есть один настоящий разработчик всё ещё может пинками заставить 5-10 новичков писать вменяемые вещи (и потом успевать исправлять за ними).
А вот если посмотреть на менеджеров…
А вот если посмотреть на менеджеров…
Captain Hindsight (Капитан Баян)
Блин, надо было ходить за печеньками на мероприятия а не книжки про отличия абстрактного класса и интерфейса читать…
Ну кстати конференции это все равно неплохо.
Ни помню ни одной конференции, где было бы что-то волшебно-полезное, чего нельзя узнать в сети (кроме, может быть 1-2 докладов). В основном все идут за майками и печеньками, но там довольно здоровские разговоры в калуарах обсуждаются — начиная от зарплат и заканчивая классными свежими технологиями.
Ни помню ни одной конференции, где было бы что-то волшебно-полезное, чего нельзя узнать в сети (кроме, может быть 1-2 докладов). В основном все идут за майками и печеньками, но там довольно здоровские разговоры в калуарах обсуждаются — начиная от зарплат и заканчивая классными свежими технологиями.
Автор поста часто любит поговорить ни о чем и потешить свое ЧСВ.
В действительно система работает. HR редко что-то решает. Пицца, айпады — это все к HR, т.к.они мало на что вообще способны. В основном кадровую политику решают техлиды на местах, которые проводят технические собеседования.
Техлид не заинтересован взять себе «синьора» который не знает чем абстрактный класс отличается от интерфейса т.к. любой нормальный техлид планирует использовать сеньора по назначению, а именно для управления джуниорами, базового делегирования небольших задач и качественного самостоятельного их исполнения, а не для удовлетворения синьором его меркантильных целей.
И да, софтверные компании, даже не подозревая о наличии хабраюзера sashaeve, самостоятельно пришли к проблеме подготовки и воспитания кадров внутри компании взаимодействуя с техническими университетами, так что в светлом будущем IT на территории СНГ я не смотневаюсь.
А упомянутый хабраюзер может продолжать говорить дальше.
В действительно система работает. HR редко что-то решает. Пицца, айпады — это все к HR, т.к.они мало на что вообще способны. В основном кадровую политику решают техлиды на местах, которые проводят технические собеседования.
Техлид не заинтересован взять себе «синьора» который не знает чем абстрактный класс отличается от интерфейса т.к. любой нормальный техлид планирует использовать сеньора по назначению, а именно для управления джуниорами, базового делегирования небольших задач и качественного самостоятельного их исполнения, а не для удовлетворения синьором его меркантильных целей.
И да, софтверные компании, даже не подозревая о наличии хабраюзера sashaeve, самостоятельно пришли к проблеме подготовки и воспитания кадров внутри компании взаимодействуя с техническими университетами, так что в светлом будущем IT на территории СНГ я не смотневаюсь.
А упомянутый хабраюзер может продолжать говорить дальше.
Вы слишком много взяли на себя смелости — рассуждать о хабраюзере sashaeve в таком тоне. Ведь на самом деле sashaeve не понаслышке знает о техлидах «на местах, которые проводят технические собеседования» и о «проблеме подготовки и воспитания кадров внутри компании взаимодействуя с техническими университетами», поэтому ваши слова, к сожалению, не подкреплены ничем, кроме ваших убеждений.
А вот и знатное ЧСВ. Тон такой, который заслужили. А чем подкрепленны ваши слова, кроме собственных убеждений и эмоций? Похоже, как всегда, ничем основательным.
И не нужно тут брать на себя ответственность за собирательные образы и за всю индустрию вцелом, не один вы тут в индустрии работаете, говорите за себя.
И не нужно тут брать на себя ответственность за собирательные образы и за всю индустрию вцелом, не один вы тут в индустрии работаете, говорите за себя.
Я вот ради интереса перелистал ваш сайт — msug.vn.ua.
Вы говорите про технические сообщества про важность квалификации разработчиков.
Ок, пускай вы взяли на себя непосильную задачу возрождения стагнирующей отрасли. Посмотрим же как вы это делаете — из первых 30 страниц msug.vn.ua/Posts идут предложения о работе, информация и пригласительные на IT мероприятия на которых кормят пиццой и раздают айпады и рассуждения про прекрасность IE и возможность существования мира без компании Google. Т.е. вы занимаетесь банальной ретрансляцией того кошмара, который вы тут порицаете.
2 (две) с натяжкой технических статьи на 300 постов. Большинство постов ваши. Основная часть — перепосты. И вы пытаетесь тут еще и хабр обо*рать?
С точки зрения обучения специалистов хабр уж точно лучше справляется с задачей повышения технического уровня специалистов, а ваше хваленое комьюнити просто не работает.
Вы говорите про технические сообщества про важность квалификации разработчиков.
Ок, пускай вы взяли на себя непосильную задачу возрождения стагнирующей отрасли. Посмотрим же как вы это делаете — из первых 30 страниц msug.vn.ua/Posts идут предложения о работе, информация и пригласительные на IT мероприятия на которых кормят пиццой и раздают айпады и рассуждения про прекрасность IE и возможность существования мира без компании Google. Т.е. вы занимаетесь банальной ретрансляцией того кошмара, который вы тут порицаете.
2 (две) с натяжкой технических статьи на 300 постов. Большинство постов ваши. Основная часть — перепосты. И вы пытаетесь тут еще и хабр обо*рать?
С точки зрения обучения специалистов хабр уж точно лучше справляется с задачей повышения технического уровня специалистов, а ваше хваленое комьюнити просто не работает.
Уважаемый almos, мог бы вас просто проигнорировать, но отвечу, чтобы у других не было повода меня доставать подобными вопросами.
Причина, по которой последние 30 страниц msug не содержат большого количества технических статей, описана в статье выше — нет сообщества, которое могло бы поддержать инициативу (почему нет большого сообщества — другой вопрос). Лично мной было написано достаточно много технических постов (вы их легко найдете после 30 страницы msug и на первых десяти страницах в профиле хабра). Перепостов на msug очень мало и если они и есть — это мои же статьи. Кроме msug у меня есть еще один ресурс — погуглите, вы легко его найдете.
Поэтому предлагаю вам успокоиться и прекратить меня доставать своими наездами.
Причина, по которой последние 30 страниц msug не содержат большого количества технических статей, описана в статье выше — нет сообщества, которое могло бы поддержать инициативу (почему нет большого сообщества — другой вопрос). Лично мной было написано достаточно много технических постов (вы их легко найдете после 30 страницы msug и на первых десяти страницах в профиле хабра). Перепостов на msug очень мало и если они и есть — это мои же статьи. Кроме msug у меня есть еще один ресурс — погуглите, вы легко его найдете.
Поэтому предлагаю вам успокоиться и прекратить меня доставать своими наездами.
Я всего-лишь высказал свое мнение, которое вам не понравилось. Вы сказали про отсутсвие обоснованности моих слов — я его добавил.
Критиковать что-то проще всего. Если вы не способны что-то поменять, и поделиться результатами вашей работы — ваш пост/мнение ничего не стоит. Важны действия, а не треп.
Это сеть и нужно быть готовым, что с вашей позицией могут не согласиться. Толерантность и терпимость к критике — одна из основных образующих комьюнити и всего того отсустсвующего, о чем вы тут написали.
Критиковать что-то проще всего. Если вы не способны что-то поменять, и поделиться результатами вашей работы — ваш пост/мнение ничего не стоит. Важны действия, а не треп.
Это сеть и нужно быть готовым, что с вашей позицией могут не согласиться. Толерантность и терпимость к критике — одна из основных образующих комьюнити и всего того отсустсвующего, о чем вы тут написали.
Не знаю в каком идеальном мире Вы живете, но все не так прекрасно как Вы говорите, но и не так плохо, как говорится в статье. Надо понимать, что проблемы имеют место быть, и статья является гиперболизированным описанием ситуации, и это несомненно является задумкой автора, чтобы обратить внимание сообщества и призвать к дискуссии.
Спасибо, вы очень правильно описали цель статьи.
Я не говорил о том, что все идеально. Проблемы есть, но система недостатков, которую автор тут предложил, совсем примитивная.
В действительности IT компании являются гибкими экосистемами, которые быстро адаптируются к проблемам рынка и достаточно быстро приходят к правильным решениям. А слабые звенья рано или поздно отсеиваются.
Проблема технической безграмотности актуальна, ее все обсуждают на всех форумах, но от этого мало пользы. Технически слабый синьор не поймет, что он слаб, если с ним не работать и не пинать его не стимулируя его технический рост. Он будет торчать на форумах и говорить про неадекватность начальства или сотрудников с более низкой должностью.
Поэтому нужно просто качественно работать с людьми осознавая, что то, что происходит на рынке не только результат деятельности менеджмента компаний, но и наших рук дело, поскольку мы даем возможность работать аппликантам проводя технические собеседования и анализируя результаты их работы под своим началом.
В действительности IT компании являются гибкими экосистемами, которые быстро адаптируются к проблемам рынка и достаточно быстро приходят к правильным решениям. А слабые звенья рано или поздно отсеиваются.
Проблема технической безграмотности актуальна, ее все обсуждают на всех форумах, но от этого мало пользы. Технически слабый синьор не поймет, что он слаб, если с ним не работать и не пинать его не стимулируя его технический рост. Он будет торчать на форумах и говорить про неадекватность начальства или сотрудников с более низкой должностью.
Поэтому нужно просто качественно работать с людьми осознавая, что то, что происходит на рынке не только результат деятельности менеджмента компаний, но и наших рук дело, поскольку мы даем возможность работать аппликантам проводя технические собеседования и анализируя результаты их работы под своим началом.
Когда вы говорили, я хотел сказать тоже самое. Спасибо, было интересно почитать.
Всё правда
Я согласен с автором насчет головоломок, но я встречался с ситуацией, когда готовое решение не работало и от программиста требовалось включить всю его логику. Программист с логикой, смог решить ее за 2 месяца. Программист «готовых решений» и за полгода не смог разобраться.
Возможно головоломки нужны, но по теме. Допустим человек устраивается программистом, можно попросить его решить простенькую задачу: «Подсчитать сколько раз встречается каждое слово в тексте». Например: «машина стояла, а другая машина ехала». Итого «машина» встречается 2 раза, остальные слова по одному разу. И даешь тестовый текст на пару тысяч слов.
Далее, смотрим на его решение. На языке python правильное решение занимает всего 2 строки. А вот неправильное решение, но работающее, может занимать 30 строк. Это тут же дает понимание насколько претендент хорошо знает данный язык программирования.
Или, например, если человек претендует на должность веб-верстальщика. Можно спросить его насчет IE6 и bootstrap. Например, как заставить работать bootstrap на ie6 :) Этот вопрос взят из живой практики, когда претендент индус (в прямом смысле) начал нести какую-то ахинею. Что сразу дало понимание о его уровне знаний.
Возможно головоломки нужны, но по теме. Допустим человек устраивается программистом, можно попросить его решить простенькую задачу: «Подсчитать сколько раз встречается каждое слово в тексте». Например: «машина стояла, а другая машина ехала». Итого «машина» встречается 2 раза, остальные слова по одному разу. И даешь тестовый текст на пару тысяч слов.
Далее, смотрим на его решение. На языке python правильное решение занимает всего 2 строки. А вот неправильное решение, но работающее, может занимать 30 строк. Это тут же дает понимание насколько претендент хорошо знает данный язык программирования.
Или, например, если человек претендует на должность веб-верстальщика. Можно спросить его насчет IE6 и bootstrap. Например, как заставить работать bootstrap на ie6 :) Этот вопрос взят из живой практики, когда претендент индус (в прямом смысле) начал нести какую-то ахинею. Что сразу дало понимание о его уровне знаний.
Что значит «неправильное решение, но работающее»? :)
Вообще, примеры задач, которые вы привели, это не головоломки.
Вообще, примеры задач, которые вы привели, это не головоломки.
Можно вытираться туалетной бумагой, а можно газеткой. Оба решения — рабочие, но правильным будет — туалетная бумага.
Нет, это все-таки головоломка, если человек впервые сталкивается с туалетной бумагой, а до этого он вытирался подорожником. Он должен зрительно догадаться, что газетка — для чтения, а вот мягкое и белое — для вытирания.
Я доходчиво объяснил? :)
Нет, это все-таки головоломка, если человек впервые сталкивается с туалетной бумагой, а до этого он вытирался подорожником. Он должен зрительно догадаться, что газетка — для чтения, а вот мягкое и белое — для вытирания.
Я доходчиво объяснил? :)
а какое правильное решение, по-вашему?
words=text.split()
dict((word,words.count(word)) for word in set(words))
?
words=text.split()
dict((word,words.count(word)) for word in set(words))
?
на должность веб-верстальщика. Можно спросить его насчет IE6
Можно и насчёт IE5, чего стесняться?
Синьор действительно премерзкое слово. Как и джуниор. Как и девелопер. И все остальные подобные слова, появлению которых нет никакого оправдания.
По большому счету я с автором согласен.
Но, на самом деле трудно сказать, какой действительно явный критерий на то, когда можно взять человека на работу. От одних я слышал, что нужны знания в первую очередь, от других — желание и возможность обучаться. Третьи высылают тестовые задания. И во всем этом, черт подери есть смысл.
Я, когда шел на свое первое собеседование на позицию программиста, успел пару лет попрограммировать на PHP «в стол». Как не странно, мне выслали тестовое задание и, как не странно я его сделал. Мне предложили работу PHP программиста и первую зарплату в Н евро и… я отказался.
Через пару месяцев я кандидировался на Junior Java Developer позицию. Мне выслали тестовое задание, я 2 недели упорно сидел и делал его по 12-14 часов в сутки, а потом было еще и тех. собеседование. Мне предложили зарплату в 1.2*Н евро и… я отказался, поскольку мне предложила другая фирма З/П в 1.5*Н евро и менторство опытных программистов после краткого тех. интервью по всему фишечкам Java.
После испытательного срока, через 4 месяца, моя З/П стала составлять 2*Н евро.
И, как это не странно, идя на свое первое собеседование я уже знал, что такое абстрактный класс и чем он отличается от интерфейса, как работать с потоками и некоторые шаблоны «банды 4-ех». Но некоторых вещей и не знал. Что-то я узнал, но что-то еще и до сих пор не знаю, но наличие работы и ЗП не мешает мне работать над собой и развиваться. А не просто тупо гуглить и лепить куски говно-кода бездумно, «лишь бы заработало».
Но, на самом деле трудно сказать, какой действительно явный критерий на то, когда можно взять человека на работу. От одних я слышал, что нужны знания в первую очередь, от других — желание и возможность обучаться. Третьи высылают тестовые задания. И во всем этом, черт подери есть смысл.
Я, когда шел на свое первое собеседование на позицию программиста, успел пару лет попрограммировать на PHP «в стол». Как не странно, мне выслали тестовое задание и, как не странно я его сделал. Мне предложили работу PHP программиста и первую зарплату в Н евро и… я отказался.
Через пару месяцев я кандидировался на Junior Java Developer позицию. Мне выслали тестовое задание, я 2 недели упорно сидел и делал его по 12-14 часов в сутки, а потом было еще и тех. собеседование. Мне предложили зарплату в 1.2*Н евро и… я отказался, поскольку мне предложила другая фирма З/П в 1.5*Н евро и менторство опытных программистов после краткого тех. интервью по всему фишечкам Java.
После испытательного срока, через 4 месяца, моя З/П стала составлять 2*Н евро.
И, как это не странно, идя на свое первое собеседование я уже знал, что такое абстрактный класс и чем он отличается от интерфейса, как работать с потоками и некоторые шаблоны «банды 4-ех». Но некоторых вещей и не знал. Что-то я узнал, но что-то еще и до сих пор не знаю, но наличие работы и ЗП не мешает мне работать над собой и развиваться. А не просто тупо гуглить и лепить куски говно-кода бездумно, «лишь бы заработало».
Круто! Классная заметка.
Это ведь прекрасная возможность сделать все иначе, и непревзойденным качеством захватить рынок! (не ирония. ну, может процентов на 10)
Никто не зажрался.
Времена и ценности меняются. Они динамичны.
Какие-то параметры растут, что-то падает вниз.
Негативное мышление чаще всего притягивается ко второму пути, так что…
Времена и ценности меняются. Они динамичны.
Какие-то параметры растут, что-то падает вниз.
Негативное мышление чаще всего притягивается ко второму пути, так что…
После прочтения, побежал читать статьи по абстрактным классам и интерфейсам, уфф, ну и напугали же вы меня сударь.
Недавно выступал на одном из форумов перед студентами-айтишниками.
Я спокоен за наше будущее — а будет ровно так, как и сейчас, ппц.
Так-то, господа…
Я спокоен за наше будущее — а будет ровно так, как и сейчас, ппц.
Так-то, господа…
«о х*р его знает, чем абстрактный класс отличается от интерфейса» — походу вопрос очень популярен :) Гугл кишит вариантами ответов на него…
Ох… Судя по комментам, все полезли читать чем интерфейс отличается от абстрактного класса. Автор спалил такой хороший критерий знания основ компьютерных наук. Теперь придётся искать что-то новое, такое же простое и сложное одновременно.
Я вас умоляю. Существует миллионы вопросов, которые характеризуют знания в этой области. Например, как вы объясните существование позитивного и негативного нуля (0 и -0)?
Кто 100% знает ответ, молчать и улыбаться!
Кто 100% знает ответ, молчать и улыбаться!
А чем абстрактный класс отличается от интерфейса?
Кто же это такой умный минусует, школьник Вася которые реально знает? Так пусть не минусует, а ответит.
Поддерживаю. Цитата:
Когда я говорил, что нужно писать технические статьи, вы продолжали читать хабр и обсуждать компании. Теперь у нас хабр в шоколаде, а технические статьи никто не пишет.ИМХО, много говорить не надо. Лучше бы автор написал техническую статью на эту тему — чем отличается интерфейс от абстрактного класса — чем мусолил тезисы «а я говорил!..». Не понимаю, за что народ плюсует такую откровенную попсу.
За что же все так настольный теннис ругают когда говорят об IT-компаниях?:)
Я, например, совершенно не стесняюсь того, что вместо безперерывного 8-10-часового «получения знаний» — я делаю перерывы для игры в теннис. Еще не встречал лучшего способа для разминки мышц, суставов и глаз.
Я, например, совершенно не стесняюсь того, что вместо безперерывного 8-10-часового «получения знаний» — я делаю перерывы для игры в теннис. Еще не встречал лучшего способа для разминки мышц, суставов и глаз.
НЛО прилетело и опубликовало эту надпись здесь
Всё верно, результаты плачевные. Но, может быть, вместо того, чтобы говорить, попробовать делать? ;)
Вас никто не послушает к сожалению, потому что даже если дать вам денег на компанию, компания вашего образца долго не протянет. А всё потому что дать +ххх денег проще, не нужно заморачиватся и больинство ваших конкурентов так и будут делать. А ваш сотрудник в которого вы вложились посчитает что challenge challenge-ом, но лишних 500 тугриков в месяц, это 6000$ в год что составляет неплохую суму, или жена его съест, или тупой одногрупник, на Camry, а ты на Focus-е.
К сожалению пока офсорсинг рулит, быть умным не окупается да и спроса нет, всем нужны пачки «индусов» на решение типовых задач. И ничего не изменится пока спрос существенно превышает предложение. Большинству не нужны ваши Python, Ruby, F#, Actor Model, моделирование процесов им нужны ASP.NET, Sharepoint, Struts и «вот эту кнопочку сделать жолтенькой, а при клике она разворачивается в банер». Вроде бы выход в продуктовых компаниях, но если туда менеджеры идут с оффсорса с тем же мышлением и конкурируют они с офсорсом то чаще всего получается то же самое.
Есть некоторые приятные иссключения вроде Яндекса, но ведь нужно платить существенно выше по рынку, сколько офсорсов это выдержит.
Проблема в рамках нашей маленькой экосистемы слаборешаема, вон даже у китайцев такая-же ситуация (12-й слайд).
К сожалению пока офсорсинг рулит, быть умным не окупается да и спроса нет, всем нужны пачки «индусов» на решение типовых задач. И ничего не изменится пока спрос существенно превышает предложение. Большинству не нужны ваши Python, Ruby, F#, Actor Model, моделирование процесов им нужны ASP.NET, Sharepoint, Struts и «вот эту кнопочку сделать жолтенькой, а при клике она разворачивается в банер». Вроде бы выход в продуктовых компаниях, но если туда менеджеры идут с оффсорса с тем же мышлением и конкурируют они с офсорсом то чаще всего получается то же самое.
Есть некоторые приятные иссключения вроде Яндекса, но ведь нужно платить существенно выше по рынку, сколько офсорсов это выдержит.
Проблема в рамках нашей маленькой экосистемы слаборешаема, вон даже у китайцев такая-же ситуация (12-й слайд).
Ненавижу вопрос про круглые люки. Не понимал его никогда. Потому что я видел разные.
Теперь буду знать. Отвечать теперь буду по тому что так было в спецификации (требованиях).
Теперь буду знать. Отвечать теперь буду по тому что так было в спецификации (требованиях).
Когда я говорил… Когда я говорил… Хочется спросить: А ЧТО ТЫ СДЕЛАЛ?
Это тоже обращение ко все тому же собирательному образу.
Это тоже обращение ко все тому же собирательному образу.
Хорошо написано, только причем тут теннисисты? :)
Верните стол! Навык теряется!!!
У меня то как раз теннисного стола никогда не было на работе, поэтому сразу и не понял этой фразы, а вы то сами сегодня уже сколько партий сыграли?
Ни сегодня, ни в этом году, ни в последние лет 5 уже. Был целый спортзал так его на офисы порезали. При том что постоянно сокращение идет! За производительность труда можно разными способами бороться, но получается как правило с перегибами. Уже за это время дважды комп сменился рабочий и разок мебель, а ракетка так и пылится. А ведь польза реальная была, главное не увлекаться %) Но теперь социалку у нас только за деньги из кармана работника признают.
— все равно х*р его знает, чем абстрактный класс отличается от интерфейса.
Ничем. И то и другое — программисткие игрушки.
Ничем. И то и другое — программисткие игрушки.
Это я сломал плотину!
Яростно плюсую!
Когда я говорил…