Использование “основы” в имени класса
Помимо playerPrefs, другой грязный способ заключается в том, чтобы сохранить объект во время загрузки уровня, вызывая DontDestroyOnLoad на нем.
DontDestroyOnLoad (transform.gameObject);
Любой скрипт, прикрепленный к игровому объекту, сохранится, а также переменные в скрипте. Функция DontDestroyOnLoad обычно используется для сохранения целого GameObject, включая прикрепленные к нему компоненты, и любые дочерние объекты, которые он имеет в иерархии.
Вы можете создать пустой GameObject и поместить только скрипт, содержащий переменные, которые вы хотите сохранить на нем.
12 ответов
Я склонен добавлять Основной суффикс к названию базового класса, только если это существует с технической точки зрения (для совместного использования некоторого кода) и действительно не составляет применимого класса самостоятельно (таким образом, все эти классы абстрактны). Это довольно редкие случаи, хотя, и должен избежаться так же, как классы Помощника.
Я принимаю сторону "нет" по точно причине рефакторинга, которую Вы процитировали.
класс А нужно назвать в честь того, что он логически представляет, и только Класс объекта действительно действительно Основа. Метафизика ftw :)
<час>ре: Опция B, нет ничего путающего приблизительно
namespace MySpecificNamespace
{
MyClass: MyCommonNamespace.MyClass
{
}
}
Классы, которые имеют то же имя как их родительские классы, прослушивают меня ни к какому концу. В Java java.sql. Дата расширяет java.util. Дата. Это является очень раздражающим, потому что необходимо указать точный класс, Вы хотите импортировать или иначе указать имя класса полностью (включая пакет/пространство имен).
Лично я предпочитаю называть вещи, как они; если Базовый или Абстрактный класс существует только для обеспечения частичной реализации чего-то и не представляет интерфейс для той вещи, часто приемлемо поместить слово Краткий обзор или Основа на ее имя. Однако, если тот класс представляет интерфейс также, то необходимо просто назвать его в честь того, что он делает.
, Например, в Java, у нас есть интерфейс Connection (для соединений с БД). Это только что назвало Соединение, не IConnection. Вы используете его как это:
Connection con = getConnectionFromSomewhere();
при создании драйвера JDBC и потребности реализовать соединение у Вас могли бы быть ConnectionBase или AbstractConnection, который является нижним уровнем детали реализации Вашего конкретного Соединения. Вы могли бы иметь
abstract class AbstractConnection implements Connection
class OracleConnection extends AbstractConnection
или что-то как этот. Клиенты Вашего кода, однако, никогда не видят AbstractConnection, и при этом они не видят OracleConnection, они только видят Соединение.
Так, в целом, классы, которые предназначены, чтобы быть обычно полезными, нужно назвать в честь того, что они представляют/, тогда как классы, которые являются помощниками для обслуживания/организации кода, можно назвать в честь того, каковы они.
пикосекунда я очень не хочу назвать Интерфейсы со мной. Люди называют все свои классы с C? Это - 2009! Ваш IDE может сказать Вам, какой объект то есть, в нечетном случае, когда даже имеет значение, если это - интерфейс или класс.
"Все Ваши BaseClass, принадлежат нам".
я принимаю сторону категорического не единственного исключения. Если Вы пишете приложение для управления военными установками или бейсбольными стадионами, пойдите для него.
Я думаю, что стоит викифицировать этот вопрос.
FWIW, я соглашаюсь. Я обычно пытаюсь найти более "универсальный" термин для своих базовых классов. Таким образом, если бы я имею "Клиентский" класс и должен представить новый базовый класс для него, я пошел бы с "Контактом" или чем-то, а не "CustomerBase".
Я также предложил бы нет, но не бросать в камне...
После молитвы OO, Ваша система именования должна лучше всего представить основные объекты, которые код, как предполагается, инкапсулирует. Не должно действительно быть никакого 'метаязыка', связанного с фактическим синтаксическим составом предпочтительного языка программирования там.
Тем не менее, если Ваш объект действительно абстрактен и Вы действительно не видите, что он изменяется в ближайшее время, существует аргумент, что добавление 'Основы' помогает с общей удобочитаемостью.
Как с большинством вещей, нет никакого общего права, и неправильно ответьте - это зависит от полного расположения Вашей кодовой базы, что этот определенный код, как предполагается, представляет и внутренний стиль, который Вы имеете. Просто попытайтесь быть последовательными.
основа, используемая где-нибудь еще?
Я также не принимаю сторону никакого лагеря... помещают Основу туда сегодня, и через 6 месяцев кто-то будет бить класс MyDerivedClass в Вас кодовая база, в то время как Вы не смотрите.
В Java я склонен обеспечивать базовое внедрение интерфейса Foo в абстрактном классе FooBase. Я думаю, что это совершенно в порядке, и устанавливает связь с интерфейсом, очень ясным и регулярным.
Без интерфейса я назвал бы абстрактный базовый класс Foo.
Я соглашаюсь, AbstractFoo является достойным решением. Я пытаюсь выбрать имена, которым не нужны дополнительные прилагательные. Я уклонился бы от использования Основы.
Я думаю, что этого нужно, вероятно, избежать, если это возможно, в пользу идентификатора, который на самом деле описывает, каково это!
на Этот вопрос трудно ответить, потому что это абстрактно. Я мог бы, например, рассмотреть вызов основы MyClassA и MyClassB, "MyClass".
Я обычно иду с IFoo для интерфейса и AbstractFoo для скелетной реализации, которая является соединением конвенций Java и.NET.