По вопросу «что мне делать с этим» может быть много ответов.
Более «формальный» способ предотвращения таких ошибок при разработке применяя дизайн по контракту в вашем коде. Это означает, что при разработке вы должны установить инварианты класса и / или даже предпосылки для функции и .
Короче говоря, инварианты класса гарантируют, что в вашем классе будут некоторые ограничения, которые не будут нарушены при нормальном использовании (и, следовательно, класс будет not получить в несогласованном состоянии). Предпосылки означают, что данные, данные как входные данные для функции / метода, должны соответствовать установленным ограничениям и никогда не нарушать их, а постулаты означают, что вывод функции / метода должен соответствовать установленным ограничениям снова не нарушая их. Условия контракта никогда не должны нарушаться во время выполнения программы без ошибок, поэтому дизайн по контракту проверяется на практике в режиме отладки, а отключен в выпусках , чтобы максимизировать развитую производительность системы.
Таким образом, вы можете избежать случаев NullReferenceException
, которые являются результатом нарушения установленных ограничений. Например, если вы используете свойство объекта X
в классе, а затем попытаетесь вызвать один из его методов, а X
имеет нулевое значение, то это приведет к NullReferenceException
:
public X { get; set; }
public void InvokeX()
{
X.DoSomething(); // if X value is null, you will get a NullReferenceException
}
Но если вы установите «свойство X никогда не должно иметь нулевого значения» в качестве предпосылки для метода, вы можете предотвратить описанный ранее сценарий:
//Using code contracts:
[ContractInvariantMethod]
protected void ObjectInvariant ()
{
Contract.Invariant ( X != null );
//...
}
По этой причине Код Контракт существует для приложений .NET.
В качестве альтернативы, дизайн по контракту может быть применен с использованием утверждений .
ОБНОВЛЕНИЕ: Стоит отметить, что этот термин был придуман Бертраном Майером в связи с его дизайном языка программирования Эйфеля .
Методы и конструкторы могут иметь одно и то же имя.
public class NewTest {
public static void main(final String[] args) {
TheClass();
new TheClass();
}
static void TheClass() {
System.out.println("Method");
}
static class TheClass {
TheClass() {
System.out.println("Constructor");
}
}
}
Является ли этот выбор дизайна языка хорошей идеей, является спорным, но так оно и работает.
Я не сейчас , почему разработчики java-языка решили добавить оператор new
к java-языку, но я не хочу его пропустить. Даже , если он может быть избыточным , если не разрешено давать классы, методы и поля с тем же именем, как и другие, которые уже были указаны в их ответах:
Потому что - это значительно улучшает читаемость. Каждый раз, когда я читал этот оператор new
, я сразу понял, что рождается новый объект.
Если вы пришли из C ++, почему вы удивлены? Разве C ++ не имеет того же new
, с той же целью? Java пытается следовать большей части синтаксиса C / C ++, это, скорее всего, причина.
Комментирует ответ artbristol: очень маловероятно, что разработчики Java сначала выложили пространства имен, а затем были вынуждены добавить новое ключевое слово. Скорее всего, наоборот: new
был первым, затем они обнаружили, что он позволяет им иметь имена конструкторов, сталкивающиеся с другими именами.
new
должен быть написан на Java для создания нового экземпляра объекта.
public class Foo {
public void test() {
final Foo foo1 = new Foo();
final Foo foo2 = Foo();
}
public Foo Foo() {
System.out.println("hello world");
return this;
}
}
Обратите внимание, что методы, начинающиеся с символа верхнего регистра, не рекомендуется на Java, чтобы избежать путаницы.
Верьте или нет, требуя использования new
для конструкторов - это вещь с именами. Следующие компилируются просто отлично:
public class Foo {
public Foo() {}
public void Foo() {}
}