В преддверии выпуска Windows 10 и новой, пятой, версии Powershell, хочу поговорить с вами о одном из наиболее серьезных нововведений этого языка — о классах. Начать наш разговор мне видится уместным с экземпляров класса — объектов — являющихся безусловно киллер-фичей языка сценариев Powershell. Простота и лаконичность упрощенного объектно-ориентированного подхода в языке автоматизации задач покорила не только большую, казалось бы, черствую, подобно 16-bit legacy, корпорацию, но и пользователей альтернативных операционных систем.
«Упрощенным» объектно-ориентированным я его назвал умышленно и хочу обратить на это ваше внимание. Объектно-ориентированные языки программирования предполагают ряд сущностей, таких как класс(тип), экземпляр класса, свойства и методы этого экземпляра, чаще называемого объектом. Powershell же, ловко оперируя объектами и их свойствами, практически полностью лишен методов и абсолютно полностью определяемых пользователем типов объектов (классов). Из часто используемых методов в голову приходят пожалуй лишь .trim() да .ToString(). Если дать еще минутку на парсинг дампа опыта написания скриптов на Powershell, всплывет еще что-то про Get-WMIObject.
Предлагаю освежить в памяти создание объекта в Powershell, хотя и для первого знакомства будет отлично.
Путь первый — Православный
Характерной особенностью Powershell, можно сказать его почерком, который легко узнается даже с десяти шагов, является его многословность. На первых порах это немного даже раздражает и вокруг монитора прилипают стикеры с сокращениями с символами: «gci, gc, gwmi, %, ?» и сокровенным — «ls alias:» (просмотр всех алиасов). Чуть позже немного отпускает и вместо пубертантного "?" начинают появляться хоть и не «Where-Object», но уже довольно уверенный «Where». Позже, когда количество строк кода переваливает за десятки тысяч, а написанных скриптов за сотни, приходит понимание, что многословность языка сказывается положительно как на скорости чтения самого скрипта, так и на качестве его поддержки коллегами. В этот момент в любимом редакторе Ruler смещается с 80 символов до 200, а по старым скриптам пускается скрипт автозамены. Хм, кажется я отвлекся.
Итак, вернемся. Первый способ создания объекта, как и весь Powershell, многословен, но это его плюс. Все слова простые, английские и для человека первый раз в глаза видящего этот язык, в общем-то, понятный в контексте языка:
$Name = 'Name'
$CustomObject = New-Object –TypeName PSObject
$CustomObject | Add-Member –MemberType NoteProperty –Name Name –Value $Name
$CustomObject | Add-Member –MemberType NoteProperty –Name Date –Value $(Get-Date)
$CustomObject | Add-Member –MemberType NoteProperty –Name Value –Value 'Value'
По-большому счету, только этот способ позволяет добавлять к объекту не только свойства, но и методы посредством "-MemberType ScriptMethod". К моему удивлению я ниразу не видел, что бы кто-то реализовывал какие-то методы в своих объектах. Признаюсь я и сам не сторонник методов в Powershell, хотя могу и списать на то, что мой опыт объектно-ориентированного программирования не успел поразить мой достаточно глубоко. Отчасти я готов списать это на то, что методы пришлось бы расписывать в каждой функции, возвращающей кастомный объект, что безусловно менее удобно, нежели описать метод однажды в классе объекта.
Путь второй — Упрощенный
В этот раз для создания объекта используется хэш-таблица, которая передается все тому же коммандлету New-Object, при уменьшившемся количестве набранных символов, мы практически не потеряли в читаемости:
$Name = 'Name'
$Properties = @{}
$Properties.Name = $Name
$Properties.Date = $(Get-Date)
$Properties.Value = 'Value'
$CustomObject = New-Object –TypeName PSObject –Prop $Properties
Вообще, мне кажется хэш-таблицы немного недооценены авторами сценариев Powershell, даже ограничив в релизе язык только лишь хэш-таблицами и лишив — более толстых — объектов, язык бы ничуть не потерял своей мощи и стройности; хотя соглашусь с тем, что объекты выглядят перспективнее, о чем и поговорим в конце заметки.
По-большому счету разница между хэш-таблицой и объектом как раз и заключается в наличии методов, полезность которых, на мой взгляд, в скриптовом языке сомнительна. Попоробуйте выполнить пример из блока цитирования кода, расположенного выше, но опустив последнюю строку, в которой создается объект. После того, как мы в поле Name присвоили значение, мы уже можем к нему обращаться как $Properties.Name, при этом нигде выше мы не объявляли, что такое поле у нас вообще будет! Хэш-таблица уже ведет себя как объект, зачем нам создавать еще один такой же? Мало того, с хэш-таблицами можно работать и как с массивами обращаясь по индексу: $Properties['Name'].
В качестве примера работы с хэш-таблицами хочу привести код функции чтения значений ini-файла, по-моему она прекрасна:
function Get-IniContent {
Param (
[String]$Filepath
)
$IniContent = @{}
switch -Regex -File $Filepath {
'^[(.+)]' {
$Section = $matches[1]
$IniContent[$Section] = @{}
$CommentCount = 0
}
"^(;.*)$" {
$Value = $matches[1]
$CommentCount = $CommentCount + 1
$Name = 'Comment' + $CommentCount
$IniContent[$Section][$Name] = $Value
}
'(.+?)s*=(.*)' {
$Name, $Value = $matches[1..2]
$IniContent[$Section][$Name] = $Value
}
}
Write-Output $IniContent
}
# Ed Wilson, Microsoft Scripting Guy
Третий путь — Короткий
Он простой и короткий, тут добавить нечего, не беру смелость советовать вам использовать его только в однострочниках и чем-то, что не будет выполняться больше пары раз, но советую. Советую не только потому, что я адепт механических клавиатур и получаю удовольствие от набора текста, а сколько потому, что читаемость и понятность вашего скрипта должна быть на первом месте. Задачи которые приходится автоматизировать зачастую и без того полны блэк-боксов, я думаю вы согласитесь — незачем добавлять к ним еще один на Powershell (ну и потому что с обфускацией скриптов отлично справляются регулярные выражения и незачем увеличивать энтропию =).
$Name = 'Name'
$CustomObject = [pscustomobject]@{
Name = $Name;
Date = $(Get-Date);
Value = 'Value';
}
Четвертый путь — Вычислимый
Этот способ используется, в первую очередь, для модификации существующих объектов, получаемых, например, из конвейера. Речь о коммандлете Select-Object, с помощью него мы можем как уменьшать количество свойств объекта (например вычистить из результата работы коммандлета Receive-Job ненужные нам свойства в вроде RunspaceID), так и добавлять свои, в том числе вычисляя часть из них в процессе:
# вычислимый
$Name = 'Name'
$CustomObject = $Name | Select-Object @{Name='Name'; Expression = {$PSItem}}, @{Name='Date'; Expression = {Get-Date}}, @{Name='Value'; Expression={'Value'}}
# оставит только два свойства
$CustomObject | Select-Object Name, Date
Путь пятый — Враждебный (шучу)
Так как Powershell работает поверх CLR, на одном уровне с C#, например, то и использовать в нем средства предоставляемые этим языком нет никакой сложности:
Add-Type @'
public class CustomClass
{
public string Name = "Name";
public System.DateTime Date = System.DateTime.Now;
public string Value = "Value";
}
'@
$CustomObject = New-Object CustomClass
Этот способ позволяет в дополнению к свойствам объекта, так же описать и методы, что вобщем-то очевидно.
Пример применения, скрывающий окно хоста консоли, показан ниже. Удобен если в скрипте есть формочка и «окно с досом» пугает пользователя:
$ShowWindow = '[DllImport("user32.dll")] public static extern bool ShowWindow(int handle, int state);'
Add-Type -name win -member $ShowWindow -namespace native
[native.win]::ShowWindow(([System.Diagnostics.Process]::GetCurrentProcess() | Get-Process).MainWindowHandle, 0)
Powershell 5 и классы
Вот мы и подошли к самому главному, тому о чем в первую очередь я хотел бы поговорить, несмотря на то, что вот уже 99 строк (Word Wrap Column 120) углубляюсь в пространные разговоры о перипетиях синтаксиса: в Powershell 5 стали доступны классы (это не обман =). Все написанное ниже относится в первую очередь к превью языка, доступного как в комплекте с Windows 10, так и в несколько урезанном виде для других операционных систем.
Сначала я решил описать рыбу класса и его применения полную шаблонных слов вроде Example, FirstProperty и подобных, и лишь за тем описать что-то рабочее и близкое к телу. Посмотрев на это понял, что упрощая усложнил, ибо порой нет ничего хуже скучных шаблонных описаний, поэтому ниже я покажу как создать класс логера для вашего сценария:
# описание класса
class Logger {
# свойство
[String]$LogPath
# конструктор
Logger([String]$NewLogPath) {
$This.LogPath = $NewLogPath
New-Item -Type File $This.LogPath -Force
}
# метод
[void]Add([String]$Value) {
'[{0}] {1}' -f $(Get-Date), $Value |
Out-File $This.LogPath -Append -Encoding default
}
}
$MyLogger = [Logger]::New('C:temptest.log')
$MyLogger.Add('Initial log entry')
Получившийся результат:
PS C:Usersrbobot> Get-Content C:temptest.log
[4/4/2015 4:23:22 PM] Initial log entry
Итак, немного слов по синтаксису нашего минимального пригодного к работе класса:
— конструктор класса именуется так же как и сам класс, при этом конструктор можно не описывать, в этом случае вызовется конструктор по-умолчанию, но и определить свойства при создании мы не сможем;
— при обращении к свойствам класса внутри конструктора и методов используется ключевое слово $This;
— описание методов начинается с указания типа возвращаемого значения, в том случае если метод не возвращает ничего следует указать ключевое слово [void];
— при создании экземпляра класса используется синтаксис вида: [Имя класса]::New();
Из отмеченного выше, лично у меня глаз цепляется лишь за синтаксис создания экземпляра класса остальное выглядит логичным. С одной стороны для создания экземпляра класса ожидаешь увидеть уже знакомый New-Object –TypeName, с помощью которого мы создавали объекты как описанные на Powershell, так и заимствованные из C#.
С другой, этот коммандлет не предполагает определения свойств и объект создается конструктором по-умолчанию, возможно к релизу синтаксис создания экземпляра пользовательского класса изменится на более Powershell-Way, путем расширения параметров коммандлета New-Object.
Расширим немного наш класс, перегрузив метод Add и добавив функцию, которая будет получать наш объект параметром и логировать свои действия:
class Logger {
[String]$LogPath
[String]$CodePage
Logger([String]$NewLogPath, [String]$NewCodePage) {
$This.LogPath = $NewLogPath
$This.CodePage = $NewCodePage
New-Item -Type File $This.LogPath -Force
}
[void]Add([String]$Value) {
'[{0}] {1}' -f $(Get-Date), $Value |
Out-File $This.LogPath -Append -Encoding $This.CodePage
}
[void]Add([String]$Type, [String]$Value) {
'[{0}] {1} {2}' -f $(Get-Date), $Type, $Value |
Out-File $This.LogPath -Append -Encoding $This.CodePage
}
[UInt64]GetSize() {
return (Get-Item $This.LogPath).Length
}
}
function New-SomeJob {
Param (
[Parameter(Mandatory=$true, ValueFromPipeline=$true)]
[String]$Job,
[Logger]$Logger
)
Process {
$JobResult = '{0} {1}' -f $Job, 'job'
$Logger.Add($JobResult)
}
}
$MyLogger = [Logger]::New('C:temptest.log', 'UTF8')
$MyLogger.Add('Initial log entry')
$MyLogger.Add('Warning:', 'Warning log entry')
'First', 'Second' | New-SomeJob -Logger $MyLogger
$MyLogger.Add('Last log entry')
$MyLogger.GetSize()
Получившийся результат:
PS C:Usersrbobot> $MyLogger.GetSize()
204PS C:Usersrbobot> Get-Content C:temptest.log
[4/6/2015 10:43:26 AM] Initial log entry
[4/6/2015 10:43:26 AM] Warning: Warning log entry
[4/6/2015 10:43:26 AM] First job
[4/6/2015 10:43:26 AM] Second job
[4/6/2015 10:43:26 AM] Last log entry
По-поводу вышепроцитированного можно отметить лишь то, что в методах, возвращающих значения, используется ключевое слово «return», использование которого в Powershell не рекомендуется в силу того, что оно как и Write-Output является синтаксическим сахаром, но при этом не соответствует стилистике Powershell. Покрайней мере так было раньше.
В заключение хотел бы спросить у вас, считаете ли вы классы в Powershell необходимой фичей или все же не стоит делать из Powershell еще один объектно-ориентированный язык программирования добавляя сущности без надобности?
Автор: rbobot
