Если бы в C# не поддерживалась перегрузка методов, вы были бы вынуждены создать четыре члена с уникальными именами, что, как можете убедиться, весьма далеко от идеала.
public class Triangle {
// Глупость…
public void DrawWithInts(int x, int y, int height, int width) {…}
public void DrawWithFloats(float x, float y, float height, float width) {…}
public void DrawWithPoints(Point upperLeft, Point bottomRight) {…}
public void DrawWithRect(Rect r) {…}
}
Но не забывайте о том, что при перегрузке члена возвращаемый тип не может быть независимым. Так, следующий вариант просто недопустим.
public class Triangle {
…
// Ошибка! Нельзя перегружать методы
// на основе возвращаемых значений!
public float GetX(){…}
public int GetX(){…}
}
Использование this для возвратных ссылок в C#
Обратите внимание на то, что другой конструктор класса Employee использует ключевое слово C# this.
// Явное использование "this" для разрешения конфликтов имен.
publiс Employee(string fullName, int empID, float currPay) {
// Присваивание входных параметров данным состояния.
this.fullName = fullName;
this.empID = empID;
this.currPay
}
Это ключевое слово C# используется тогда, когда требуется явно сослаться на поля и члены
// В отсутствие конфликта имен "this" подразумевается.
public Employee(string name, int id, float pay) {
fullName = name;
empID = id;
currPay = pay;
}
В данном случае нет необходимости явно добавлять префикс this к именам членов-переменных Employee, потому что конфликт имен уже исключен. Компилятор может самостоятельно выяснить области видимости используемых членов-переменных, и в этой ситуации this называют
public Employee(string name, int Id, float pay) {
this.fullName = name;
this.empID = id;
this.currPay = pay;
}
Замечание. Статические члены типа не могут использовать ключевое слово this в контексте метода. В этом есть смысл, поскольку статические члены-функции действуют на уровне класса (а не объекта). На уровне класса нет this!
Передача вызовов конструктора с помощью this
Другим вариантом использования ключевого слова this является такая реализация вызова одним конструктором другого, при которой не возникает избыточной логики инициализации члена. Рассмотрим следующую модификацию класса Employee.
public class Employee {
…
public Employee(string fullName, int empID, float currPay) {
this.fullName = fullName;
this.empID = empID;
this.currPay = currPay;
}
// Если пользователь вызовет этот конструктор, то
// передать вызов версии с тремя аргументами.
public Employee(string fullName) : this(fullName, IDGenerator.GetNewEmpID(), 0.0F) {}
…
}
Эта итерация класса Employee определяет два пользовательских конструктора, и второй из них имеет единственный параметр (имя индивидуума). Однако для построения полноценного нового Employee вы хотите гарантировать наличие соответствующего ID и значения зарплаты. Предположим, что у вас есть пользовательский класс (IDGenerator) со статическим методом GetNewEmpID(), тем или иным образом генерирующим ID нового работника. Собрав множество начальных параметров, вы передаете запрос создания объекта конструктору с тремя аргументами.
Если не передавать вызов, то придется добавить в каждый конструктор избыточный программный код.