12.12 на складе №4 был разгружен ламинат "..." с большим количеством брака. Пачки были отсортированы мной и подписаны, хорошие пачки «Х», а плохие пачки «П». При возврате товара поставщику, начальник склада ошибочно посчитал, что «Х» означает «х**вые», а «П» означает «п**датые», что в корне меняло ситуацию. Грузчики его поддержали и на возврат был отгружен качественный товар. Виновным в данном инциденте себя не признаю, услуги транспортной компании оплачивать отказываюсь.
Зы: вопросы которые я задаю Junior не сильно отличаются от тех что Senior. Просто ожидаю разный уровень ответов.
Теория — пару вопросов из этого списка, чуть под настроение(вычеты, сортировки, перестановки, графы, древья: чтото базовое что можно вывести на месте) и разные вопросы на многопоточность:
как устроен CopyOnWriteArrayList. Зачем он так устроен?
Когда имеет смысл паралелить алгортм(хорошо если знает закон Амдала)?
Прошу написать принципы реализации многопоточных списков и кольцевого буфера. а неблокирующие?
Прошу придумать как бы он реализовывал многопоточный HashMap в случае разных паттернов работы с ним.
Как бы он реализовал кеш для приложения? а персистентный?
Как можно остановить поток выполняющий код который не находится под нашим контролем?
Из чего состоит переключение контекста процессора между потоками и процессами? сколько оно стоит?
Когда не знает ответа на вопрос(или даже не понимает формулировки) поясняю ему вопрос, я хочу увидеть как он мыслит.
После прошу написать реалию минимального приложения, тоже под настроение и в зависимости от диалога: последние варианты были написать сервис быстро возвращающий среднее в массиве(то есть к нему по сети приходят запросы «добавить елемент a» и «верни среднее»). На задачку даю часа 3-4. Для этого даю ему некий костяк — интерфейс который он должен реализовать и интерфейсы которыми он может пользоваться. Сам быстренько реализую последние.
Тут смотрю как они пишет тесты и mock-реализации(и пишет ли), пишет ли комментарии, как структурирует код. Обычно я наблюдаю что это спрашивают устно, но ИМХО в таких вопросах устный ответ часто в корни разнится от реальности.
Я прекрасно понимаю, что такое инкапсуляция. Опять же, в SICP (почитайте таки для саморазвития — книга стоит на самом высоком месте в матрице компетентности программиста от Google) во 2-3 главах приводятся отличные примеры абстракции и инкапсуляции (см. реализацию работы с декартовыми и полярными координатами). А ваш пример отвратителен, поскольку вы подменяете одно понятие другим — логическое действие объекта «прикотовить» вы заменяете на установку его состояния на «включена». С точки зрения модели функция «включить плиту» бессмысленна, поскольку не приводит ни к каким значимым результатам. Именно по этой причине названия «начать работу» или «разогреть» являются гораздо более правильными в данном случае, но к установке свойств они не имеют никакого отношения. И да, эта функция может выполнять те же функции, что и «включить» — начать уменьшать переменную с топливом, увеличивать темпетаруту и т.д., и будет являться прекрасным примером инкапсуляции. Только вот к свойствам объекта и геттерам с сеттерами, о которых я говорил в своей статье, это уже не будет иметь никакого отношения. А для DTO объектов вы не придумаете примера, в котором установка свойства приведёт к каким-то действиям — просто по определению, потому что DTO-объекты на то и data transfer objects, что просто переносят данные и не выполняют никакой логики. Иначе это уже не DTO.
ну да, прикольно, но какое это отношение имеет к ООП? Вы про то, что одни понятие ООП подменило другими? Даже если так, то новые понятия гораздо проще воспринимать. Разве нет?
Я вам русским по белому написал: то, что вы расписываете как возможное достигнуть только в ООП, на самом деле является общеязыковым и уже 50 лет используется во всех возможных парадигмах. Вы пытаетесь показать, как круто писать в стиле ООП, но при этом не приводите ни одного значимого довода, ибо все аргументы в равной степени применимы к любой парадигмы лишь с заменой пары схожих понятий.
И нет, новые названия (именно названия, потому что понятия не менялись) — не проще воспринять, потому что вы отбрасываете опыт поколений, пользовавшихся теми же средствами, но с другим названием, и уже прочувствовавших на своих лбах все их грабли.
«И да, не забудьте про null — это одна из самых распространённых ошибок из-за недостатка типизации таких языков как Java (в C# вроде чуть полегче).» — если честно, не понял глубинный смысл вашего высказывания.
Вы не понимаете, но при этом обвиняете меня в глупости? Вот это круто. Я надеялся, что вы хотя бы сможете постоять за своё мнение.
Строгая типизация означает строгое соблюдение теории множеств — переменные одного типа (множества) не могут стать переменными другого типа, кроме случая, когда одно множество является надмножеством другого. Отсюда лезут косяки современных ОО языков. Значение null принадлежит сразу всем множествам, при этом не выполняя действия других объектов из этих множест. Если ваша функция принимает объект типа SomeObject, то она с удовольствием примет и значение null, но вызвать его методы или получить свойства уже не сможет — null чужой для множества SomeObject объект. Изобретение Тони Хоаром ссылки null было ошибкой на миллиард долларов, ведущая к многочисленным багам и крахам программ.
Есть и куча других примеров косяков ООП в плане типизации. Сама иерархия объектов противоположна теории множест — наследники имеют больший функционал, а значит с точки зрения множест являеются надмножествами, а не подмножествами. Конечно, необязательно опираться на математику при разработке, но тогда вы теряете очень сильный формальный язык, читайте — сильный инструмент верификации программ.
Ещё один пример — сужение типа за счёт явного приведения. Например, приведения Object к String. Современные языки активно используют этот инструмент, но не заставляют программиста проверять результат — в ООП неправильное приведение это «исключительная ситуация», хотя в других языках использовалась бы штатная проверка (дело не в механизме эксепшенов, конечно, дело в самом подходе ОО языков: эксепшены используются не в каких-то крайних случаях, а в самых обычных штатных ситуациях).
Про типизацию можно долго говорить, показывая в ОО языках элементы как статической, так и динамической типизаций. Но вы этого тупо не понимаете, потому что не знаете, что может быть по другому.
да нет, уважаемый, как раз это вы хотите сузить. Понятие объекта именно ООП вынесло на тот уровень, когда GoF могут с удовольствием создавать всякие мосты, фабрики. И нами это воспринимается нормально.
Во-первых, вы GoF ещё раз перечитайте. Там несколько раз говорится, что паттерны решают проблемы, с которыми ООП не может эффективно справиться. Так что чем больше паттернов, тем больше задач, с которыми голове ООП не может нормально справиться. Во-вторых, о да, понятие «что угодно» гораздо уже чем понятие «инстанс класса». Вы хотя читайте, что вам пишут. В ООП объектом называется только единый законченный элемент, хранящийся в одной области памяти. List в Java/C# — это именно один элемент, который уже хранит в себе коллекцию нужного типа. В Clojure и других ФЯ список может быть представлен цепочкой объектов, когда один указывает на другой (переменная списка хранит указатель на начало списка), но такой список всё равно будет считаться объектом. В Java/C# — нет, это уже что-то не цельное, не инкапсулирующее и т.д. А связные списки, хранящиеся как цепочки, открывают целый мир очень мощных алгоритмов.
Так что нет, уважаемый, инстанс класса — это гораздо меньше, чем просто объект.
Такие названия показывают наплевательское отношение разработчиков и/или непонимание сути вёрстки. Вся соль в том, что мне совершенно всё-равно, назвать этот метод "isAdult" или "isOlderThan18". Так само, как всё-равно, назвать класс "left" или "toolbar". Реализация не изменится, изменится только имя, которое для парсера совершенно не имеет смысла, пусть я его даже назву "sex" или "kak-ya-zdez-trahalsa-s-ie". Но если у вас проблема придумать осмысленное название классу элемента, то проблема в том, что вы просто не понимаете сути того, что вы делаете.
В современных ide отличная автозамена и при необходимости поменять все left на right не будет никакой проблемы. Но это просто хороший стиль программирования. Так само, как последовательные стандарты, разделение логики и представления, да и просто традиция писать все имена на английском, а не транслите.
Или вы не имеете ничего против названия класса «levaya-panel»? Это просто некрасиво и этому есть причины.
Теория — пару вопросов из этого списка, чуть под настроение(вычеты, сортировки, перестановки, графы, древья: чтото базовое что можно вывести на месте) и разные вопросы на многопоточность:
как устроен CopyOnWriteArrayList. Зачем он так устроен?
Когда имеет смысл паралелить алгортм(хорошо если знает закон Амдала)?
Прошу написать принципы реализации многопоточных списков и кольцевого буфера. а неблокирующие?
Прошу придумать как бы он реализовывал многопоточный HashMap в случае разных паттернов работы с ним.
Как бы он реализовал кеш для приложения? а персистентный?
Как можно остановить поток выполняющий код который не находится под нашим контролем?
Из чего состоит переключение контекста процессора между потоками и процессами? сколько оно стоит?
Когда не знает ответа на вопрос(или даже не понимает формулировки) поясняю ему вопрос, я хочу увидеть как он мыслит.
После прошу написать реалию минимального приложения, тоже под настроение и в зависимости от диалога: последние варианты были написать сервис быстро возвращающий среднее в массиве(то есть к нему по сети приходят запросы «добавить елемент a» и «верни среднее»). На задачку даю часа 3-4. Для этого даю ему некий костяк — интерфейс который он должен реализовать и интерфейсы которыми он может пользоваться. Сам быстренько реализую последние.
Тут смотрю как они пишет тесты и mock-реализации(и пишет ли), пишет ли комментарии, как структурирует код. Обычно я наблюдаю что это спрашивают устно, но ИМХО в таких вопросах устный ответ часто в корни разнится от реальности.
Я прекрасно понимаю, что такое инкапсуляция. Опять же, в SICP (почитайте таки для саморазвития — книга стоит на самом высоком месте в матрице компетентности программиста от Google) во 2-3 главах приводятся отличные примеры абстракции и инкапсуляции (см. реализацию работы с декартовыми и полярными координатами). А ваш пример отвратителен, поскольку вы подменяете одно понятие другим — логическое действие объекта «прикотовить» вы заменяете на установку его состояния на «включена». С точки зрения модели функция «включить плиту» бессмысленна, поскольку не приводит ни к каким значимым результатам. Именно по этой причине названия «начать работу» или «разогреть» являются гораздо более правильными в данном случае, но к установке свойств они не имеют никакого отношения. И да, эта функция может выполнять те же функции, что и «включить» — начать уменьшать переменную с топливом, увеличивать темпетаруту и т.д., и будет являться прекрасным примером инкапсуляции. Только вот к свойствам объекта и геттерам с сеттерами, о которых я говорил в своей статье, это уже не будет иметь никакого отношения. А для DTO объектов вы не придумаете примера, в котором установка свойства приведёт к каким-то действиям — просто по определению, потому что DTO-объекты на то и data transfer objects, что просто переносят данные и не выполняют никакой логики. Иначе это уже не DTO.
Я вам русским по белому написал: то, что вы расписываете как возможное достигнуть только в ООП, на самом деле является общеязыковым и уже 50 лет используется во всех возможных парадигмах. Вы пытаетесь показать, как круто писать в стиле ООП, но при этом не приводите ни одного значимого довода, ибо все аргументы в равной степени применимы к любой парадигмы лишь с заменой пары схожих понятий.
И нет, новые названия (именно названия, потому что понятия не менялись) — не проще воспринять, потому что вы отбрасываете опыт поколений, пользовавшихся теми же средствами, но с другим названием, и уже прочувствовавших на своих лбах все их грабли.
Вы не понимаете, но при этом обвиняете меня в глупости? Вот это круто. Я надеялся, что вы хотя бы сможете постоять за своё мнение.
Строгая типизация означает строгое соблюдение теории множеств — переменные одного типа (множества) не могут стать переменными другого типа, кроме случая, когда одно множество является надмножеством другого. Отсюда лезут косяки современных ОО языков. Значение null принадлежит сразу всем множествам, при этом не выполняя действия других объектов из этих множест. Если ваша функция принимает объект типа SomeObject, то она с удовольствием примет и значение null, но вызвать его методы или получить свойства уже не сможет — null чужой для множества SomeObject объект. Изобретение Тони Хоаром ссылки null было ошибкой на миллиард долларов, ведущая к многочисленным багам и крахам программ.
Есть и куча других примеров косяков ООП в плане типизации. Сама иерархия объектов противоположна теории множест — наследники имеют больший функционал, а значит с точки зрения множест являеются надмножествами, а не подмножествами. Конечно, необязательно опираться на математику при разработке, но тогда вы теряете очень сильный формальный язык, читайте — сильный инструмент верификации программ.
Ещё один пример — сужение типа за счёт явного приведения. Например, приведения Object к String. Современные языки активно используют этот инструмент, но не заставляют программиста проверять результат — в ООП неправильное приведение это «исключительная ситуация», хотя в других языках использовалась бы штатная проверка (дело не в механизме эксепшенов, конечно, дело в самом подходе ОО языков: эксепшены используются не в каких-то крайних случаях, а в самых обычных штатных ситуациях).
Про типизацию можно долго говорить, показывая в ОО языках элементы как статической, так и динамической типизаций. Но вы этого тупо не понимаете, потому что не знаете, что может быть по другому.
Во-первых, вы GoF ещё раз перечитайте. Там несколько раз говорится, что паттерны решают проблемы, с которыми ООП не может эффективно справиться. Так что чем больше паттернов, тем больше задач, с которыми голове ООП не может нормально справиться. Во-вторых, о да, понятие «что угодно» гораздо уже чем понятие «инстанс класса». Вы хотя читайте, что вам пишут. В ООП объектом называется только единый законченный элемент, хранящийся в одной области памяти. List в Java/C# — это именно один элемент, который уже хранит в себе коллекцию нужного типа. В Clojure и других ФЯ список может быть представлен цепочкой объектов, когда один указывает на другой (переменная списка хранит указатель на начало списка), но такой список всё равно будет считаться объектом. В Java/C# — нет, это уже что-то не цельное, не инкапсулирующее и т.д. А связные списки, хранящиеся как цепочки, открывают целый мир очень мощных алгоритмов.
Так что нет, уважаемый, инстанс класса — это гораздо меньше, чем просто объект.
isAdult" или "isOlderThan18". Так само, как всё-равно, назвать класс "left" или "toolbar". Реализация не изменится, изменится только имя, которое для парсера совершенно не имеет смысла, пусть я его даже назву "sex" или "kak-ya-zdez-trahalsa-s-ie". Но если у вас проблема придумать осмысленное название классу элемента, то проблема в том, что вы просто не понимаете сути того, что вы делаете.В современных ide отличная автозамена и при необходимости поменять все left на right не будет никакой проблемы. Но это просто хороший стиль программирования. Так само, как последовательные стандарты, разделение логики и представления, да и просто традиция писать все имена на английском, а не транслите.
Или вы не имеете ничего против названия класса «levaya-panel»? Это просто некрасиво и этому есть причины.