Дмитрий Каратаев

Открываете любую книгу по питону для начинающих и читаете, что переменная это просто ссылка.
Все ваши 100 позиций будут указывать на один и тот же объект в памяти.

Похоже на обфускацию данных, которую делают перед передачей базы сторонним разработчикам, которым нужны реальные данные для тестирования, но есть опасность утечки информации.

Тут в коментах понакидали, я немного разложу для понимания.
Сегодня программирование это не 1 область, типа " - хочу в программирование - вам вот в эту дверь".
Условно ее можно разделить на несколько подвидов, переход из которых в смежную будет сопровождаться некоторыми трудностями, особенно для новичка, по этому с направлением нужно определиться на берегу, или по крайней мере вовремя остановиться если увидели что это направление - не ваше.

1) Веб разработка. В свою очередь делится на 2 поднаправления: фронтенд - все что отрисовывается и обрабатывается на клиенте (то есть проще говоря в браузере), и бэкенд - все что относится к работе со стороны сервера. Фронтенд, как это ни странно, ограничен в языках более всего, тут только яваскрипт или что-то типа тайпскрипта, которое по итогоу в яваскрипт "компилируется". Бэк в этом плане более разношерстный, тут можно практически все использовать, но мэйнстрим это пхп, питон, ява, сишарп, руби-рельсы. Первые два в основном используют студии вебразработки, вторые два - в основном энтерпрайз, последний уже больше экзотика.
2) Геймдев. Как ни странно, тоже делится на 2 поднаправления: казуалки/мобилы и большие триплА проекты. В первом случае это сишарп + юнити (да, это не язык, а инструмент, но без него стек не полный), в редком случае что-то экзотическое. Во втором это скорее всего си++ и какой-то фреймворк, а-ля анриал или вулкан.
3) Энтерпрайз. Тут стандарт де факто - ява. Как вариант Сишарп, но гораздо реже.
4) Десктоп приложения. Простенькие консольные можно писать практически на чем угодно, более-менее обладающее интерфейсом тербует соответствующих gui библиотек, по типу Qt, gtk, ну и соответственно языков типа ява, си++, сишарп... Хочу заметить, что направление это весьма дохлое, в плане того что именно приложения для широких масс в последнее время практически не выпускаются, уступая место вебсервисам или мобильным приложениям, которые тоже не ахти какие рынки занимают...
5) Мобильная разработка. Зверь редкий, так как под мобилы больше игры делают. Именно разработка приложений достаточно узкий сегмент, ну и опять же - делится на разработку под андроид и под айфон. В первом случае языком разработки будет Котлин(в девичестве Ява), под айфон соответственно будет Свифт. Есть решения кроссплатформенные, по типу флаттера, но это не всегда подходит, так как некоторые функции под конкретную платформу будут недоступны.

Короче, определяетесь с направлением, пробуете, не нравится - берете следующее, с языками так же. По тому "в чем писать" определяться стоит по запросу "среда разработки для %языкнейм%"

для удобства программиста, чтобы он сразу видел что NodeRef является Serializable и не нужно было куда то проваливаться. В плане исполнения кода ни на что не влияет. Можно и убрать спокойно, чисто личные предпочтения

Соглашусь с предыдущими комментаторами, пример СЛИШКОМ высосан из пальца, чтобы по нему давать какие-то рекомендации.
Но в целом, бак должен быть отдельным объектом в составе машины, а никаким не "аругментом".
И у него может быть метод consumeFuel(miles)
Который может принимать длину дороги в качестве аргумента, и уменьшать количество топлива в соответствии с заложенной формулой.

Car.Tank.fillMax()
print Car.Tank.getLevel()
Car.Тank. consumeFuel(Road.length)
print Car.Tank.getLevel()

По поводу последнего варианта - всегда исходите из здравого смысла. Может ли быть дорога частью автомобиля? Нет, это очевидная бессмыслица. Дорога может быть частью поездки. Как и автомобиль. Вот в рамках объекта Trip они вполне могут взаимодействовать друг с другом.

Вообще, тут важно сразу понять, что ООП гораздо сложнее "базового" процедурного программирования, которое в принципе может осилить любой. Все эти циклы, условные переходы, функции, базовые алгоритмы, последовательное выполнение команд. Или даже асинхронное.

Но вот построение осмысленной иерархии классов - это на порядок сложнее. И очень хорошо, что вы об этом задумываетесь. Просто не надо думать, что это все вы освоите по щелчку пальцев, как перебор словаря, например.

Эта резкая разница в кривой обучения поначалу действительно обескураживает. Но надо просто себе уяснить, что да, тема требует гораздо больше усилий, и обязательного чтения учебников. Но при этом не надо идти на поводу у всяких "упростителей". Да, если задача - решить проблему, то надо ее решать доступными средствами. Но если задача - подняться на следующий профессиональный уровень, то надо грызть.

В одном соглашусь с ними: никогда не нужно делать два дела одновременно: и решать конкретную задачу, и учить новые концепции.
Поэтому лучшим вариантом написания кода будет такой: сначала наговнякать процедурный, но рабочий вариант.
А потом заняться его рефакторингом: посмотреть, какие можно использовать классы, как они могут взаимодействовать.

в примере с кораблём и пространством можно использовать паттерн "фабрика".
Делаешь третий класс, в нём поле, которое содержит Space, и метод который будет принимать координаты нового корабля и возвращать созданный экземпляр. В этом методе и будет проверка.

С другой стороны, если тебе ок, что корабль знает, в каком пространстве он создан - можно прямо в конструктор корабля такую проверку впихнуть или использовать паттерн "фабричный метод".

В любом случае, в отрыве от конкретной задачи, вопрос смысла не имеет.

Прямо в первой же строке ссылка, по которой находится ответ на ваш вопрос.

С точки зрения C# вы хотите не того, что нужно. В отличие от C++, где перегрузка операций даёт возможность сформировать индивидуальное поведение для каждого пользовательского типа, в C# для вас построили два основных стереотипа поведения - тип-ссылка и тип-значение - и предлагают выбрать один из них.

Вам нужно переформулировать задачу в более общую, и понять, что вы хотите сделать на самом деле, и для чего вам понадобилось переопределение присваивания. Судя по имени класса (Person), вы явно делаете с ним что-то не то.

К сожалению, алгоритмы применяются не очень часто, а во многих областях - практически не применяются. Могу лишь сказать, что чем фундаментальнее проект, тем больше там алгоритмов.

Например браузер. Лично мне приходилось в хромиуме писать и динамическое программирование и дихотомию и всякие хитрые структуры данных.

Из вашего списка скорее подходят бакенд и desktop. Еще очень алгоритмоемкая область - разработка игр. Вот там нужно много чего использовать, потому что надо все делать эффективно, иначе игра будет тормозить.

По поводу второго вопроса, похоже большинство разработчиков алгоритмы презирают. Считают что это не нужно знать вообще и очень ненавидят алгоритмические интервью в ФААНГах и им подражающим.

Степени - Math.Pow
Модуль - Math.Abs
Синус - Math.Sin

Привет!

Возможно проблема кроется в битности MS Access.
Откройте в MS Access: Файл -> Учетная запись -> О программе Access -> появится информация о программе, где указана ее битность.
Если, указано 32, то Вам нужно снести офис и поставить x64.



Второй Вариант - настройки компилятора для построения x86 решения.
Нашел вот тут подсказку.
А вот мануал по настройки VS Studio 2022 под запуск на нужной платформе.