Каковы преимущества использования частичного класса в отличие от абстрактного?
Я читал Программирование Microsoft ® Visual C# ® 2008: язык, чтобы лучше понять C# и что с ним можно сделать. Я столкнулся с частичными классами, которые я уже встречал от ASP.Net-класс странички.
Мне кажется, что вы можете делать то, что частичные классы делают с абстрактным классом и переопределенным классом. Очевидно, что одна команда будет контролировать интерфейс с помощью абстрактных методов, но вы все равно будете полагаться друг на друга. А если цель есть тогда сотрудничество-это не то, что решает система управления версиями и другие инструменты.
Я просто упускаю из виду частичный класс. Также мог бы кто-то обеспечить реальное использование мира.
8 ответов:
Частичные классы не имеют ничего общего с наследованием объектов. Разделяемые классы-это просто способ разбиения исходного кода, определяющего класс, на отдельные файлы (это делается, например, при создании новой формы в приложении Windows Forms - один файл является "вашим" кодом, другой-другим файлом).дизайнер.cs содержит код, которым управляет VS2008 для вас).
Самое замечательное в частичном классе то, что вы можете взять существующий класс и добавить к нему. Теперь это звучит очень похоже на наследование,но есть много вещей, которые наследование не может сделать, что частичные классы будут.
Вот одна мысль о классах Linq to SQL, созданных для вас. Они генерируются автоматически, что означает, что вы не должны изменять их. Без разделяемого класса вы не можете присоединить интерфейс. Можно создать новый класс и вывести его из класса Linq to sql, но это действительно ничего вам не даст, потому что вы не можете передать класс linq to sql в свой класс с интерфейсом.
Частичные классы должны быть ограничены использованием С автоматически генерируемым кодом, где другой код не может быть изменен. Использование его в качестве замены наследования или добавления функциональности не является лучшим решением.
Если у вас большой класс, это уже неправильно. Код должен быть преобразован в несколько "реальных" классов вместо нескольких файлов. Большие классы вообще означают, что класс делает слишком много вещей и нарушает SRP (принцип единой ответственности).
Парциальные классы теперь широко используются в ASP.Net разрешить два исходных файла пример на основе разметки.aspx и пример на основе кода.аспн.cs так, чтобы методы и переменные, определенные в каждом, были видны каждому. в примере.aspx
<custom:exampleControl id="exampleCntr" property="<%#getProperty()%>" />
В Примере.аспн.cs
private object GetProperty(){ // called from aspx return DateTime.Now; } private void DoStuff(){ ExampleControl c = exampleCntr; //exampleCntr is defined in aspx. }
Двунаправленная природа этого не может быть воссоздана с помощью абстрактных классов.
Похоже, что ваш вопрос заключается в том, в чем разница между
partial class Foo { PART ONE } partial class Foo { PART TWO }
И
Хотя они могут показаться несколько похожими, и в некоторых случаях последняя конструкция может быть использована вместо первой, есть по крайней мере две проблемы с последним стилем:astract class FooBase { PART ONE } partial class Foo : FooBase { PART TWO }
-1 - Тип
FooBase
, вероятно, должен был бы знать тождество конкретного типа, который должен был бы выводиться из него, и всегда использовать переменные этого типа, а не типаFooBase
. Тот представляет собой неудобно тесную связь между этими двумя типами.- 2-Если тип
Foo
является открытым, то типFooBase
также должен быть открытым. Даже если все конструкторыFooBase
являютсяinternal
, для внешнего кода было бы возможно определить классы, производные отFooBase
, но неFoo
; построение экземпляров таких классов было бы трудным, но не невозможным.Если бы производный тип мог расширить видимость базового типа, эти проблемы не были бы чрезмерными. проблематично; можно было бы рассматривать
FooBase
как "выброшенный" идентификатор, который появлялся бы ровно дважды: один раз в его объявлении и один раз в строке объявления дляFoo
, и считать, что каждыйFooBase
был быFoo
замаскированным. Тот факт, чтоFooBase
не может использовать члены экземпляраFoo
наthis
без преобразования типа, может быть утомительным, но также может способствовать хорошему разбиению кода. Поскольку расширить видимость базового типа невозможно, дизайн абстрактного класса выглядит следующим образом: мерзкий.