Hesaplanmış özellik yazarken tek soru sözdizimi değil, çıktının sütun sırası ve sonradan nesne olarak kullanılıp kullanılmayacağıdır. Kısaca: yalnız geçici bir alan ekleyeceksen hashtable yeterli olabilir; sıra sabit kalmalıysa ordered dictionary, nesne gibi taşınacak çıktı gerekiyorsa PSCustomObject daha uygundur.
En temiz seçim yolu, önce çıktının sadece gösterim mi yoksa yeniden kullanılacak veri mi olduğunu ayırmaktır. Sonra sütun sırası gerçekten önemli mi, bu çıktı bir cmdlet zincirinde mi kalacak, yoksa rapor gibi tekrar tüketilecek mi sorularını yanıtlayıp yapıyı buna göre seçmek gerekir.
En temiz seçim yolu, önce çıktının sadece gösterim mi yoksa yeniden kullanılacak veri mi olduğunu ayırmaktır. Sonra sütun sırası gerçekten önemli mi, bu çıktı bir cmdlet zincirinde mi kalacak, yoksa rapor gibi tekrar tüketilecek mi sorularını yanıtlayıp yapıyı buna göre seçmek gerekir.
Hesaplanmış özellikte hangi yapı ne zaman seçilir?
Kısa karar ölçütü
Bir hesaplanmış özellik, çoğu zaman Select-Object veya Format-Table içinde tek satırlık bir sözlükle tanımlanır. Burada önemli ayrım şudur: hashtable, sözdizimi açısından yeterlidir ama anahtar sırasını garanti etmez; ordered dictionary ise yazdığınız sırayı korur. PSCustomObject ise özellikle literal hashtable’den dönüştürüldüğünde, özellikleri düzenli bir nesne olarak taşımak için daha uygundur.- Geçici görünüm gerekiyorsa: hashtable.
- Sütunların sırası korunacaksa: ordered dictionary.
- Çıktı nesne olarak saklanacaksa: PSCustomObject.
Select-Object ve Format-Table tarafı
Bu iki cmdlet hesaplanmış özellik için aynı temel sözdizimini kullanır; yani ad, ifade ve gerekirse etiket gibi parçalar tek bir sözlükte verilir. Fakat burada yapılan şey, yeni bir kalıcı veri modeli kurmak değil, mevcut nesneye görüntü amaçlı alan eklemektir. Bu nedenle yalnızca “çalışıyor mu?” sorusuna değil, çıktı düzeni ileride önemli olacak mı sorusuna da bakılmalıdır.Hashtable ne zaman yeterli olur?
Eğer tek amaç, bir-iki alanı hızlıca hesaplayıp sonuç almaksa hashtable pratik ve okunabilir kalır. Anahtarların hangi sırada geldiği kritik değilse fazladan yapı kurmaya gerek yoktur. Ancak aynı yaklaşımı rapor, CSV benzeri sütun düzeni veya kullanıcıya birebir gösterilecek tablo üretiminde kullanırsanız, alanların görünme sırası beklediğiniz gibi olmayabilir.| Yapı | Ne zaman seçilir |
|---|---|
| Hashtable calculated property | Kısa ve tek seferlik alan ekleme için yeterli; sıra garantisi yoksa sorun olmaz. |
| Ordered dictionary | Sütunların tanımladığınız sırada görünmesi gerekiyorsa kullanın. |
| PSCustomObject | Daha sonra genişletilecek ya da nesne gibi taşınacak çıktı için uygundur. |
| Select-Object | Hesaplanmış özellik yazımının en yaygın yeri; adı ve değeri açıkça verin. |
| Format-Table | Görüntüleme amaçlı düzen ister; üretim nesnesi oluşturmaz. |
Sırayı korumak gerekiyorsa ne değişir?
Ordered dictionary neden tercih edilir?
Ordered dictionary, anahtarların tanımlandığı sırayı koruduğu için rapor benzeri çıktılarda daha güvenlidir. Özellikle birden fazla hesaplanmış alanı yan yana koyarken hangi sütunun önce geleceğini siz belirlersiniz. Bu, okunabilirliği artırır ve her çalıştırmada aynı görünümü elde etmenize yardım eder.PSCustomObject ne zaman daha doğru seçimdir?
Eğer amaç sadece ekran çıktısı değil, daha sonra başka komutlara aktarılacak bir nesne üretmekse PSCustomObject daha uygun olabilir. Literal bir hashtable’den dönüştürüldüğünde özellik sırasını koruyabildiği için düzenli bir nesne görünümü sağlar. Bu yaklaşım, sonradan ekleme yapacağınız veya başka yerde kullanacağınız verilerde özellikle işlevseldir.Seçimi hızlandıran pratik tablo
Duruma göre yapı eşleştirmesi
Bu tablo, aynı ihtiyaca farklı yapılarla yaklaşırken hangi farkın gerçekten karar verdirici olduğunu özetler.- Yalnızca hesaplanan alan eklemek: hashtable.
- Sütun sırası sabit kalmalı: ordered dictionary.
- Nesneyi sonradan kullanmak gerekiyor: PSCustomObject.
- Görsel düzenleme ama kalıcı veri değil: Format-Table.
- Filtreleme ve seçme ile birlikte alan üretmek: Select-Object.
