При каких условиях хорошо иметь “частичный класс?”
Идеи объединяющегося Линделефа и Gregg Lind:
last <- function(x) { tail(x, n = 1) }
Работа при подсказке, я обычно опускаю" n=", т.е. tail(x, 1).
, В отличие от этого last от pastecs пакет, head и tail (от utils) работа не только на векторах, но также и на кадрах данных и т.д., и также может возвратить данные "без первых/последних n элементов", например,
but.last <- function(x) { head(x, n = -1) }
(Обратите внимание, что необходимо использовать head для этого, вместо [1 110].)
4 ответа
Когда вам нужно автоматически сгенерировать часть этих классов и вручную записать остальное содержимое классов.
Это делается для того, чтобы вы могли поместить созданный машиной контент в один файл и код, закодированный вручную, в другом файле. Преимущество этого заключается в том, что, когда вам нужно регенерировать исходный код, ваша закодированная вручную часть не будет уничтожена.
Вот как MS генерирует контент класса для своих дизайнеров графического интерфейса (вспомните те * .designer.cs файл), и позволяет вам поместить мясо вашей логики в другой связанный файл ( *. cs )
Как говорили другие, автоматически сгенерированный код - хорошая причина. Я также иногда использую частичный класс, когда хочу поместить вложенный класс в отдельный файл.
public partial class MyClass
{
private class NestedClass
{
...
}
}
Кроме того, есть небольшая хитрость, позволяющая вложить файл в проводник решений (чтобы сделать как winform и вложить файл Form1.designer.cs ).
<Compile Include="Foo.1.cs">
<DependentUpon>Foo.cs</DependentUpon>
</Compile>
Если у вас есть автоматически сгенерированный код, который вы хотите расширить, частичный класс - отличный способ сделать это.
Например, расширение LINQ на генерируемые классы SQL.
Допустим, у вас есть обработчики событий и другой код графического интерфейса пользователя в одном месте, и вы хотите сохранить другой код, не связанный с графическим интерфейсом пользователя, в одном месте. Паттерн MVC, который непрост в C #.