Чому створення екземпляра таким, яким воно є?

Я навчився 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();

Мені здається, мені цікаво, чи є краща відповідь, ніж "це просто так робиться".

Чи буде колись щось_ельс Боб = нова особа ()?

Так, через спадщину. Якщо:

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();

і компілятор виводити тип змінного Бобу від виклику конструктора 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інтерфейсом.

Інший приклад, коли два типи різняться, - це заводський метод, який вибирає певний підклас для екземпляру, а потім повертає його як базовий тип, тому абоненту не потрібно знати про деталі реалізації, наприклад, вибір "політики".

Висновок типу може виправити надмірність вихідного коду. Наприклад, на Java

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

створить правильний вид списку завдяки виводу типу та декларації

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

У деяких мовах висновок типу йде далі, наприклад, у C ++

auto p = new Person();

Словами мирянина:

• Відокремлення декларації від інстанції допомагає відокремити, хто використовує об'єкти, від того, хто їх створює
• Коли ви це зробите, поліпорфізм увімкнено, оскільки, поки інстанційований тип є підтипом типу декларації, весь код із використанням змінної буде працювати
• У сильно набраних мовах ви повинні оголосити змінну із зазначенням її типу, просто зробивши, var = new Process()ви не оголошуєте змінну спочатку.

Йдеться також про рівень контролю над тим, що відбувається. Якщо оголошення об’єкта / змінної автоматично викликає конструктор, наприклад, якщо

Person somePerson;

автоматично було таким же, як

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

тоді ви ніколи не зможете використовувати (наприклад) статичні заводські методи для створення об'єктів, а не конструкторів за замовчуванням, тобто бувають випадки, коли ви не хочете викликати конструктор для нового екземпляра об'єкта.

Цей приклад пояснюється в Joshua Bloch «s Effective Java (Пункт 1 досить іронічно!)