Yeni Şeyler (2) - Dependency Injection, SOLID, Abstract Class, GitHub ve SSL
Merhaba,
Başlıktan da anlayacağınız üzere ‘günlük hayatta olsun’, ‘iş hayatında olsun ’ okuduğum ve üzerine araştırmalar yaptığım konulardan kendime notlar çıkarmaya karar verdim ve bu notları da sizler ile paylaşmak gerçekten çok güzel olacağını düşündüğümden bu yazıyı yazdım. Eğer siz şu an bu sayfada bulunuyorsanız muhakkak başlıkta yazılan konulardan biri ile bir araştırma yapmışsınızdır. Umarım benim burada yazmış olduğum konulardan herhangi biri işinize yarar ve sizin için faydalı olur. Lafı fazla uzatmadan başlayalım mı?
Cevabınız “EVET” ise, bu yazıda Dependency Injection , SOLID Prensipleri , Abstract Class , GitHub ve SSL hakkında bilgiler bulacaksınız.
Bu arada yazımı beğenmeyi ve paylaşmayı, bi de beni takip etmeyi unutmayın :)
🔰 Dependency Injection
- : bir sınıfın constructer metodundan talep edilen parametreye gönderilecek nesneleri alt yapısal olarak Dependency Injection özelliği sayesinde önceden belirleyebiliyoruz ve yapısal olarak ilgili sınıftan üretilecek instancelarda parametredeki referans tipine olan bağımlılığı ortadan kaldırabiliyoruz.
DETAY : var olan hali hazırda çalışan sistemin hiç bir yerine dokunmadan ekleyebildiğim özelliği “dependeny injection” sayesinde ekleyebiliyoruz.
Dependency Injection mantığını teknik boyutta yönetmemizi sağlayan 3 farklı yordam :
- AddTransient : her talepte yeni ve geçici bir nesne üretir.
Transient nesneler, her zaman farklıdır. Her nesne çağrımında, yani her bir controller veya her bir service için yeni oluşturulurlar. En hızlısı ve thread safety açısından en güvenlisidir(no locks, pooled db connection gibi..). Örneğin LogServiceler bu şekilde kullanılabilirler. Kötü yani, çok fazla deep dive object oluştururlar. Daha çok monolitik büyük dependency ağacı olan yapılarda tercih edilmelidirler.
- AddScoped : bir talebe&requeste özel nesne üretir. Sadece o requeste özel nesne oluşturur.
Üretilme şekli, bir request içinde hep aynıdır. Farklı web requestler’de farklı instancelar oluşturulur. Aynı using kullanımında olduğu gibi. Şahsen ben Repository sınıflarını bu şekilde ayağa kaldırmayı tercih ediyorum. Kısaca her istekte yaratılıp, dispose edilirler.
- AddSingleton : her talep için ilk üretilen nesneyi döndürür. Uygulamanın her noktasından üretilmiş mevcut nesneye erişilir.Tüm application zamanı boyunca bir kere yaratılıp, her requestte aynı Instance’ın kullanılmasına olanak sağlanır. Mesela herkes için ortak kullanılan nesneler, Singleton yapılar, buna çok uygundur. Örneğin Cache manager gibi
🔰 SOLID
- Single Responsibility Principle : Tek sorumluluk prensibi,bir nesnenin değişmesi için tek bir nedenin bulunmasını gerektiğini savunur. Bu prensip ile daha kaliteli ve daha yararlı kodlar yazabiliriz. İlk olarak karmaşık sınıflar yazmaya bırakmalıyız. Bu prensibin biz yazılımcılara sundukları ise;
Okunaklı kod, Anlaşılabilir kod, Hata eğilimi az olan kod, Sağlam ve kolay test edilebilir kod, Sürdürülebilir kod
- Open/Closed Principle : Elinizde bir yazılım ürünü var ve bu ürünü satın alan müşterilerinize destek veriyorsunuz. Müşteri size geldi ve sizden bazı isteklerde bulundu. Örnek verecek olursak ,sizden gelen xml verilerini parse edip bunu belli kurallara göre filtreleyen bir özellik olmasını istedi. Sizin de zaten hali hazırda bu işi yapan bazı fonksiyonlarınız var fakat bu isteği tam olarak karşılayamıyor. Eğer yazdığınız kodu değiştirmeye kalkarsanız bu prensibi çiğnemiş olursunuz çünkü prensibin en önemli kuralı kodunuzun değiştirilemez fakat genişletilebilir olmasıdır. Yani mevcut kaynak kodunuzda A fonksiyonu B işini yapıyorsa müşterinin bin tane de isteği olsa bu işi yapmaya devam etmeli. Siz bu işin gerçekleştirilmesini istiyorsanız ürününüze bir kaç fonksiyon daha ekleyerek bu işi halledebilirsiniz. Aksi takdirde kodunuzun yapısı bozulacak hangi fonksiyonun ne yaptığı,ne zaman değiştiği,neden değiştiği gibi belirsiz senaryolar oluşacaktır. Bir süre sonra ürününüz amacından uzaklaşmaya başlayacaktır. Yapmamız gereken şey bir interface yaratıp ihtiyaca göre her sınıfın o fonksiyonu şekillendirmesi. Böylece kodunuz genişletilebilir olacak ve her sınıfın fonksiyonu kendi işini yapacaktır.
- Liskov Substitution Principle : Liskov prensibi ise aynı sınıftan türemiş sınıfların birbirleri yerine kullanılıyor olabilmesi gerektiğini savunmuştur.Yani bir sınıftan miras alırken 2–3 defa düşünmemiz gerektiğini söylüyor. Extends ve implements olaylarını sadece gerektiği yerde yapmalıyız. Burada yapacağımız her doğru hamle kodumuzun kalitesini önemli ölçüde arttıracaktır.
- Interface Segregation Principle : Bu prensip ise bize yazdığımız interface’lerde bulunan fonksiyonların birbirlerine konu bakımından bağlı olmasını söyler.
- Dependency Inversion Principle : Bu prensibi diğer prensiplerin babası gibi düşünebiliriz. Prensip somut sınıflara olan bağımlılıkların soyut sınıflar ile çözülmesini savunur. Bir projeye bakıyoruz yüzlerce somut sınıf, ister istemez bağımlılık fazla değişime kapalı, karışık, test etmesi zor bu şekilde devam ediyor. Oysa şu soyut sınıfları doğru bir şekilde kullansak kodumuz ne kadar da temiz ve anlaşılır olacak.
Interface kullanarak daha düzenli kodlar yazabiliriz. Fakat bu interface’leri yazarken interface’teki fonksiyonların konu bakımından çok yakın olmasına ve bu interface’i implement edecek olan sınıfın bu interface’in her fonksiyonunu tam olarak kullanmasına dikkat edin. Yani bir interface ’i implement ettiniz ve o interface ’ten 10 metod override edildi fakat bu metodların 5 'i boş kaldı. Yanlış yoldasınız. Bir yerde bir kod veya tasarım hatanız var. Bu kodun refactor zaman gelmiş.
🔰 Abstract(Soyut) Class
Ortak özellikleri olan nesneleri modellemek için abstract(soyut) sınıflar kullanır. Soyut sınıflar oluşturulurken class ismi yerine “abstract class” kelimeleri kullanılır.
Soyut sınıflar kalıtım özelliğini kullanarak kod tekrarını azaltır. Her ne kadar soyutlama işlemi yapılmış olsa da interface kullanımına göre iyi sonuçlar alınmayabilir.
Soyut sınıflar kendisinden türeyen sınıflardır. Bu sınıflardan nesne oluşturamayız. Soyut sınıfı türeten sınıf soyut sınıfın tüm soyut metotlarını override etmek zorundadır.
Türeterek farklı sınıflarda kullanabiliriz. Her türettiğimiz sınıfta, soyut sınıfların özellikleri kullanılarak farklı sonuçlar üretilir. Arayüzdeki somut nesneler (new operatörü ile oluşturduğumuz nesneler) oluşturulamaz. Soyut sınıflar , başka nesnelerden bağımsız bir şekilde çalışır.
- Soyut sınıflarda neler olmaz?
: Soyut sınıfların içerisindeki soyut metotların gövdesi boş olması gerekir (kullanılacak yere göre işlem farklılığı olacağından). Ama soyut olmayan metotların gövdeleri olmak zorundadır.
: Soyut sınıflar private olarak tanımlanamazlar. Çünkü kalıtım özelliğini her daim göstermek zorundadır (zaten soyut sınıfların sihri bu).
: Soyut sınıflar “abstract” türünden nesneler tanımlamazlar. “Static” metotlar soyut olarak tanımlanamazlar.
- Soyut sınıflar neden kullanılır?
: Bazı durumlarda oluşturacağımız tasarımda benzer özellikler taşıyan sınıflara rastlayabiliriz. Bu sınıflarda tekrar tekrar aynı kodları yazmaktansa soyut sınıfları kullanmak daha kolaylık sağlıyor (kodun yeniden kullanılabilirliği).
- Soyut sınıflar nasıl kullanılır?
: Öncelikle abstract class ’ı tanımlayalım.
public abstract class Ders
{
private string ad;
public int sinifNo = 1;
/* Tamamlanmamış method. : Abstract içi dolu olmayan virtual
method'dur. */
public abstract string getAd();
/* Tamamlanmış method. */
public int getSinifNo()
{
return this.sinifNo;
}
} Örneğimizde getAd() isminde soyut metot ve getsinifNo() isminde normal bir metot bulunmaktadır. getAd() metodu soyut olduğundan dolayı bu abstractı türeten alt sınıflar bu metodu implemente etmek zorundadır. Kullanmadığımız zamanlarda ise‘Matematik’ does not implement inherited abstract member ‘Ders.getAd()’ hata mesajı alacağız. Örneğimize devam edelim.
public class Matematik : Ders
{
public override string getAd()
{
return "Matematik";
}
}
public class Fizik : Ders
{
public override string getAd()
{
return "Fizik";
}
}getsinifNo() metodu üst sınıfta(abstract) tanımlanmaktadır. Bu metot değiştirilerek (re-implemente) ya da olduğu gibi kullanılabilir.
class Program
{
static void Main(string[] args)
{
Matematik matematik = new Matematik();
Console.WriteLine("SınıfNo : " + matematik.getSinifNo());
Console.WriteLine("Ad : " + matematik.getAd()); Fizik fizik = new Fizik();
fizik.sinifNo = 2;
Console.WriteLine("SınıfNo : " + fizik.getSinifNo());
Console.WriteLine("Ad : " + fizik.getAd()); Console.ReadLine();
}
}
Özet olarak getAd() soyut olarak tanımlandığı için alt sınıfların hepsinde getAd() isminde implementasyonu yapılmış sınıf olarak kullanılmak zorundadır. getsinifNo() ise normal metot olarak belirtildiğinden dolayı diğer sınıflarda kendilerine özgü kullanılabilir ya da abstract sınıfta belirtildiği şekilde kullanılabilirler.
Aşağıda kodun çalıştığındaki ekran görüntüsünü bulabilirsiniz.
🔰 GitHub
Git, yazılım geliştirme süreçlerinde kullanılan, hız odaklı, dağıtık çalışan bir sürüm kontrol ve kaynak kod yönetim sistemidir. Öncelikle Git Bash yüklenmeli
install : https://git-scm.com/downloads
$ git config --global user.name ""
$ git config --global user.email ""
GIT ’in temelinde 3 durum vardır. Bu durumlar working directory, staging area ve git repository. Working directory ve git repository, çalıştığımız yer ve git deposunu belirtiyor. Staging area ise aralarında bir köprü görevi görüyor. Yani çalıştığımız proje üzerinde yaptığımız değişikliği git reposuna yollamak için önce staging area’ya yollarız. Daha sonra fikrimiz değişir ise bu işten vazgeçme şansımız olur.
$ git init
$ git status
$ git add .
$ git commit -m ""
$ git logŞu anda tek branch’imiz var o da master branch ’i. Bir branch daha oluşturup git checkout komutu ile branch ’e girelim. Bu branch ’leri ekipteki diğer arkadaşlar için oluşturuyoruz.
$ git branch
$ git branch database
$ git checkout databaseŞimdi de master branch ’imize geçelim. Daha sonra git diff komutunu kullanarak master branch ’i ile database branch ’i arasındaki farkı görüp database branch ’ini master branch’i ile birleştirelim.
$ git checkout master
$ git diff master database
$ git merge databasecommit (işlemek)
merge (birleştirmek)
🔰 SSL (Secure Socket Layer)
Türkçe olarak güvenli giriş katmanı olarak çevirebileceğimiz protokol, Netscape tarafından geliştirilmiştir. Kısaca özetlemek gerekirse giriş yaptığınız sitede sizin ile site arasındaki veri alışverişinin şifreli olarak yapılmasını sağlayan bir algoritmadır. Veriler şifrelenmiş olarak gönderilip alınır. Bu şifrelemelerin çözümü için bizim sertifika alırken kaşımıza çıkacak olan Priavate Key gereklidir.
SSL sertifikası, genellikle e-ticaret sitelerinin kullandığı ve kullanıcı ile site arasında bilgi akışı olan siteler ücretli SSL sertifikası kullanmaktadır. Ancak blog sahiplari SSL SEO için ücretsiz (sslforfree.com) SSL sertifikası bulunmaktadır.
20 ile 30 yaş arası kafanı, 30 ile 40 yaş arası cebini, 40 ile 50 yaş arası ruhunu doldur.
Bu içeriğin yararlı olduğunu düşünüyorsanız 👏 butonuna tıklayarak destek olabilir, soru ve fikirlerinizi yorum’dan paylaşabilirsiniz…
Bir sonraki makalede görüşmek ümidi ile sağlıcakla kalın.
