Это смотря с какой целью народ набирают. Когда в аутрорсинговой конторе стоит задача быстро подобрать под жирный проект допустим 10 спецов-явистов, причем единственное, но жесткое требование заказчика — идеальное знание Java core и какого-либо фреймворка, то можете поверить, на собеседовании будут гонять именно по Java core и по этому фреймворку. И как раз нужно будет отвечать в режиме «вопросы здесь задаю не я». Причина проста, через неделю аналогичные же вопросы будут задаваться этому же уже сотруднику в таком же режиме, но уже менеджером заказчика из-за океана, по телефону, и у менеджера запросто может оказаться сложный для наших ребят, допустим, индийский акцент. Там должно быть очень четко, вопрос — ответ, иначе проект контора может просто не получить.
Зачем же рефлексией, это уже чит, с таким подходом можно просто все поля пабликами делать. Наш Article хороший, умеет себя сериализовывать, бинарный формат, последовательно пишет в поток содержимое своих полей. Это так архитектор того проекта задумал изначально, в лучших традициях конца 90х годов. Он молодец, че. Был. Проект уже 15 лет в продакшене, и сейчас мы просто дописываем код, добавляем новые фичи. Вот, возникла потребность категории в статьи добавить.
А, забыл добавить, движок проекта успешно жужжит примерно на тридцати тысячах хостов партнеров, которые время от времени получают от нас обновления, в том числе обновления либы, включающей в себя класс Article. И что они там у себя дописали для работы с классом Article, какие плагины и т.д. мы не знаем, и это не наше дело. У них может быть и рефлекшен, и унаследование нашего теплого лампового Article в свой монстрокласс с переопределением всех методов, и что угодно.
У класса Atricle нет, а у какого-нибудь другого класса ArticleManager могут и быть. Как насчет имплементации метода saveArticle(Article a)? Сделали. Допустим, сохраняем сериализованные объекты класса Article со сжатием, всё работает… точнее работало, до того, как кто-то залез руками в наш любимый Article и что-то туда добавил. :)
Такой подход часто встречается, когда сериализованные данные где-либо хранятся — в сессии ли, в БД ли, в файловой системе ли, и т.д. Или другой пример, если кто делает ремотные вызовы, передавая экземпляры класса как параметры или возвращая их. В этом случае аналогично используется сериализация. При изменении класса формат сериализованых данных уже будет другим, если, конечно, не реализовывать сериализацию самому. Вполне возможно, что и пользователям класса придется вносить соответствующие изменения в свой код, но вообще они могут это и не сразу заметить, что чревато.
В общем, это лишь пример, подчеркивающий, что принцип OCP оправдывает себя в большинстве случаев. Просто еще один шаг в сторону безопасного программирования.
Основные принципы ООП — инкапсуляция, наследование, полиморфизм и абстракция. 20 лет назад основными принципами ООП считались только первые три, именно это мы и застали в свое время в ВУЗах. Абстракцию в этот перечень добавили позднее. Все остальное — уже от лукавого, то есть нельзя назвать основными принципами ООП.
SOLID — это лишь хорошие правила (можно сказать, принципы) дизайна, которым можно следовать или не следовать. Так же как и DRY, KISS и т.д., их много.
Возможно, это был вопрос-детектор на собеседовании, чтобы проверить, может ли специалист аргументированно отстаивать свою точку зрения.
Тоже возраст приближается к 40. И тоже некоторое время назад было нечто похожее. Решение нашел, помогло вот что:
1. Ранее я терялся, когда задавали простые вопросы по базовым либам, API и т.д. Подготовился и сдал сертификационные экзамены по нескольким технологиям. Сертификаты не факт что помогут в поиске работы, но сама подготовка и экзамен сильно помогут в систематизации знаний. Впрочем, от сертификатов польза всё равно есть — очень добавляют уверенности в себе.
2. Я терялся, когда задавали вопросы с упоминанием незнакомых названий алгоритмов и структур данных, по оценке сложности алгоритмов, по различным деревьям и т.д. Прошел несколько курсов, в том числе и на Курсере. По алгоритмам, технологиям и различной теории. Помимо всего прочего это еще и неслабая тренировка английского, плюс, узнал кучу новых терминов, касающихся давно привычных вещей.
3. Терялся, когда прямо на собеседовании просили сходу написать какую-либо мелкую программку, например генератор простых чисел, комбинаторные задачки и т.д. Волновался, опечатывался, ошибался, спешил, выбирал неоптимальные решения и т.д. Мне это не нравилось. Занялся спортивным программированием, решил весьма большое количество задачек, и теперь всякую мелкоту получается сходу решать моментально.
4. Вообще терялся на собеседованиях, особенно когда задавали провокационные вопросы, типа про слона в холодильнике. Специально потратил массу времени, чтобы разобраться, какие вообще бывают вопросы на собеседованиях, какие вопросы задаются в крупных компаниях, какие ответы оптимальны. Особенно пригодились индийские сайты, где ихние программеры делились друг с другом реальными вопросами с собеседований и детально разбирали ответы. Сейчас их что-то не видно… раньше были.
5. Терялся, когда на собеседовании спрашивали про владение английским языком. На одном из собеседований попросили перевести какой-то текст, я не смог, было очень неудобно. Пошел на хорошие курсы, потом параллельно занятия с репетитором, потом второй репетитор. Получилось.
6. Терялся, когда спрашивали, сколько хочу денег. Вообще не мог себе цены сложить. Решил вопрос кардинально. Так как все вышесказанное (обучение, курсы, проектики для себя и т.д.) занимало кучу времени, вообще уволился с работы. Стал свободным человеком, занялся самообразованием, научился жить очень скромно с минимумом денег, хотя было непросто перестроиться после программерских зарплат. Потом настал момент, когда уже по скилам был готов работать чуть ли не в любой конторе в своем городе, но решил, что ну его, нужно идти дальше. Ранее как-то попробовал работать менеджером, не понравилось, показалось, что туповатая работа функционера, да и не очень-то получалось. Свой бизнес решил не заводить, хотя чуть было не попробовал… тоже оказалось что не интересно, а деньги, как я к этому времени понял, это вообще ничто.
7. Но возраст, мысли всякие, что делать, кто я, что я… Рекрутеры постоянно заваливали предложениями, и однажды согласился поработать за границей. И там я увидел такое… в общем, 50- или 60-летний программист — это в Европе нормально. И только тогда я успокоился. Теперь спокойно пишу код в своё удовольствие, постоянно переключаюсь на те или иные новые технологии, слушаю те или иные курсы, также, вот, учу еще один иностранный язык. То есть кризис прошел. ))
Совет автору: если данная тема тяготит, то, если есть возможность, попробуйте на несколько лет сменить обстановку. Скажем, поработав пару лет в Европе, можете быть уверенными, что потом, если вернетесь, отечественные конторы просто завалят прекрасными предложениями. Ну а если сейчас всё в порядке, тогда то, что я написал, можете игнорировать. ))
Использовал finalize, но только лишь для одной цели… когда искал возможные причины утечки памяти, добавлял в finalize логирование. Другого применения для этого метода в реальном проекте не нашел.
Оказывается я не один такой. Аналогично, мне написали номер, и про 12 часов. И никакого емейла. В истории платежей этого платежа я не вижу. И теперь непонятно, получилось ли оплатить, или нет, то ли снимутся деньги с кредитки, то ли нет. На всякий случай номер я, конечно, записал… но как-то печально получилось.
Если студия не потрудилась оформить передачу прав от фрилансера себе, то она не может гарантировать заказчику, что потом фрилансер не затаскает этого заказчика по судам за незаконное использование результатов творческого труда.
Например, по-умолчанию (если это не оговорено в договоре) автор может требовать от заказчика упоминания о нем в том виде, как сам автор захочет, может требовать недопустимости искажений своего произведения, может требовать дополнительной оплаты, компенсации морального ущерба, или вообще может требовать прекратить использовать свое произведение, и т.д. И закон будет всецело на стороне автора.
Большая часть этих проблем решается договором между студией и фрилансером. Вот пример. Кому в здравом уме может быть нужен дизайн сайта, в который будет невозможно вносить изменения в будущем? А ведь по-умолчанию это именно так, фрилансер может это требовать, и это право оговорено отдельной статьей в ГК РФ. Поэтому нужно получать разрешение автора на модификацию произведения. И там много подобных тонкостей.
Это не дыра, а фича. Вы отдаете готовый сайт заказчику, а авторское право на дизайн принадлежит фрилансеру, то есть создателю дизайна. Это нормально и правильно.
Еще можно отдельно указать, что не входит в разработку сайта. Например, не входит наполнение сайта контентом, поисковая оптимизация, и т.д. Некоторые заказчики это не понимают, по-своему трактуя фразу «сайт под ключ».
А может быть там нет call потому, что автор кода забыл поставить return перед рекурсивным вызовом функции chet, и, соответственно, компилятор определил, что делать этот вызов не имеет смысла, и просто исключил его?
А, забыл добавить, движок проекта успешно жужжит примерно на тридцати тысячах хостов партнеров, которые время от времени получают от нас обновления, в том числе обновления либы, включающей в себя класс Article. И что они там у себя дописали для работы с классом Article, какие плагины и т.д. мы не знаем, и это не наше дело. У них может быть и рефлекшен, и унаследование нашего теплого лампового Article в свой монстрокласс с переопределением всех методов, и что угодно.
В общем, это лишь пример, подчеркивающий, что принцип OCP оправдывает себя в большинстве случаев. Просто еще один шаг в сторону безопасного программирования.
Основные принципы ООП — инкапсуляция, наследование, полиморфизм и абстракция. 20 лет назад основными принципами ООП считались только первые три, именно это мы и застали в свое время в ВУЗах. Абстракцию в этот перечень добавили позднее. Все остальное — уже от лукавого, то есть нельзя назвать основными принципами ООП.
SOLID — это лишь хорошие правила (можно сказать, принципы) дизайна, которым можно следовать или не следовать. Так же как и DRY, KISS и т.д., их много.
Возможно, это был вопрос-детектор на собеседовании, чтобы проверить, может ли специалист аргументированно отстаивать свою точку зрения.
Иными словами, существующее поведение (если это можно так назвать) таки меняется. Хотя это от способа сериализации зависит, конечно.
1. Ранее я терялся, когда задавали простые вопросы по базовым либам, API и т.д. Подготовился и сдал сертификационные экзамены по нескольким технологиям. Сертификаты не факт что помогут в поиске работы, но сама подготовка и экзамен сильно помогут в систематизации знаний. Впрочем, от сертификатов польза всё равно есть — очень добавляют уверенности в себе.
2. Я терялся, когда задавали вопросы с упоминанием незнакомых названий алгоритмов и структур данных, по оценке сложности алгоритмов, по различным деревьям и т.д. Прошел несколько курсов, в том числе и на Курсере. По алгоритмам, технологиям и различной теории. Помимо всего прочего это еще и неслабая тренировка английского, плюс, узнал кучу новых терминов, касающихся давно привычных вещей.
3. Терялся, когда прямо на собеседовании просили сходу написать какую-либо мелкую программку, например генератор простых чисел, комбинаторные задачки и т.д. Волновался, опечатывался, ошибался, спешил, выбирал неоптимальные решения и т.д. Мне это не нравилось. Занялся спортивным программированием, решил весьма большое количество задачек, и теперь всякую мелкоту получается сходу решать моментально.
4. Вообще терялся на собеседованиях, особенно когда задавали провокационные вопросы, типа про слона в холодильнике. Специально потратил массу времени, чтобы разобраться, какие вообще бывают вопросы на собеседованиях, какие вопросы задаются в крупных компаниях, какие ответы оптимальны. Особенно пригодились индийские сайты, где ихние программеры делились друг с другом реальными вопросами с собеседований и детально разбирали ответы. Сейчас их что-то не видно… раньше были.
5. Терялся, когда на собеседовании спрашивали про владение английским языком. На одном из собеседований попросили перевести какой-то текст, я не смог, было очень неудобно. Пошел на хорошие курсы, потом параллельно занятия с репетитором, потом второй репетитор. Получилось.
6. Терялся, когда спрашивали, сколько хочу денег. Вообще не мог себе цены сложить. Решил вопрос кардинально. Так как все вышесказанное (обучение, курсы, проектики для себя и т.д.) занимало кучу времени, вообще уволился с работы. Стал свободным человеком, занялся самообразованием, научился жить очень скромно с минимумом денег, хотя было непросто перестроиться после программерских зарплат. Потом настал момент, когда уже по скилам был готов работать чуть ли не в любой конторе в своем городе, но решил, что ну его, нужно идти дальше. Ранее как-то попробовал работать менеджером, не понравилось, показалось, что туповатая работа функционера, да и не очень-то получалось. Свой бизнес решил не заводить, хотя чуть было не попробовал… тоже оказалось что не интересно, а деньги, как я к этому времени понял, это вообще ничто.
7. Но возраст, мысли всякие, что делать, кто я, что я… Рекрутеры постоянно заваливали предложениями, и однажды согласился поработать за границей. И там я увидел такое… в общем, 50- или 60-летний программист — это в Европе нормально. И только тогда я успокоился. Теперь спокойно пишу код в своё удовольствие, постоянно переключаюсь на те или иные новые технологии, слушаю те или иные курсы, также, вот, учу еще один иностранный язык. То есть кризис прошел. ))
Совет автору: если данная тема тяготит, то, если есть возможность, попробуйте на несколько лет сменить обстановку. Скажем, поработав пару лет в Европе, можете быть уверенными, что потом, если вернетесь, отечественные конторы просто завалят прекрасными предложениями. Ну а если сейчас всё в порядке, тогда то, что я написал, можете игнорировать. ))
Например, по-умолчанию (если это не оговорено в договоре) автор может требовать от заказчика упоминания о нем в том виде, как сам автор захочет, может требовать недопустимости искажений своего произведения, может требовать дополнительной оплаты, компенсации морального ущерба, или вообще может требовать прекратить использовать свое произведение, и т.д. И закон будет всецело на стороне автора.
Большая часть этих проблем решается договором между студией и фрилансером. Вот пример. Кому в здравом уме может быть нужен дизайн сайта, в который будет невозможно вносить изменения в будущем? А ведь по-умолчанию это именно так, фрилансер может это требовать, и это право оговорено отдельной статьей в ГК РФ. Поэтому нужно получать разрешение автора на модификацию произведения. И там много подобных тонкостей.
int chet(int n) {
for (; n; n/=10) if (n%2) return 0;
return 1;
}