Почему создание экземпляров такое, какое оно есть?

Я изучал C # в течение последних шести месяцев или около того и сейчас углубляюсь в Java. Мой вопрос касается создания экземпляров (на любом языке, на самом деле), и это больше: интересно, почему они сделали это таким образом. Возьми этот пример

Person Bob = new Person();

Есть ли причина, по которой объект указан дважды? Будет ли когда-нибудь something_else Bob = new Person()?

Казалось бы, если бы я следовал из конвенции, это было бы больше похоже на:

int XIsAnInt;
Person BobIsAPerson;

Или, возможно, один из них:

Person() Bob;
new Person Bob;
new Person() Bob;
Bob = new Person();

Полагаю, мне любопытно, есть ли лучший ответ, чем «это просто так».

Будет ли когда-нибудь что-то еще, Боб = new Person ()?

Да, по наследству. Если:

public class StackExchangeMember : Person {}

Потом:

Person bob = new StackExchangeMember();
Person sam = new Person();

Боб тоже человек, и, черт возьми, он не хочет, чтобы с ним обращались иначе, чем с кем-либо еще.

Кроме того, мы могли бы наделить Боба сверхспособностями:

public interface IModerator { }
public class StackOverFlowModerator : StackExchangeMember, IModerator {}

IModerator bob = new StackOverFlowModerator();

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

StackExchangeMember bob = new StackOverFlowModerator();

Затем, когда он находит какой-то плохой 1-й плакат, он сбрасывает свой плащ-невидимку и набрасывается на него.

((StackOverFlowModerator) bob).Smite(sam);

И тогда он может действовать невинно и все остальное потом:

((Person) bob).ImNotMeanIWasJustInstantiatedThatWay();

Давайте возьмем вашу первую строку кода и рассмотрим ее.

Person Bob = new Person();

Первый Person- это спецификация типа. В C # мы можем обойтись без этого, просто сказав

var Bob = new Person();

и компилятор определит тип переменной Bob из вызова конструктора Person().

Но вы можете написать что-то вроде этого:

IPerson Bob = new Person();

Где вы не выполняете весь API-контракт Person, а только контракт, указанный в интерфейсе IPerson.

1. Этот синтаксис в значительной степени унаследован от C ++, который, кстати, имеет оба:

   Person Bob;

   и

   Person *bob = new Bob();

   Первый для создания объекта в текущей области, второй для создания указателя на динамический объект.

2. Вы определенно можете иметь something_else Bob = new Person()

   IEnumerable<int> nums = new List<int>(){1,2,3,4}

   Здесь вы делаете две разные вещи, указывая тип локальной переменной numsи говорите, что хотите создать новый объект типа «Список» и поместить его туда.

3. C # вроде с вами согласен, потому что большую часть времени тип переменной идентичен тому, что вы в нее вставили, следовательно:

   var nums = new List<int>();

4. В некоторых языках вы стараетесь не указывать типы переменных, как в F # :

   let list123 = [ 1; 2; 3 ]

Существует огромная разница между int xи Person bob. intЭто intявляется intи он всегда должен быть intи не может быть ничем иным, как int. Даже если вы не инициализируете, intкогда объявляете его ( int x;), он все равно intустановлен на значение по умолчанию.

Однако, когда вы объявляете Person bob, существует большая гибкость в отношении того, к чему на bobсамом деле может относиться имя в любой момент времени. Он может ссылаться на a Personили ссылаться на некоторый другой класс, например Programmer, производный от Person; это может даже быть null, не ссылаясь ни на какой объект вообще.

Например:

  Person bob   = null;
  Person carol = new Person();
  Person ted   = new Programmer();
  Person alice = personFactory.functionThatReturnsSomeKindOfPersonOrNull();

Разработчики языка, безусловно, могли бы создать альтернативный синтаксис, который выполнял бы то же самое, что и Person carol = new Person()в меньшем количестве символов, но они все равно должны были бы разрешить Person carol = new Person() (или сделать какое-то странное правило, делающее этот конкретный один из четырех примеров выше недопустимым). Их больше заботило сохранение языка «простым», чем написание чрезвычайно лаконичного кода. Это, возможно, повлияло на их решение не предоставлять более короткий альтернативный синтаксис, но в любом случае это не было необходимо, и они не предоставили его.

Эти две декларации могут быть разными, но часто одинаковыми. Общий рекомендуемый шаблон в Java выглядит следующим образом:

List<String> list = new ArrayList<>();
Map<String, Integer> map = new HashMap<>();

Эти переменные listи mapобъявляются с использованием интерфейсов Listи в Mapто время как код создает конкретные реализации. Таким образом, остальная часть кода зависит только от интерфейсов, и легко выбрать другие классы реализации для создания экземпляров, например TreeMap, так как остальная часть кода не может зависеть от какой-либо части HashMapAPI, которая находится за пределамиMap интерфейса.

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

Вывод типа может исправить избыточность исходного кода. Например, на Яве

List<String> listOne = Collections.emptyList();

создаст правильный вид List благодаря выводу типа и объявлению

static <T> List<T> emptyList(); 

В некоторых языках вывод типов идет дальше, например, в C ++

auto p = new Person();

По словам непрофессионала:

• Отделение объявления от экземпляра помогает отделить тех, кто использует объекты, от тех, кто их создает
• Когда вы это делаете, полипорфизм включается, поскольку, пока созданный тип является подтипом типа объявления, весь код, использующий переменную, будет работать
• В строго типизированных языках вы должны объявить переменную с указанием ее типа, просто var = new Process()не объявляя переменную первой.

Это также об уровне контроля над тем, что происходит. Если объявление объекта / переменной автоматически вызывает конструктор, например, если

Person somePerson;

был автоматически такой же, как

Person somePerson = new Person(blah, blah..);

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

Этот пример объясняется в книге « Эффективная Java» Джошуа Блоха (пункт 1 достаточно иронически!)