Хоть какой-то интерес вызвал ноутбук от Леново - такую функцию действительно хотел бы в своём рабочем ноутбуке, так как всегда не хватает места видеть весь нужный софт и всегда используются внешние мониторы. С вот такой надстройкой должно быть куда удобнее работать - банально делим экран на 2 части, в нижней - IDE, в верхней - браузер или логи или дебаггер.
А максимально неинтересный - ноутбук от Самсунга по очевидным причинам
купил бы, вещь интересная - но вот дизайн настолько кондовый, такое ощущение, что его в архитектурном бюро 1978 года Спиртозаводска рисовали (при всём уважении к этому городу)
сравнить с оригинальным уокманом - такое я бы купил, а вот это современное поделие - нет
Если ты к примеру делаешь, форму к БД - надо ли создавать классы, соответствующие предметам из этой БД
а тут с опытом приходит) неизбежно на первых порах у вас буду получаться классы-божественные объекты или наоборот - слишком много слишком атомарных классов. Но это не страшно, этим так-то многие популярные фреймворки грешат - где-то слишком много классов, прослоек и дроблений, чтобы максимально гибко можно было выстроить структуру, а где-то на одну строчку в дб - один класс со всем набором функций, которые могут понадобиться.
В общем, если хочется вынести какой-то айтем в класс - берите и смело выносите, так будет проще. Всё равно сразу грамотную иерархию классов не построить - но хотя бы вы получите прозрачную и понятную (хоть и, допустим, избыточную) структуру. С практикой будут приходить какие-то моменты, ну и хорошо бы где-то получать на работе проектную практику - смотреть как сделано, слушать от старших коллег, как делать, на крайняк спрашивать критики и чатГПТ
Что до тупорылого джуна - много проектов мечтают про таких, которые бы просто сидели и убирали рутину за мидлами/сениорами и чтобы это не надо было перепроверять как за ЧатГПТ или Copilot. И за это будут с удовольствием платиться деньги, вам будут выделять какое-то время, менторить, устраивать интернатуры, смотреть ваш код и предлагать вам смотреть куски чужого кода, разбираться, что там сделано и зачем. ИТ с удовольствием пожрёт любого адекватного человека в ряды свои. "Девки с дойками так и плачут по дембелю" - это про это) Много кто из джунов просто идут в ит "за бабками", минимально собираясь впускать в себя новый материал, для них это просто - работа за деньги. Я бы на вашем месте не переживал, а учился и пробовал, если есть возможность и желание (не знаю ваших жизненных обстоятельств).
Но уверенным 100% нужно быть. У меня тоже так бывало - в 32 пришёл в одну контору, где мне прямым текстом сказали "вы слишком старый быть джуном", это прямая цитата. И я у них спросил - а какая им разница, если меня устраивают стек, проект и ставка - "ну, вам у нас неловко будет, у нас одни молодые ребята". Ну ок, здесь не прокатило - наняли в другой компании, где был нужен джун.
Так что не переживайте из-за таких мелочей как излишество классов) Это как вы ещё авомобиль не купили, а переживаете, что гаража нету) Постепенно ешьте слона, по частям))
у меня ситуация наоборот - я отлично понял всё это, полюбил и использую, а вот собственно с программированием как решением алгоритмической задачи - огромные проблемы, могу решить только самые примитивные случаи и задачи. Более того, я когда впервые понял ООП и научился писать через классы - я всё что угодно пытался тащить в те классы, надо и не надо))
Объект - это абстрактный предмет или явление, абстракция. Мы представляем что-то, что может что-то делать и имеет какие-то базовые свойства. Например, кубик (условно - игральный). Кубик можно кидать, из кубика можно строить башенку, кубик можно покрасить в какой-то цвет. Или перекрасить.
Интерфейс, соответственно - как описание кубика. Грубо говоря "нам пригодится что угодно - абы его можно было кидать, абы из него можно было строить, абы его можно было покрасить, если объект выполнит эти условия - мы готовы признать его КУБИКОПОДОБНЫМ и использовать в нашем коде" или даже "делайте что хотите - но абы из него можно было строить, бросать и красить"
И вот на основе объекта мы можем создать "экземпляр" (один инстанс) - как будто у нас был чертёж кубика и мы сделали по этому чертежу 1 кубик. И он прям кубик как кубик - соответствует интерфейсу, его можно бросать и из него можно строить пирамидку, это - его базовые свойства. И как у программной сущности каждый экземпляр имеет какую-то свою привязку-идентификатор, для которой мы в памяти записываем свойства только этого кубика - так мы их будем различать и сохранять индивидуально заданные свойства.
Ещё при создании экземпляра у нас используется метод "конструктор", в котором можно задать, чтобы, например, кубик сразу покрасили в красный цвет - тогда свойство экземпляра сразу после создания получит аттрибут - "красный": $this color = 'red'; и теперь в память для экземпляра именно этого кубика ($this) будет записано "красный". Ну а если этот метод оставить пустым - кубик создатся как есть и цвет можно будет задать/перезадать потом.
А потом приходит менеджмент и говорит: "да, классные кубики, но они из глины всегда делались, со временем грани оббиваются, мы вот тут думаем это исправить и заодно расширять ассортимент и будем делать кубики из дерева и из металла". То есть, для кубиков нужно прям новое свойство - материал, мы теперь его точно хотим знать и быть уверены в нашей продукции. Описание кубика останется таким же - "чтобы из него строилось, кидалось и цвета разные" - это значит, что интерфейс кубика менять не нужно, а нужно добавить новый атрибут для объекта "кубик" - для нашего "чертежа", на основе которого мы создаём экземпляры кубиков.
И мы возвращаемся на уровень выше - от экземпляра к объекту, которому даём новое свойство - material. Волшебным образом теперь все новые экземпляры кубиков будут иметь это свойство. Можно доделать метод "конструктор" так, чтобы он каждый раз спрашивал - из чего будет кубик. Ну нам не тяжело, будем указывать - дерево или металл.
Это - довольно важный момент в жизни любого объекта или библиотеки - когда мы что-то такое добавили, чего раньше прям не было. Все новые кубики будут деревянные или металлические, а если взять старый кубик - он будет "никакой" в плане материала. Это как раз тот момент в разработке программного обеспечения, когда заводят волынку про "обратная совместимость нарушена" и вот такие обновления обычно называют "мажорное" - update 2.0.1. 1 в данном случае означает версию какого-то мелкого дополнения, исправление ошибок, то есть - 1 раз что-то было мелкое сделано, 0 обозначает "минорные" обновления, когда мы добавили что-то новое, но оно не помешает использовананию старых объектов. А вот цифра 2 - это как раз "мажорное" изменения, то есть, нам уже не удастся использовать "старые" кубики, ведь у них не будет "материала" - а мы уже настроились поджигать кубики или магнитить (что менеджмент попросит), поэтому старые кубики прям совсем не подойдут.
----
Ну и "полирнём" "тремя китами" ООП: наследование, инкапсуляция, полиморфизм.
Инкапсуляция - это та невидимая работа, которая переводит наше взаимодействие с кубиком в физические изменения кода кубика, хранящегося в оперативной памяти и имеющего идентификатор. Грубо говоря, мы просто говорим, что этот кубик - красный - и он станет красным. Нам никто не вынесет конторскую книгу, мы не будем её всю читать и искать идентификатор именно этого кубика, разбираться - как он там в памяти хранится, он записан двоичным кодом или может, текстом или ещё как-то. И нам не нужно задумываться - а кто или что там объясняет, что из этого кубика можно строить что-то - "оно как-то само, где-то там, унутри".
А если бы наш "кубик" не был инкапсулирован (то есть не был классом) - нам бы приходилось вручную запрашивать идентификатор в памяти компьютера, выбирать из него объект, смотреть и проверять - а что мы там получили, где оно и что оно может или нет.
Соответственно, есть языки программирования, которые поддерживают инкапсуляцию, есть такие, которые не поддерживают - их называют "низкого" уровня, а первые, соответственно, "высокого". Отличие приблизительно как общение с очень опытным работником, который знает, где что лежит как работать - и как с совсем зелёным новичком, который прям не знает ничего нигде: с новичком нужно возиться и прям подробнейше ему всё разъяснять, где и что лежит и как делается, зато все те инструкции он будет выполнять чётко так, как вы ему сказали. А опытный работник будет всё делать с полуслова, но у вас уже не будет всего понимания - а где он взял этот гаечный ключ, который принёс - взял на складе, нашёл, украл, сделал сам.
Здесь к слову можно ещё добавить про "императивные" языки и "декларативные", там сходная ситуация: первые - это прям надо дотошные инструкции писать: "пойди вот туда, сделай 43 шага, найди шкаф, найди третью ячейку, найди там ключи, возьми самый большой, принеси сюда" - а вторый (например, код SQL или код HTML) - "иди принеси чем там гайки крутить". Оба вида нужны, да оба на своих уровнях, так и сосуществуют). Как правило, про декларативные языки говорят, что это не языки программирования - хотя проектировать (писать сценарии) на них тоже нужно)
Вернёмся к кубикам и посмотрим - что там с полиморфизмом. А ничего, это просто возможность делать экземпляры кубиков разными способами. Если кубик из дерева - ну хочешь - топором теши, или на деревопильном станке выпиливай или из бревна долотом выдолби - "мы доверяем вашему профессионализму")) А если кубик из металла - ну хотите - целиком отливайте, или на токарном станке выточить попробуйте, или там на лазерном ЧПУ-станке вырежьте - на не принципиально, пока его можно кидать, из него можно строить, его можно красить. В итоге мы будем иметь кучу полиморфных кубиков - будут сделаты по разному, а свойства будуть иметь нужные. Значит - их можно будет продать и менеджмент будет доволен: "какие молодцы наши разработчики - умеют по-всякому")))
Ну и осталось наследование. Пришёл менеджмент и говорит, мол, пользователи жалуются - если строить башню из кубиков - получается столб, некрасиво, вы там добавьте новый кубик - который крыша. Получается, теперь нужно 2 объекта: кирпичик (кубоид, 6 граней) и крыша (пирамида, 5 граней). Вроде бы интерфейсно всё то же самое - кидать, строить, красить, но для крыши ещё и свои свойства нужны - ведь она может ставиться только сверху других кубиков и только одна, больше ничего на шпиль крыши не поставить.
Получается, пирамидка должна делать что-то такое новое, что ей прям совсем нужно, а кубику вообще необязательно - а именно пирамидке нужно уникальное поведение - проверка, на кого её кладут: если это будет кубик - подходит, если там будет пирамидка - уже нельзя.
Можно это свойство добавить в объект кубика - но кубик может создавать экземпляры без этой проверки, это только пирамидке надо. Вот в этих случаях, чтобы не фаршировать ненужными свойствами готовые объекты мы применяем "наследование" - наследуем описание какого-то объекта и добавляем нужные свойства и методы или действия.
И вот мы создаём новый объект "Пирамидка", который такой же, как "Кубик", но имеет свой метод, который проверяет, участвует ли пирамидка в строительстве башни и если да - на какую фигуру она кладётся.
Можем ещё на этом примере докинуть SOLID:
1 не фаршируй кубик методами всуе, разделяй объекты, чтобы каждый содержал нужные ему свойства и поведения-методы;
2 если тебе нужен какой-то особенный кубик - создай новый объект, не вороши в уже созданных, ведь они - чертежы для экземпляров, их кто-то может использовать и поменяв что-то в этих чертежах - ты их подставишь делать не такие кубики;
3 если какая-то фигурка описана на основе кубика - она может иметь свои свойства и методы, но должна иметь все те же свойства и уметь всё то же, что имел и умел кубик; нарушение этого принципа ведёт к нарушению обратной совместимости, несёт смуту и непонятки - как это пирамидку можно окрасить краской, а кубик - нельзя? Если кубик можно покрасить - значит, и пирамидка должна уметь окрашиваться. Ведь все знают про кубики LEGO, но никто не знает про шарики - потому что шарик уже не будет крепиться и не будет иметь смысла как фигурка конструктора. Можно ли его выпускать? Можно. Но это уже не конструктор будет - что же ты из шариков построишь?)) Ничего)
4ый пункт про интерфейсы говорит: вот у нас был интерфейс "Кубикоподобное", он создавался, чтобы делать кубикоподобные детали. Потом мы добавили пирамидку, у которой есть свои методы. Так вот если мы хотим делать пирамидкоподобные детали - правильно для пирамидки создать свой интерфейс - "Пирамидкоподобное", а не добавлять новые штуки в "Кубикоподобное". Каждый новый объект если нуждается в описании - должен получать своё описание по своим свойствам и методам, лучше иметь 10 разных интерфейсов, написанных чётко для своих объектов, чем один интерфейс с целым списком свойств и методов, которые каждому объекту придётся проверять - а кубик ли он, а может, он пирамидка? нет? А может, он цылиндр?
Так делать нехорошо) Кубик должен проверять только описание для кубика, пирамидка для проверки должна иметь своё описание для пирамидки, это несёт иерархию и разделение объектов, а что толку иметь одно описание на все объекты? Это как когда вы заполняете большую форму на 20 пунктов и ошиблись в пункте адрес, нажимаете "Редактировать" - а вам все поля формы сбросило, нужно всё заново указывать - это нехорошо, каждое поле должно иметь свою кнопку "Редактировать (адрес)", которая будет отвечать только за своё поле.
5ый пункт - очень прост, он просит не привязываться к конкретным случаям и свойствам, а "мыслить ширше". Например, были у нас кубики, из глины делались, но у них оббивались грани - ну, теперь давайте делать кубики из дерева и не из дерева, добавим свойство "деревянный" для объекта Кубик и каждый экземпляр пусть указывает при создании - деревянный он или не деревянный.
Так делать нехорошо, нужно мыслить не категорией ремесленника, а проектировщика, мы должны зависеть не от дерево/не дерево, а мы должны учитывать материал будущего экземпляра. Поэтому мы добавили свойство "материал" - это - правильно и хорошо, и мы можем увидеть это хотя бы по тому бонусу, что никакие новые материалы не вызовут проблем и кубики из них можно будет прекрасно делать - хоть из стекла, а хоть из резины, да хоть из теста печь.
А вот если бы мы оставили свойство "деревянный" - "не деревянный", мы бы, во-первых, не знали бы, вот те экземпляры, которые "недеревянные" - окей, так а из чего же они там? Сахар? Пластилин? Из яблока вырезали? Мы бы знали только, что этот кубик - "недеревянный", а на все остальные случаи приходилось бы ещё какие-то проверки писать, чтобы узнать - из чего тот кубик. Так что куда лучше сразу продумать и придумать абстрактные свойства, чем намертво завязываться на какие-то конкретные материалы или аттрибуты, даже для двух материалов это будет плохо работать ,так как у нас будут материалы из дерева и не из дерева и уже буквально для трёх материалов мы получаем кашу: у нас кубики из дерева, не из дерева из металла и не из дерева, не из металла. И опять же мы получаем то же самое - непонятку "не из дерева и не из металл" - так из чего он? И опять же следующим наследованным классам придётся добавлять методы и проверки - из чего ж там следующие придуманные кубики высекать решили.
по Мэдисону согласен - он стримил, ещё когда это немодно было, начинал с видеообзоров на треш-игры, да в трешовой же манере, имел свой стиль. Не сказал бы, что фанат его творчества, но заслуги определённые есть
по легендарным играм - Дальнобойщики 2 в каждом компьютерном клубе крутились. Я бы сказал, эта игра принесла понимание того, что игра может быть про автомобили, но не обязательно при этом про гонки, а и какой-то элемент планирования/менеджмента. Опять же это, если не ошибаюсь, была первая игра про автомобили, где были задействованы местные реалии и автомобили, что на то время было невероятно - как же, игра, где "Камазы" и маршрут в Шахты.
по киберспортсменам - про "Соло" согласен, а вот Ярослав, скорее, не как киберспортсмен, а больше как деятель и просветитель внёс чудовищный вклад в популяризацию и развитие Доты и сообщества, один проект "Фишки" чего стоит - проект подстегнул кучу людей пересмотреть отношение к игре, в которую они играют, в плане подхода к нюансам и тонкостям, к взаимодействию скилов, к особенностям работы механик. Куча людей это подстегнуло искать такие "фишки", моменты и баги, многие пересмотрели свои отыгрыши на любимых персонажах с учётом особенностей.
у знакомого преподавателя предпенсионного возраста в подвале жилого дома была некислая железная дорога на столе метра 4 на 6, которую он неспешно развивал десятилетиями, делал диарамы, ландшафт и всё такое. Рассказывал байку, что у него один железнодорожный переезд с динамиком, через который была звуковая индикация, что переезд закрывается для прохождения поезда, то этот динамик через раз ловил какое-то местное метровое радио и по этой причине переезд в цепь коммутировался через физический выключатель. К сожалению, байку продаю за что купил, лично не слышал.
п.с.: интересный был человек, "подарки" на пересдачу со студентов натурально брал вагонами "PiKo")
для детей - лего дупло или деревянная железная дорога на магнитах, поверьте: самое то.
Piko - это уже если ребёнок пару лет поиграл в паровозики, не перерос и интересуется + достиг какого-то возраста хотя бы лет в 10 - тогда имеет смысл купить стартовое кольцо, локомотив и пару вагонов, возможно, базовые набор для построения диарам.
Ну и тоже присоединюсь к комментаторам, которые говорят, что продукция PiKo - она немного не для детей, точнее, не для самых детей, а скорее, для фанатов железной дороги от самых младших сознательных возрастов до самых старших. Это как сложные настольные игры - для детей покатят только самые простые, даже если настольная игра очень крутая - до неё надо минимально "дорасти"
а это где-то специальные курсы или болезнь или что мешает каждому новому производителю ноутбуков вкупе с 99% уже существующих корячить раскладку клавиатуры?
Места же хоть залейся, ну сделайте нормальную полноразмерную клавиатуру, с нормальными кнопками, раскладкой, функциональными клавишами, добавьте клавиши для управления медийкой.
ну нет, там не потому отменили результаты выборов, что тикток, а потому что результаты выборов не устроили))) грубо говоря - "давайте переголосовывайте, бояре этого царя не хотят")
А ТикТок всего лишь удобный предлог, не было бы его - другую бы причину придумали, приплели бы что угодно
при минимальном желании средством, пригодным к пропаганде, можно признать абсолютно что угодно, даже ваш комментарий)
например, ваш комментарий пропагандирует семейное насилие - так как в тексте вашего комментария нету ни слова про то, что вы - против насилия в семье) Комиссия уже выехала с ножницами разрезать ваш паспорт)
ещё было бы неплохо, если бы действительно начали делать настоящую локализированную клавиатуру - это прям первым делом Якина на кол
p.s: естественно при полном сохранении двойного левого шифта и нормального большого энтера, хотите - правые альты и виндовс клавиши ворошите (как делают те же Logitech), а левый шифт и энтер будьте добры оставить нормальных размеров
справедливости ради, его новости выглядят на голову разумнее новостей альтернативных каналов, ему успешно удаётся избегать как минимум хайповости, истеричности и громких заявлений по горячим следам вбросов - а перед этим искушением очень многие не могут устоять и не вмазаться в хайп или впасть в истерику по самые уши, трепля нервы аудитории попусту, "курс валюты упал на 3% - а это значит, уже завтра экономика переживёт коллапс и превратится в тыкву - приглашаем всех на тыквенную кашу".
Хоть какой-то интерес вызвал ноутбук от Леново - такую функцию действительно хотел бы в своём рабочем ноутбуке, так как всегда не хватает места видеть весь нужный софт и всегда используются внешние мониторы. С вот такой надстройкой должно быть куда удобнее работать - банально делим экран на 2 части, в нижней - IDE, в верхней - браузер или логи или дебаггер.
А максимально неинтересный - ноутбук от Самсунга по очевидным причинам
"бесплатная игра - один раз купил и играешь себе бесплатно" (с)
купил бы, вещь интересная - но вот дизайн настолько кондовый, такое ощущение, что его в архитектурном бюро 1978 года Спиртозаводска рисовали (при всём уважении к этому городу)
сравнить с оригинальным уокманом - такое я бы купил, а вот это современное поделие - нет
вот бы на эту клавиатуру, да клавишу "Энтер" нормальную + блок управления мультимедиа - и тогда было бы интересно попробовать
а тут с опытом приходит) неизбежно на первых порах у вас буду получаться классы-божественные объекты или наоборот - слишком много слишком атомарных классов. Но это не страшно, этим так-то многие популярные фреймворки грешат - где-то слишком много классов, прослоек и дроблений, чтобы максимально гибко можно было выстроить структуру, а где-то на одну строчку в дб - один класс со всем набором функций, которые могут понадобиться.
В общем, если хочется вынести какой-то айтем в класс - берите и смело выносите, так будет проще. Всё равно сразу грамотную иерархию классов не построить - но хотя бы вы получите прозрачную и понятную (хоть и, допустим, избыточную) структуру. С практикой будут приходить какие-то моменты, ну и хорошо бы где-то получать на работе проектную практику - смотреть как сделано, слушать от старших коллег, как делать, на крайняк спрашивать критики и чатГПТ
Что до тупорылого джуна - много проектов мечтают про таких, которые бы просто сидели и убирали рутину за мидлами/сениорами и чтобы это не надо было перепроверять как за ЧатГПТ или Copilot. И за это будут с удовольствием платиться деньги, вам будут выделять какое-то время, менторить, устраивать интернатуры, смотреть ваш код и предлагать вам смотреть куски чужого кода, разбираться, что там сделано и зачем. ИТ с удовольствием пожрёт любого адекватного человека в ряды свои. "Девки с дойками так и плачут по дембелю" - это про это) Много кто из джунов просто идут в ит "за бабками", минимально собираясь впускать в себя новый материал, для них это просто - работа за деньги. Я бы на вашем месте не переживал, а учился и пробовал, если есть возможность и желание (не знаю ваших жизненных обстоятельств).
Но уверенным 100% нужно быть. У меня тоже так бывало - в 32 пришёл в одну контору, где мне прямым текстом сказали "вы слишком старый быть джуном", это прямая цитата. И я у них спросил - а какая им разница, если меня устраивают стек, проект и ставка - "ну, вам у нас неловко будет, у нас одни молодые ребята". Ну ок, здесь не прокатило - наняли в другой компании, где был нужен джун.
Так что не переживайте из-за таких мелочей как излишество классов) Это как вы ещё авомобиль не купили, а переживаете, что гаража нету) Постепенно ешьте слона, по частям))
у меня ситуация наоборот - я отлично понял всё это, полюбил и использую, а вот собственно с программированием как решением алгоритмической задачи - огромные проблемы, могу решить только самые примитивные случаи и задачи. Более того, я когда впервые понял ООП и научился писать через классы - я всё что угодно пытался тащить в те классы, надо и не надо))
Объект - это абстрактный предмет или явление, абстракция. Мы представляем что-то, что может что-то делать и имеет какие-то базовые свойства. Например, кубик (условно - игральный). Кубик можно кидать, из кубика можно строить башенку, кубик можно покрасить в какой-то цвет. Или перекрасить.
Интерфейс, соответственно - как описание кубика. Грубо говоря "нам пригодится что угодно - абы его можно было кидать, абы из него можно было строить, абы его можно было покрасить, если объект выполнит эти условия - мы готовы признать его КУБИКОПОДОБНЫМ и использовать в нашем коде" или даже "делайте что хотите - но абы из него можно было строить, бросать и красить"
И вот на основе объекта мы можем создать "экземпляр" (один инстанс) - как будто у нас был чертёж кубика и мы сделали по этому чертежу 1 кубик. И он прям кубик как кубик - соответствует интерфейсу, его можно бросать и из него можно строить пирамидку, это - его базовые свойства. И как у программной сущности каждый экземпляр имеет какую-то свою привязку-идентификатор, для которой мы в памяти записываем свойства только этого кубика - так мы их будем различать и сохранять индивидуально заданные свойства.
Ещё при создании экземпляра у нас используется метод "конструктор", в котором можно задать, чтобы, например, кубик сразу покрасили в красный цвет - тогда свойство экземпляра сразу после создания получит аттрибут - "красный": $this color = 'red'; и теперь в память для экземпляра именно этого кубика ($this) будет записано "красный". Ну а если этот метод оставить пустым - кубик создатся как есть и цвет можно будет задать/перезадать потом.
А потом приходит менеджмент и говорит: "да, классные кубики, но они из глины всегда делались, со временем грани оббиваются, мы вот тут думаем это исправить и заодно расширять ассортимент и будем делать кубики из дерева и из металла". То есть, для кубиков нужно прям новое свойство - материал, мы теперь его точно хотим знать и быть уверены в нашей продукции. Описание кубика останется таким же - "чтобы из него строилось, кидалось и цвета разные" - это значит, что интерфейс кубика менять не нужно, а нужно добавить новый атрибут для объекта "кубик" - для нашего "чертежа", на основе которого мы создаём экземпляры кубиков.
И мы возвращаемся на уровень выше - от экземпляра к объекту, которому даём новое свойство - material. Волшебным образом теперь все новые экземпляры кубиков будут иметь это свойство. Можно доделать метод "конструктор" так, чтобы он каждый раз спрашивал - из чего будет кубик. Ну нам не тяжело, будем указывать - дерево или металл.
Это - довольно важный момент в жизни любого объекта или библиотеки - когда мы что-то такое добавили, чего раньше прям не было. Все новые кубики будут деревянные или металлические, а если взять старый кубик - он будет "никакой" в плане материала. Это как раз тот момент в разработке программного обеспечения, когда заводят волынку про "обратная совместимость нарушена" и вот такие обновления обычно называют "мажорное" - update 2.0.1. 1 в данном случае означает версию какого-то мелкого дополнения, исправление ошибок, то есть - 1 раз что-то было мелкое сделано, 0 обозначает "минорные" обновления, когда мы добавили что-то новое, но оно не помешает использовананию старых объектов. А вот цифра 2 - это как раз "мажорное" изменения, то есть, нам уже не удастся использовать "старые" кубики, ведь у них не будет "материала" - а мы уже настроились поджигать кубики или магнитить (что менеджмент попросит), поэтому старые кубики прям совсем не подойдут.
----
Ну и "полирнём" "тремя китами" ООП: наследование, инкапсуляция, полиморфизм.
Инкапсуляция - это та невидимая работа, которая переводит наше взаимодействие с кубиком в физические изменения кода кубика, хранящегося в оперативной памяти и имеющего идентификатор. Грубо говоря, мы просто говорим, что этот кубик - красный - и он станет красным. Нам никто не вынесет конторскую книгу, мы не будем её всю читать и искать идентификатор именно этого кубика, разбираться - как он там в памяти хранится, он записан двоичным кодом или может, текстом или ещё как-то. И нам не нужно задумываться - а кто или что там объясняет, что из этого кубика можно строить что-то - "оно как-то само, где-то там, унутри".
А если бы наш "кубик" не был инкапсулирован (то есть не был классом) - нам бы приходилось вручную запрашивать идентификатор в памяти компьютера, выбирать из него объект, смотреть и проверять - а что мы там получили, где оно и что оно может или нет.
Соответственно, есть языки программирования, которые поддерживают инкапсуляцию, есть такие, которые не поддерживают - их называют "низкого" уровня, а первые, соответственно, "высокого". Отличие приблизительно как общение с очень опытным работником, который знает, где что лежит как работать - и как с совсем зелёным новичком, который прям не знает ничего нигде: с новичком нужно возиться и прям подробнейше ему всё разъяснять, где и что лежит и как делается, зато все те инструкции он будет выполнять чётко так, как вы ему сказали. А опытный работник будет всё делать с полуслова, но у вас уже не будет всего понимания - а где он взял этот гаечный ключ, который принёс - взял на складе, нашёл, украл, сделал сам.
Здесь к слову можно ещё добавить про "императивные" языки и "декларативные", там сходная ситуация: первые - это прям надо дотошные инструкции писать: "пойди вот туда, сделай 43 шага, найди шкаф, найди третью ячейку, найди там ключи, возьми самый большой, принеси сюда" - а вторый (например, код SQL или код HTML) - "иди принеси чем там гайки крутить". Оба вида нужны, да оба на своих уровнях, так и сосуществуют). Как правило, про декларативные языки говорят, что это не языки программирования - хотя проектировать (писать сценарии) на них тоже нужно)
Вернёмся к кубикам и посмотрим - что там с полиморфизмом. А ничего, это просто возможность делать экземпляры кубиков разными способами. Если кубик из дерева - ну хочешь - топором теши, или на деревопильном станке выпиливай или из бревна долотом выдолби - "мы доверяем вашему профессионализму")) А если кубик из металла - ну хотите - целиком отливайте, или на токарном станке выточить попробуйте, или там на лазерном ЧПУ-станке вырежьте - на не принципиально, пока его можно кидать, из него можно строить, его можно красить. В итоге мы будем иметь кучу полиморфных кубиков - будут сделаты по разному, а свойства будуть иметь нужные. Значит - их можно будет продать и менеджмент будет доволен: "какие молодцы наши разработчики - умеют по-всякому")))
Ну и осталось наследование. Пришёл менеджмент и говорит, мол, пользователи жалуются - если строить башню из кубиков - получается столб, некрасиво, вы там добавьте новый кубик - который крыша. Получается, теперь нужно 2 объекта: кирпичик (кубоид, 6 граней) и крыша (пирамида, 5 граней). Вроде бы интерфейсно всё то же самое - кидать, строить, красить, но для крыши ещё и свои свойства нужны - ведь она может ставиться только сверху других кубиков и только одна, больше ничего на шпиль крыши не поставить.
Получается, пирамидка должна делать что-то такое новое, что ей прям совсем нужно, а кубику вообще необязательно - а именно пирамидке нужно уникальное поведение - проверка, на кого её кладут: если это будет кубик - подходит, если там будет пирамидка - уже нельзя.
Можно это свойство добавить в объект кубика - но кубик может создавать экземпляры без этой проверки, это только пирамидке надо. Вот в этих случаях, чтобы не фаршировать ненужными свойствами готовые объекты мы применяем "наследование" - наследуем описание какого-то объекта и добавляем нужные свойства и методы или действия.
И вот мы создаём новый объект "Пирамидка", который такой же, как "Кубик", но имеет свой метод, который проверяет, участвует ли пирамидка в строительстве башни и если да - на какую фигуру она кладётся.
Можем ещё на этом примере докинуть SOLID:
1 не фаршируй кубик методами всуе, разделяй объекты, чтобы каждый содержал нужные ему свойства и поведения-методы;
2 если тебе нужен какой-то особенный кубик - создай новый объект, не вороши в уже созданных, ведь они - чертежы для экземпляров, их кто-то может использовать и поменяв что-то в этих чертежах - ты их подставишь делать не такие кубики;
3 если какая-то фигурка описана на основе кубика - она может иметь свои свойства и методы, но должна иметь все те же свойства и уметь всё то же, что имел и умел кубик; нарушение этого принципа ведёт к нарушению обратной совместимости, несёт смуту и непонятки - как это пирамидку можно окрасить краской, а кубик - нельзя? Если кубик можно покрасить - значит, и пирамидка должна уметь окрашиваться. Ведь все знают про кубики LEGO, но никто не знает про шарики - потому что шарик уже не будет крепиться и не будет иметь смысла как фигурка конструктора. Можно ли его выпускать? Можно. Но это уже не конструктор будет - что же ты из шариков построишь?)) Ничего)
4ый пункт про интерфейсы говорит: вот у нас был интерфейс "Кубикоподобное", он создавался, чтобы делать кубикоподобные детали. Потом мы добавили пирамидку, у которой есть свои методы. Так вот если мы хотим делать пирамидкоподобные детали - правильно для пирамидки создать свой интерфейс - "Пирамидкоподобное", а не добавлять новые штуки в "Кубикоподобное". Каждый новый объект если нуждается в описании - должен получать своё описание по своим свойствам и методам, лучше иметь 10 разных интерфейсов, написанных чётко для своих объектов, чем один интерфейс с целым списком свойств и методов, которые каждому объекту придётся проверять - а кубик ли он, а может, он пирамидка? нет? А может, он цылиндр?
Так делать нехорошо) Кубик должен проверять только описание для кубика, пирамидка для проверки должна иметь своё описание для пирамидки, это несёт иерархию и разделение объектов, а что толку иметь одно описание на все объекты? Это как когда вы заполняете большую форму на 20 пунктов и ошиблись в пункте адрес, нажимаете "Редактировать" - а вам все поля формы сбросило, нужно всё заново указывать - это нехорошо, каждое поле должно иметь свою кнопку "Редактировать (адрес)", которая будет отвечать только за своё поле.
5ый пункт - очень прост, он просит не привязываться к конкретным случаям и свойствам, а "мыслить ширше". Например, были у нас кубики, из глины делались, но у них оббивались грани - ну, теперь давайте делать кубики из дерева и не из дерева, добавим свойство "деревянный" для объекта Кубик и каждый экземпляр пусть указывает при создании - деревянный он или не деревянный.
Так делать нехорошо, нужно мыслить не категорией ремесленника, а проектировщика, мы должны зависеть не от дерево/не дерево, а мы должны учитывать материал будущего экземпляра. Поэтому мы добавили свойство "материал" - это - правильно и хорошо, и мы можем увидеть это хотя бы по тому бонусу, что никакие новые материалы не вызовут проблем и кубики из них можно будет прекрасно делать - хоть из стекла, а хоть из резины, да хоть из теста печь.
А вот если бы мы оставили свойство "деревянный" - "не деревянный", мы бы, во-первых, не знали бы, вот те экземпляры, которые "недеревянные" - окей, так а из чего же они там? Сахар? Пластилин? Из яблока вырезали? Мы бы знали только, что этот кубик - "недеревянный", а на все остальные случаи приходилось бы ещё какие-то проверки писать, чтобы узнать - из чего тот кубик.
Так что куда лучше сразу продумать и придумать абстрактные свойства, чем намертво завязываться на какие-то конкретные материалы или аттрибуты, даже для двух материалов это будет плохо работать ,так как у нас будут материалы из дерева и не из дерева и уже буквально для трёх материалов мы получаем кашу: у нас кубики из дерева, не из дерева из металла и не из дерева, не из металла. И опять же мы получаем то же самое - непонятку "не из дерева и не из металл" - так из чего он? И опять же следующим наследованным классам придётся добавлять методы и проверки - из чего ж там следующие придуманные кубики высекать решили.
попробуйте продукцию Logitech, например, MX Keys - их радиодонглы с технологией Lightspeed очень хороши, сам пользуюсь.
по Мэдисону согласен - он стримил, ещё когда это немодно было, начинал с видеообзоров на треш-игры, да в трешовой же манере, имел свой стиль. Не сказал бы, что фанат его творчества, но заслуги определённые есть
по легендарным играм - Дальнобойщики 2 в каждом компьютерном клубе крутились. Я бы сказал, эта игра принесла понимание того, что игра может быть про автомобили, но не обязательно при этом про гонки, а и какой-то элемент планирования/менеджмента. Опять же это, если не ошибаюсь, была первая игра про автомобили, где были задействованы местные реалии и автомобили, что на то время было невероятно - как же, игра, где "Камазы" и маршрут в Шахты.
по киберспортсменам - про "Соло" согласен, а вот Ярослав, скорее, не как киберспортсмен, а больше как деятель и просветитель внёс чудовищный вклад в популяризацию и развитие Доты и сообщества, один проект "Фишки" чего стоит - проект подстегнул кучу людей пересмотреть отношение к игре, в которую они играют, в плане подхода к нюансам и тонкостям, к взаимодействию скилов, к особенностям работы механик. Куча людей это подстегнуло искать такие "фишки", моменты и баги, многие пересмотрели свои отыгрыши на любимых персонажах с учётом особенностей.
у знакомого преподавателя предпенсионного возраста в подвале жилого дома была некислая железная дорога на столе метра 4 на 6, которую он неспешно развивал десятилетиями, делал диарамы, ландшафт и всё такое. Рассказывал байку, что у него один железнодорожный переезд с динамиком, через который была звуковая индикация, что переезд закрывается для прохождения поезда, то этот динамик через раз ловил какое-то местное метровое радио и по этой причине переезд в цепь коммутировался через физический выключатель. К сожалению, байку продаю за что купил, лично не слышал.
п.с.: интересный был человек, "подарки" на пересдачу со студентов натурально брал вагонами "PiKo")
для детей - лего дупло или деревянная железная дорога на магнитах, поверьте: самое то.
Piko - это уже если ребёнок пару лет поиграл в паровозики, не перерос и интересуется + достиг какого-то возраста хотя бы лет в 10 - тогда имеет смысл купить стартовое кольцо, локомотив и пару вагонов, возможно, базовые набор для построения диарам.
Ну и тоже присоединюсь к комментаторам, которые говорят, что продукция PiKo - она немного не для детей, точнее, не для самых детей, а скорее, для фанатов железной дороги от самых младших сознательных возрастов до самых старших. Это как сложные настольные игры - для детей покатят только самые простые, даже если настольная игра очень крутая - до неё надо минимально "дорасти"
а это где-то специальные курсы или болезнь или что мешает каждому новому производителю ноутбуков вкупе с 99% уже существующих корячить раскладку клавиатуры?
Места же хоть залейся, ну сделайте нормальную полноразмерную клавиатуру, с нормальными кнопками, раскладкой, функциональными клавишами, добавьте клавиши для управления медийкой.
ну нет, там не потому отменили результаты выборов, что тикток, а потому что результаты выборов не устроили))) грубо говоря - "давайте переголосовывайте, бояре этого царя не хотят")
А ТикТок всего лишь удобный предлог, не было бы его - другую бы причину придумали, приплели бы что угодно
а кто так не делает?)
при минимальном желании средством, пригодным к пропаганде, можно признать абсолютно что угодно, даже ваш комментарий)
например, ваш комментарий пропагандирует семейное насилие - так как в тексте вашего комментария нету ни слова про то, что вы - против насилия в семье) Комиссия уже выехала с ножницами разрезать ваш паспорт)
ещё было бы неплохо, если бы действительно начали делать настоящую локализированную клавиатуру - это прям первым делом
Якина на колp.s: естественно при полном сохранении двойного левого шифта и нормального большого энтера, хотите - правые альты и виндовс клавиши ворошите (как делают те же Logitech), а левый шифт и энтер будьте добры оставить нормальных размеров
Надеюсь, для продукции они придумают нормальные бренды и названия.
p.s: уже придумал им геймерскую мышку - ABR WALG ))
ну чего ж - год человек поработает за 70к, потом второй за 140к, а на третий уйдёт в курьеры на 200 или в другую компанию на 300)
вот тоже собирался написать то же самое, но вы меня опередили)
только этот человек, скорее, с планшетом и он курит))
справедливости ради, его новости выглядят на голову разумнее новостей альтернативных каналов, ему успешно удаётся избегать как минимум хайповости, истеричности и громких заявлений по горячим следам вбросов - а перед этим искушением очень многие не могут устоять и не вмазаться в хайп или впасть в истерику по самые уши, трепля нервы аудитории попусту, "курс валюты упал на 3% - а это значит, уже завтра экономика переживёт коллапс и превратится в тыкву - приглашаем всех на тыквенную кашу".
о да, с этим оно отлично справляется)