Программирование на C# (Си Шарп) - ООП в .NET - Абстрактные функции и классы

ООП С Sharp - Абстрактные функции и классы

До сих пор всякий раз, когда мы определяли класс, то тут же создавали и экземпляры этого класса, но так бывает не всегда. Во многих ситуациях вам придется создавать очень обобщенные классы, от которых вы будете наследовать другие, более специализированные классы, никогда не создавая их экземпляров. В C# для этой цели предназначено ключевое слово abstract. Если класс объявлен как abstract, то создать его экземпляр невозможно.

Например, предположим, у вас есть абстрактный класс MyBaseClass, объявленный следующим образом:

 
abstract class MyBaseClass
{
... 

В этом случае следующий код компилироваться не будет:

 
MyBaseClass MyBaseRef = new MyBaseClass(); 

Однако вполне законно иметь ссылки типа MyBaseClass, если они указывают на экземпляры классов-наследников. Например, вы можете унаследовать новый класс от MyBaseClass:

class MyDerivedClass : MyBaseClass
{
... 

В этом случае следующий код совершенно корректен:

 
MyBaseClass myBaseRef;
myBaseRef = new MyDerivedClass(); 

Можно также определить метод как abstract. Это означает, что метод трактуется как virtual, и вы не реализуете его в данном классе, предполагая, что он должен быть переопределен в классах-наследниках. Если метод объявлен как abstract, его тело определять не нужно:

 
abstract class MyBaseClass
{
public abstract int MyAbstractMethod(); // никакого тела!
... 

Если любой метод класса объявлен как abstract, это значит, что и сам класс должен быть abstract, и компилятор выдаст ошибку, если класс не будет так объявлен. К тому же, любой неабстрактный ласс, унаследованный от данного, должен переопределять этот абстрактный метод. Эти правила предотвращают создание экземпляра абстрактного класса, который не имеет реализации всех своих методов.

На этом этапе, возможно, вам будет неясно, зачем вообще нужны абстрактные методы и классы. Они исключительно полезны по двум причинам. Одна из них состоит в том, что зачастую они помогают лучше построить дизайн иерархии классов, когда иерархия лучше соответствует модели, которую требуется смоделировать. Другая же причина связана с тем, что применение абстрактных классов может переместить некоторые потенциально трудно обнаруживаемые ошибки времени выполнения в легко обнаруживаемые ошибки времени компиляции. Трудно понять, как это работает на практике, если не обратиться к примеру, поэтому в следующем разделе архитектура программы MortimerPhones будет усовершенствована - будет изменена иерархия классов.