Читаем Язык программирования С# 2005 и платформа .NET 2.0. полностью

Если бы в 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(){…}

}

<p>Использование this для возвратных ссылок в C#</p>

Обратите внимание на то, что другой конструктор класса Employee использует ключевое слово C# this.

// Явное использование "this" для разрешения конфликтов имен.

publiс Employee(string fullName, int empID, float currPay) {

 // Присваивание входных параметров данным состояния.

 this.fullName = fullName;

 this.empID = empID;

 this.currPay = currPay;

}

Это ключевое слово C# используется тогда, когда требуется явно сослаться на поля и члены текущего объекта. Причиной использования ключевого слова this в этом пользовательском конструкторе является стремление избежать конфликта имен параметров и внутренних переменных состояния. Альтернативой могло бы быть изменение имен всех параметров.

// В отсутствие конфликта имен "this" подразумевается.

public Employee(string name, int id, float pay) {

 fullName = name;

 empID = id;

 currPay = pay;

}

В данном случае нет необходимости явно добавлять префикс this к именам членов-переменных Employee, потому что конфликт имен уже исключен. Компилятор может самостоятельно выяснить области видимости используемых членов-переменных, и в этой ситуации this называют неявным: если класс ссылается на свои собственные поля данных и члены-переменные (без каких бы то ни было неоднозначностей), то this подразумевается. Таким образом, предыдущая логика конструктора функционально идентична следующей.

public Employee(string name, int Id, float pay) {

 this.fullName = name;

 this.empID = id;

 this.currPay = pay;

}

Замечание. Статические члены типа не могут использовать ключевое слово this в контексте метода. В этом есть смысл, поскольку статические члены-функции действуют на уровне класса (а не объекта). На уровне класса нет this!

<p>Передача вызовов конструктора с помощью this</p>

Другим вариантом использования ключевого слова 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 нового работника. Собрав множество начальных параметров, вы передаете запрос создания объекта конструктору с тремя аргументами.

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

Перейти на страницу:

Похожие книги

97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

Успешная карьера архитектора программного обеспечения требует хорошего владения как технической, так и деловой сторонами вопросов, связанных с проектированием архитектуры. В этой необычной книге ведущие архитекторы ПО со всего света обсуждают важные принципы разработки, выходящие далеко за пределы чисто технических вопросов.?Архитектор ПО выполняет роль посредника между командой разработчиков и бизнес-руководством компании, поэтому чтобы добиться успеха в этой профессии, необходимо не только овладеть различными технологиями, но и обеспечить работу над проектом в соответствии с бизнес-целями. В книге более 50 архитекторов рассказывают о том, что считают самым важным в своей работе, дают советы, как организовать общение с другими участниками проекта, как снизить сложность архитектуры, как оказывать поддержку разработчикам. Они щедро делятся множеством полезных идей и приемов, которые вынесли из своего многолетнего опыта. Авторы надеются, что книга станет источником вдохновения и руководством к действию для многих профессиональных программистов.

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT