Caner Tosuner

Leave your code better than you found it

Dependency Inversion Principle

SOLID prensipleri yazı serisinde son prensip olan SOLID'in "D" si Dependency Inversion prensibine gelmiş bulunuyoruz. Türkçe anlamını her ne kadar beğenmiyor olsam da atalarımız "Bağlılığı Tersine Çevirme Prensibi" olarak çevirmişler.

Bu prensip bizlere OOP yaparken şu 2 kurala uymamız gerektiğini söylüyor;

  • Üst seviye (High-Level) sınıflar alt seviye (Low-Level) sınıflara bağlı olmamalıdır, aralarındaki ilişki abstraction veya interface kullanarak sağlanmalıdır,
  • Abstraction detaylara bağlı olmamalıdır, aksine detaylar abstraction'lara bağlı olmalıdır.

Birçok projede malesef üst seviye sınıflar alt seviye sınıflara bağlıdır ve bu sınıflarda bir değişiklik yapmak istediğimizde başımıza onlarca iş açabilmektedir çünkü alt sınıfta yapılan bu değişiklik üstü sınıfıda etkileyebilir ve üst sınıfların etkilenmesi de projenizdeki bütün yapının etkilenmesi neden olabilir. Bu durum aynı zamanda reusability yani tekrar kullanılabilirlik durumuna engeller. İşte bu karmaşayı ortadan kaldırmak için Dependency Inversion prensibi ortaya çıkmıştır ve üsttede belirttiğim gibi modulleri birbirinden soyutlamamız gerekir. SOLID Nedir makalesinde verdiğim örnekte olduğu gibi gözlüğünüz var ve camlarını değiştirmek istediniz gittiniz gözlükçüye adam dediki "Bu camların değişmesi için gözlüğünde değişmesi gerek..." saçma dimi :) işte bazen bu prensibe uymazsak gözlük örneğinde olduğu gibi enteresan sorunlar başımıza gelebilir. 

Örnek bir case üzerinden ilerleyelim. LogManager adında bir class'ımız olsun ve bu class'ın Log() isminde bir metodu ve bu metod çağrıldığında FileLogger() objesine ait olan Log() metodu çağrılsın ve FileLog işlemini yapsın.

	public class FileLogger  
	{
		public string Message { get; set; }
		public void Log()
		{
			//File Log
		}
	}

	public class DBLogger  
	{
		public string Message { get; set; }		
		public void Log()
		{
			//Database Log
		}
	}

	public class LogManager  
	{
		private FileLogger _file;
		private DBLogger _db;
		
		public LogManager()
		{
			_file = new FileLogger();
			_db = new DBLogger();
		}
	
		public void Log()
		{
			_file.Log();
			_db.Log();
		}
	}

Yukarıda görüldüğü gibi LogManager üst seviye class'ımız ve tam da Dependency Inversion prensibine ters olarak FileLogger ve DBLogger class'larına yani alt seviye class'lara bağlı. DIP bize bu gibi alt-üst seviye sınıf ilişkilerini abstraction veya interface'ler kullanarak kurmamızı söylüyor ancak durum şuan bunun tam tersi ve yarın bir gün yöneticiniz geldi dedi ki "bundan sonra uygulama Log'ları EventLog'a da yazdırılacak". Bunun için gidip aynen File-DB Logger class'larında olduğu gibi EventLogger adında bir class tanımlayıp LogManager() içerisinde aynı işlemleri yapmak heralde istediğimiz bir çözüm değildir ki bu LogManger class'ına extra bir nesneye daha bağlı hale getirir. Hedefimiz LogManager class'ını olabildiğince nesne bağımsız hale getirmek.

 

Bunun için ilk olarak ILogger adında bir interface tanımlayalım ve FileLogger & DBLogger class'larını bu interface'den implement edelim.

	public interface ILogger  
	{
		void Log();
	}

	public class FileLogger : ILogger
	{
		public string Message { get; set; }
		public void Log()
		{
			//File Log
		}
	}

	public class DBLogger : ILogger
	{
		public string Message { get; set; }
		
		public void Log()
		{
			//Database Log
		}
	}

Ve son olarak da LogManager class'ını sadece ILogger interface'ine bağlı hale getirmek kalıyor. Böylelikle ILogger'den implement olmuş bütün class'lar LogManager tarafından kullanılabilecektir.

	public class LogManager 
	{
		private ILogger _logger;
		public LogManager(ILogger logger)
		{
			_logger = logger;
		}
	
		public void Log()
		{
			_logger.Log();
		}
	}

Bu refactoring işlemlerini yaptıktan sonra artık LogManager class'ı Dependency Inversion prensibine uygun hale gelmiştir yani alt seviye sınıflara bağlı değildir aradaki ilişki interface kullanarak sağlanmıştır. 

LogManager class'ının kullanım şekli ise aşağıdaki gibidir.

	public static void Main()
	{
		var dbLogger = new DBLogger();
		dbLogger.Message = "Test 123";
		
		var manager = new LogManager(dbLogger);
		manager.Log();
	}

Özetle; yaptığımız refactoring işlemiyle birlikte DIP'nin söylediği gibi high-level ve low-level sınıfları abstraction'lara bağlı hale getirdik.

Bu yazımızla beraber SOLID prensiplerinin sonuna gelmiş bulunuyoruz. Umarım faydalı bir yazı serisi olmuştur, soru, yorum veya eleştirilere açığımdır :) hope to keep in touch

PostSharp Kullanarak Request Response Loglama

Çok küçük projeleri saymazsak Log tutmak bir projede olmazsa olmazlardandır. Hele ki o proeje bir enterprise proje ise müşteri size burdan kuş bile geçse onun log'unu görmek istiyorum gibi bir cümle dahi kurabilir.Bu tür bir projede müşterinin loglamanızı isteyeceği şeylerin başında yapılan request ve response'lar gelir. Metota gelen request ve response'u loglamak için Aspect Oriented yazımızda da bahsettiğim üzre AOP paradigmasından yararlanarak request response log'larını tutabiliriz. Bunun için Postsharp kullanıcaz.

Postsharp ile Excetion Handling yazısında da bahsettiğimiz gibi OnMethodBoundaryAspect class ile sahip olduğumuz bazı metotlar vardı. Exception Handling için OnException metodunu kullanmıştık. Request Response log için OnEntry ve OnExit diye 2 metot mevcut. İsimlerinden de anlaşıldığı üzre bu metotlar ilgili metota giriş ve metottan çıkış anında bir takım işlemler yapmamızı sağlar.

*PostSharp kurulumu vs bilgileri için şu yazıyı inceleyebilirsiniz.

Case'imiz şöyle olsun TracingAspect adında OnMethodBoundaryAspect den inherit olan bir class tanımlayalım ve OnEntry & OnExit metotlarını override edelim ve bu metotlar içerisinde gelen request response'u JSON formatında loglayalım.

    [Serializable]
    public class TracingAspect : OnMethodBoundaryAspect
    {
        JavaScriptSerializer serializer = new JavaScriptSerializer();
        public override void OnEntry(MethodExecutionArgs args)
        {
            var jsonRequest = serializer.Serialize(args.Arguments);
            LogMessage(jsonRequest);
        }

        public override void OnExit(MethodExecutionArgs args)
        {
            var jsonResponse = serializer.Serialize(args.ReturnValue);
            LogMessage(jsonResponse);
        }

        private void LogMessage(string message)
        {
            Console.Write(message);
        }
    }

 

Şimdi ise EFT işlemi yapan bir metot yazalım ve bu metot parametre olarak TransferRequest objesi alsın ve response olarak TransferResponse adında bir model dönsün.

 class Program
    {
        static void Main(string[] args)
        {
            var request = new TransferRequest
            {
                Amount = 540,
                ReceiverIBAN = "TR33 0006 1005 1978 6457 8413 26",
                SenderIBAN = "TR33 0006 1005 1978 6457 8413 26"
            };

            var resp = MoneyTransfer(request);
        }

        [TracingAspect] //Aspect'i ekliyoruz
        public static TransferResponse MoneyTransfer(TransferRequest request)
        {
            var resp = new TransferResponse
            {
                IsSuccess = true,
                Message = "Transfer İşleminiz Gerçekleşti."
            };
            return resp;
        }

        public class TransferRequest
        {
            public decimal Amount { get; set; }
            public string SenderIBAN { get; set; }
            public string ReceiverIBAN { get; set; }
        }

        public class TransferResponse
        {
            public bool IsSuccess { get; set; }
            public string Message { get; set; }
        }
    }

Main fonksiyon içerisinde MoneyTransfer metoduna istekte bulunduğumuzda Metota girerken OnEntry'ye, metotdan çıkarken de OnExit'e düşecektir ve LogMessage fonsiyonuna aşağıdaki gibi message parametlerini gönderecektir.

OnEntry => 

  • [{"Amount":540,"SenderIBAN":"TR33 0006 1005 1978 6457 8413 26","ReceiverIBAN":"TR33 0006 1005 1978 6457 8413 26"}]

OnExit => 

  • {"IsSuccess":true,"Message":"Transfer İşleminiz Gerçekleşti."}
     

Görüldüğü üzre Postsharp sayesinde request ve response log tutma işlemini çok kolay bir şekilde halledebiliyoruz ve aynı zamanda AOP bizlere reusable aspect'ler yazın diyor bizde TracingAspect'i uyulamada istediğimiz her hangi bir yerde kullanıp log tutma işlemini tek bir yerden yönetebiliriz.

Code Review Nedir, Neden Önemlidir

Kod kalitesini artırmak için bir çok yol izlenebilir; unit test, continuous integration, continuous deployment, agile methodology etc. ancak en önemli yollardan biri code review dır. Bazen kaliteli diyebileceğimiz kodlar yazmaya çalışsak bile öyle anlar geliyor ki proje müdürünüz bir anda gelip bu feature'u bugün yetiştirmemiz gerekiyor deyip spaghetti code yazma süreciniz başlıyor. Bu gibi durumlar hep olacak ancak daha sonrasında geriye dönüp yazmış olduğunuz kodu review-refactoring etmemiz gerekmekte. Yada normal akışında geliştirme yapıyor olsak bile teknik olarak bilgili birisi (genelde takım liderleri) yapmış olduğumuz geliştirmelere bir göz atıp ondan sonra master branch'ine commit/checkin yapıyor olmamız gerekir.

Code Review yapmanın bir çok avantajı var;

  • Kod kalitesini arttırır,
  • Bug bulmamızı kolaylaştırır,
  • Developer kendisi olmasa bile bir başkası review işlemi yapacağından geliştirme yaparken daha dikkatli olmasını sağlar,
  • Review işlemi yapan kişi daha önce hiç karşılaşmadı şekilde olumlu geliştirmelerle karşılaşabilir ve onun gelişimine de katkısı olur,
  • Yazılım standartlarına bağlı kalmaya yönlendirir.

Gibi gibi birçok faydasından bahsedebiliriz. 

Başlangıçta biraz garip gelebilir ancak iyi bir flow bulduğumuzda hem yazılım kalitesi, hem ekip çalışması ve ekibin moral-motivasyonu açısından ne kadar büyük bir değişim olduğunu fark edeceksiniz dir.

Code Review İçin İzlenebilecek Yollar/Kurallar

Code Review için belli başlı kabul edilen bazı kurallar mevcut. Bazı software tool'lar kullanarak başlanabilir ancak developer olarak bizlerin uyması gereken bazı kurallar sıralayabiliriz. 

 

Kısa Commit'ler ve Anlaşılır Commit Mesajları

İlgili branch'e commit yaparken bir seferde bütün her şeyi commit'lemekten ziyade kısa kısa paketler halinde yaptığınız geliştirmeleri commit edin ve anlaşılır commit mesajları kullanmaya çalışın. Böyle yaparak her şeyi step-by-step açıklamış olacaksınız ve hem review yapacak kişi için kolay anlaşılabilir olacak hemde kendiniz için geriye dönüp baktığınızda yaptığınız geliştirmeyi hatırlaması daha kolay olacaktır.

Kodları Review Edin Developer'ı Değil

Review yaparken başkalarının yapmış olduğu işleri incelediğinizden eleştiri yaparken bazen yapılan işe değilde kişinin kendisine eleştirilerde bulunulabiliyor. Ancak bu devloper'la üzerinde olumsuz tepebilir. Yanlış yaptıkları bir şeyi gördüğünüzde onları sürekli eleştirmek yerine nasıl daha doğru yapabilirlerdi o yönde tavsiyelerde bulunmak daha çok önemlidir. Tabi bunları söylerken kullandığınız ses tonu da oldukça önemlidir.   

Developer olarak, review eden kişi commit'inize yorumlarda bulunduğunda bunu kişisel algılamamaya çalışın tabi doğrudan kişisel bir söylemde bulunulmuyorsa.  

Muhakkak Checklist'iniz Olsun

Hem review edecek olan kişi hemde developer için checklist'inizin olması önemli daha sistematik bir review süreci için oldukça önemlidir.

  • Bugs,
  • Duplicate Code,
  • Login Pages,
  • Code Style and Formatting
  • etc..

Bu gibi checklist'ler yaparak süreci daha kolay hale getirebiliriz. 

Multiple Reviewers

Genelde bir kişi bulmak bile çok zor oluyor ancak eğer mümkünse kodunuzu birden fazla kişiye review ettirin. Eğer kodla ilgili bir anlaşmazlık var ise örneğin; a kişisi burda factory design pattern kullanman doğru olmuş dedi, B-C kişileri hayır burda abstract factory kullanmalısın dedi. Hemen bu gibi durumlarda oylama yapılıp çoğunluğa göre karar verilebilir.

Ne Zaman Review Yapılmalı ?

Aslında bu büyük oranda development ekibine bağlı.Size bir geliştirme atandı ve 4 gün içinde dev branch'inde geliştirme yaptınız ve test'e gönderdiniz, testlerden herhangi bir bug vs. çıkmayıp "Ok production'a alabiliriz.." dedikten sonra yapmış olduğunuz geliştirmeleri master branch'ine merge işleminden önce review edecek olan kişiye gönderilmesi en doğru olan zamandır diyebiliriz. Review edilmeyen kodları master'a merge etmemek gerekir.

 

Review İşleminden Sonra..

Dev ortamda yaptığınız geliştirmeleri review eden kişi eğer herhangi bir sorun görmez "OK" verir ise master branch'ine merge işlemini yapabilirsiniz.  Eğer yaptığınız geliştirmeler review eden kişiden onay almaz ise tekrardan dev branch'de istenilen refactoring işlemlerini yapıp projenin son halini tekrardan review eden kişiye assign etmek gerekir. Bu sefer reviewer'dan "OK" aldıysanız üstte de belirttiğim gibi master branch'ine geliştirmelerinizi merge edebilirsiniz.

 

Özetle Code Review yazılım kalitesini artırmak için yapılabileceklerin en başında gelir. Eğer Development ekibinin başında olan kişi iseniz büyük ihtimalle review işlemini yapan kişi siz olacaksınızdır ve takımınıza belli başlı kabul görmüş yazılım geliştirme standartlarına uymalarını sağlarsanız review süreciniz daha rahat ve keyifli geçecektir.

 

PostSharp Kullanarak Exception Handling ve Log İşlemi

Daha önce Aspect-Oriented Programming yazımızda AOP'den bahsetmiştik ve AOP'nin .Net tarafında uyarlanabilmesini sağlayan tool'lar ve bu tool'ların en yaygın olanı Postsharp olduğunu söylemiştik. Bu yazıda Postsharp kullanarak uygulamamızda meydana gelecek olan exception'ları yakalamayı sağlayan bir geliştirme yapacağız.

Başlarken

Öncelikle VS'yu açıp yeni bir proje oluşturuyoruz.

  • File > New > Project > Console Application

İsim olarak ben "PostSharpExcHand" dedim siz istediğiniz bir ismi verebilrisiniz, sonrasında Ok'e tıklayıp projeyi oluşturuyoruz.

Daha sonra Postsharp'ı projemize ekleme işlemi var. Bunun için;

  • Tools > NuGet Package Manager > Manage NuGet Packages for Solution

Search kısmına "PostSharp" yazıp çıkan sonuçlar arasından postsharp'ı bulup indiriyoruz sornasında solution'da bulunan hangi projeye eklemek istiyorsak onu seçip yüklemi işlemini bitiriyoruz.

Aspect Tanımlama

AOP yazımızda aspect'lerden bahsetmiştik. Projemizde kullanacağımız reusable modülleri aspectler halinde tanımlayıp kullanmak istediğimiz yerlerde aynı metot üstünde attribute tanımlarmış gibi eklediğimizden bahsetmiştik. Bu yazıda Exception anında çalışacak olan aspect'i tanımlicaz. Bunun için projeye ExceptionHandlerAspect adında bir class ekleyelim. Postsharp ile birlikte gelen OnMethodBoundaryAspect adında bir class var ve bu class'tan inherit olan class'lar aşağıda da görüldüğü gibi override edebileceği bazı metodlara sahip oluyorlar.

Bu metotları kullanarak log,exception handling gibi bir çok ihtiyaca çözüm üretebilirsiniz. Biz bu yazıda exceptionHandling işlemi yapacağımız için oluşturduğumuz ExceptionHandlerAspect class'ını OnExceptionAspect class'ından türetiyoruz ve bu metotla birlikte gelen OnException metodunu override ediyoruz.

   [Serializable]
    public class ExceptionHandlerAspect  : OnExceptionAspect
    {
        public override void OnException(MethodExecutionArgs args)
        {
            string msg =  string.Format("{0}: Error running {1}. {2}{3}",DateTime.Now, args.Method.Name, args.Exception.Message, args.Exception.StackTrace);
            Debug.WriteLine(msg);
            args.FlowBehavior = FlowBehavior.Continue;
        }

Yukarıda görüldüğü gibi uygulamada exception meydana geldiğinde OnException metoduna düşecektir ve burda ihtiyaca göre log atma vs. gibi işlemleri yapabliriz.

Tanımladığımız Aspect'i Kullanma

Şimdi ise sırada tanımladığımız Aspect'i projede kullanma var. Bunun için uygulamada Exception olabilieceğini düşündüğümüz metotların başına attribute olarak ExceptionHandlerAspect'i ekleyebilriz.

    class Program
    {
        static void Main(string[] args)
        {
            ThrowSampleException();
        }
 
        [ExceptionHandlerAspect]//Attribute olarak Aspect'i ekledik
        private static void ThrowSampleException()
        {
            throw new NotImplementedException ();
        }
    }

Görüldüğü üzre yukarıda bulunan ThrowSampleException()  içerisinde exception alındığında üzerinde tanımlı bulunan ExceptionHandlerAspect'inden dolayı bu class içerisine gidip OnException metoduna düşecektir ve ilgili exception açıklamasını alıp artık canınız ne isterse onu yapabilirsiniz :) Log atabilirsiniz, çalışmasını istediğiniz ayrı bir process olabilir onu çalıştırabilirsiniz vs. vs.

ThrowSampleException IL Kodları

ExceptionHandlerAspect ThrowSampleException metoduna ne kazandırdı diye IL kodlarına bakacak olursak aslında try/catch kullandı ve metot içerisinde bulunan kodları try bloğunun içerisine alarak meydana gelecek olan exception'lar için catch bloğunda bunları handle eden kodları yazdı.

private static void ThrowSampleException()
{
    try
    {
        throw new NotImplementedException();
    }
    catch (NotImplementedException exception)
    {
        MethodExecutionArgs methodExecutionArgs = new MethodExecutionArgs(null, null);
        MethodExecutionArgs arg_1F_0 = methodExecutionArgs;
        MethodBase m = Program.<>z__Aspects.m2;
        arg_1F_0.Method = m;
        methodExecutionArgs.Exception = exception;
        Program.<>z__Aspects.a0.OnException(methodExecutionArgs);
        switch (methodExecutionArgs.FlowBehavior)
        {
        case FlowBehavior.Default:
        case FlowBehavior.RethrowException:
            IL_55:
            throw;
        case FlowBehavior.Continue:
            methodExecutionArgs.Exception = null;
            return;
        case FlowBehavior.Return:
            methodExecutionArgs.Exception = null;
            return;
        case FlowBehavior.ThrowException:
            throw methodExecutionArgs.Exception;
        }
        goto IL_55;
    }
}

Reusability

Evet arkadaşlar aslında AOP kullanarak exception handling yapmamızda ki en büyük amaç bu Reusability. Tanımlamış olduğumuz aspect'i artık projenin her yerinde kullanabiliriz ve bu durum bizi çookk ama çok büyük bir iş yükünden kurtarmış olup spaghetti code'lar yazmamıza engel olmuştur.

Son olarak; AOP candır.. :)

Interface Segregation Principle

SOLID prensipleri yazı dizisinde sırada SOLID'in "I" olan Interface Segregation (ISP) var. Bu prensip bize kısaca şunu söylüyor; "Nesneler asla ihtiyacı olmayan property/metot vs içeren interface'leri implement etmeye zorlanmamalıdır  !".

Terminolojide bu interface'ler "fat" yada "polluted" interfaces diye adlandırılır.  ISP uygulanmadığında bir den fazla sorumluluğu olan nesneler ortaya çıkar ki bu da aslında SOLID'in "S" si olan "Single Responsibility" prensibine aykırı bir şeydir. Bu sınıflar yüklenen çoklu sorumluluklardan dolayı zaman içerisinde yönetilemez hale gelirler ve projemiz patates olur çıkar. Bu tarz case'ler le karşılaşıldığında interface içerisinde bulunan kullanılmaması gereken özellikleri içeren yeni interface'ler tanımlanır ve ihtiyaca göre nesneler tarafından implement edilir. Eğer projeniz bu prensibi ihlal ediyorsa Adapter Design Pattern avantajlarını kullanarak da ilerleyebilirsiniz. İlgili nesne interface'i implement edip hiç kullanmayacağı metotlara sahip olduğunda class'ınız içerisinde "NotImplementedException" yazan metotlar olacaktır ve buda OOP açısından hiç istenen bir şey değildir.

ISP'yi örnek bir case üzerinde anlatmaya çalışalım. Bir tane FileLog ve DbLog yapan işlemleri yapan bir proje geliştireceğiz ve içerisinde ILog adında bir interface tanımlayalım ve bu interface'inde Log(), OpenConn(), CloseConn() gibi metodları olsun.

public interface ILog
{ 
    void Log(string message);

    void OpenConnection();

    void CloseConnection();
}

 

İlk olarak DBLogger sınıfını yazalım

public class DBLogger : ILog
{		
        public void Log(string message)
        {
            //Code to log data to a database
        }

        public void OpenConnection()
        {
            //Opens database connection
        }

        public void CloseConnection()
        {
           //Closes the database connection
        }
}

 

Şimdi de FileLogger class'ını yazalım. 

public class FileLogger : ILog
    {
        public void Log(string message)
        {
            //Code to log to a file           
        }
    }

FileLog işlemi yaparken Db de olduğu gibi bir Connection açıp kapama işlemi yok ve bu metotları FileLogger'da kullanmak istemiyoruz sadece ILog interface'inde tanımlı olan Log(string message) metodunu kullanmak istiyoruz. Projeyi derlediğinizde şöyle bir hata alırsınız "FileLogger class doesn't implement the interface members ILog.OpenConnection() and ILog.OpenConnection()" .  Peki hatayı görüp eksik interface'in eksik üyelerini implement edelim. Bu sefer class'ımız aşağıdaki gibi olacaktır.

public class FileLogger : ILog
    {
        public void Log(string message)
        {
             //Code to log to a file           
        }

        public void CloseConnection()
        {
            throw new NotImplementedException();
        }

        public void OpenConnection()
        {
            throw new NotImplementedException();
        }
    }

E şimdi ne oldu ? Patates ! Hiç ihtiyacımız olmasa da FileLogger class'ına 2 tane gereksiz metot kazandırdık. İşte ISP burada devreye giriyor. Yapmamız gereken şey yeni interface veya interface'ler tanımlayarak FileLogger ve DbLogger class'larının sadece ihtiyacı olan metotları içeren interface'i implemente etmesini sağlamak.

Yeni interface'ler aşağıdaki gibi olacaktır.

    public interface ILog
    {
        void Log(string message);
    }

    public interface IDBLog: ILog
    {
        void OpenConnection();

        void CloseConnection();
    }

    public interface IFileLog: ILog
    {
        void CheckFileSize();

        void GenerateFileName();
    }

 

Bu interface'leri implement eden DbLogger ve FileLogger class'larımızda aşağıdaki gibidir.

 public class FileLogger : IFileLog
    {
        public void CheckFileSize()
        {
            //Code to check log file size
        }

        public void GenerateFileName()
        {
            //Code to generate a new file name
        }
		
        public void Log(string message)
        {
            //Code to log data to the log file
        }
    }

    public class DBLogger : IDBLog
    {
        public void Log(string message)
        {
            //Code to log data to the database
        }

        public void OpenConnection()
        {
            //Code to open database connection
        }

         public void CloseConnection()
         {
            //Code to close database connection
         }
    }

Interface Segregation çok önemli bir prensiptir. Özellikle Adapter Design Pattern ile haşır neşir olan arkadaşlar için dahada fazla öneme sahiptir. İçerisinde 60-70 tane üyesi bulunan interface'ler yazmaktan da çekinin bu gibi durumlarda bir yolunu bulup interface üyelerini ayırıp gruplayıp yeni interface'ler türetmeye çalışmamız daa doğru olacaktır. 

C# 7.0 Yenilikleri

Daha C# 6.0 'ın tüm özelliklerini yeni yeni kavramışken Microsoft C# 7.0 ile gelecek olan özelliklerden bazılarını açıkladı bile. Gelecek olan feature'lara baktığımızda çokta fazla major yenilikler yok gibi ancak yine de kayda değer şeyler var. Gelin bu feauture'ları ufaktan bi inceleyelim

Öncelikle C#7.0 ın özellikleri VS2015'de default olarak yok. Normalde vs2015'de yeni bir proje açtığınızda default C# 6.0 ile gelir. 7.0'ın özelliklerini aktifleştirmek için VS de proje oluştururken ufak bir kaç şey yapmak gerekiyor.

İlk olarak C#da bir tane console proje oluşturalım ve sonrasında solution'da bulunan projeye sağ tıklayıp özellikler diyelim. Açılan ekrandan Build tabına geçelim ve "conditional compilation symbols" textbox'ına __DEMO__ yazalım. Projeyi build ettikten sonra artık C# 7.0 özelliklerini otomatik olarak alacaktır.

 

 

C# 7.0 Features

  • Local functions
  • Binary literals
  • Digit separators
  • Pattern matching
  • Ref returns and locals

 

Local functions

Bir çok yazılım dili fonksiyon içinde fonksiyon yazımına izin verirken C# için bu geçerli değildi. 7.0 ile artık fonksiyon içerisine fonksiyon tanımlıyor olacağız.

public int Method_1(int x,int y)
	{
		int Metho_2(int x)
		{
			return x*x;
		}
	 
		return Metho_2(x)*y;
	}

 

Binary literals and Digit separators

Bu özelliğin aslında 6.0 ile geleceği söyleniyordu ancak galiba yetiştiremediler ki 7.0 ile geliyor. Bu özellikle birlikte artık numeric tanımlamaları binary olarak yazabileceğiz. 

	public void BinaryLiterals()
	{
		var numbers = new[] { 0b0, 0b1, 0b10 };
		foreach (var number in numbers)
		{
		  Console.WriteLine(number);
		}
	}

 

Daha büyük sayıları daha kolay okuyabilmek için ise "_" ayıracını kullanarak digitleri gruplayabiliriz ve bu decimal, hexa veya binary'ler içinde geçerlidir. 

int oneBillion = 1_000_000_000;
int num_1 = 0x7FFF_1234;
int num_2 = 0b1001_0110_1010_0101;

 

Pattern matching

Pattern matching özelliği fonkysionel programlama dillerinde çok yaygın bir özellik ve C# 7.0 da "is" operatörü ile bazı özellikleri bize sunuyor ancak final sürümü ile birlikte daha fazla özellik ekleneceği söyleniyor.

1) Type Pattern

Type pattern reference typle'ların runtime type test işlemi yaparken işimize yarayacak olan bir özellik.

public void Foo(object item)
{
    if (item is string s)
    {
        WriteLine(s.Length);
    }
}

2) Constant Pattern

Constant pattern bir ifadenin runtime değerini test etmek için kullanılır.

public void Foo(object item)
{
    switch (item)
    {
        case 10:
            WriteLine("It's ten");
            break;
        default:
            WriteLine("It's something else");
            break;
    }
}

3) Var Pattern

public void Foo(object item)
 {
     if(item is var x)
     {
         WriteLine(item == x); // prints true
     }
 }

4) Wildcard Pattern

public void Foo(object item)
 {
     if(item is *)
     {
         WriteLine("Hi there"); //will be executed
     }
 }

5) Recursive Pattern

public int Sum(LinkedListNode<int> root)
{
    switch (root)
    {
        case null: return 0;
        case LinkedListNode<int> { Value is var head, Next is var tail }:
            return head + Sum(tail);
        case *: return 0;
    }
}

 

Ref returns and locals

C# ın ilk versiyonundan itibaren "ref" keyword'ünü kullanarak metotlara pass by reference ile parametreler geçebiliyoruz. Bu özellikle birlikte metottan pass by reference ile değer dönmesini sağlıyor.

static void Main()
 {
     var arr = new[] { 1, 2, 3, 4 };

     ref int item = ref Get(arr, 1);

     Console.WriteLine(item); //2

     item = 10;

     Console.WriteLine(arr[1]); //10

     Console.ReadLine();
 }

ref int Get(int[] array, int index)
{
   return ref array[index]; 
}

 

Kısaca C# 7.0 ile gelecek olan feature'lara değindik ancak relase olması için henüz çok erken ve ilerleyen sürümlerde üstte belirttiğimiz özelliklerinin bazıları değişebilir de. 7.0 ile ilgili yeni duyumlar geldikçe de yazmaya devam...

 

Aspect Oriented Programming Nedir

Aspect Oriented Programming (AOP) tükçesi "Cephe Yönelimli Programlama" bir programlama paradigmasıdır. İsim olarak bazılarımıza yabancı geliyor olabilir çünkü çok yeni bir kavram değil ve gelişen yazılım teknolojileri ve AOP nin daha kolay ve verimli implement edilmesini sağlayacak "PostSharp" gibi tool'ların çıkmasıyla birlikte epey bir önemli hale gelir oldu AOP.

Biz yazılımcılar daha iyi kodlar yazmak için hep kullandığımız bir cümle var "Separation of Concern". AOP'nin çıkış noktası aslında buna dayanıyor diyebiliriz. AOP birbiriyle kesişen ilgilerin (Cross-Cutting Concerns) ayrılması üzerinedir. Uygulama genelinde kullanılacak olan yapıları (logging,exception hand., cache, etc.) core tarafta yazdığımız koddan ayırarak bir çeşit ayrı küçük programcıklar şeklinde yazıp projede kullanmayı hedefler diyebiliriz.

Örnek olarak 70.000 kişinin çalıştığı çok büyük bir holding için uygulama geliştiriyoruz geriye bütün çalışan listesini dönen bir metod yazıyor olalım ve klasik her uygulamada olması gereken belli başlı şeyler vardır; Cache,ExceptionHandling, Logging gibi bizde metodumuzda bunları yapıyor olalım;

 public IEnumerable<Employee> GetEmployeeList()
        {
			//Request'i yapan kişinin yetkisi varmı yokmu kontrol et
			//metoda girerken request'i log'la
			
            try
            {
                var resultList = DbQuery("Select * from Employee"); // database de ki tabloya sorgu attığımız varsayalım ve 70 bin kayıt gelsin
				
                //geriye dönen sonuçları cache'e at bir sonrakine cache'den ver

                return resultList;
            }
            catch (Exception ex)
            {
                // meydana gelen Exception'ı handle edip log'la ve client'a gidecek olan response'u modify et  
                throw;
            }
			
			//metoddan çıkarken response'u log'la
        }
}

Yukarıda bulunan metodu incelediğimizde ne kadar eksik olduğunu görebiliyoruz. Yorum satırlarında yazan işlemler için geliştirmeler yapmamız gerekmekte ancak bu geliştirmeyi nasıl yapacağız  ? CheckUserAuth(), LogRequest(), LogException(), LogResponse(), ModifyResponse() gibi metodlar yazıp bu metodları ilgili yerlerde her metodda yazmak herhalde ilk akla gelen çözüm ancak AOP bize daha farklı şekilde yapmamız gerektiğini söylüyor. Bunları ayrı modüller olarak tasarlayıp daha kullanılabilir, okunabilir ve SOLID prensiplerine uygun geliştirmeler yapmamız gerektiğini söyler.

Peki birbirleri ile çakışan ilgileri birbirlerinden nasıl ayıracağız ? İşte bu noktada karşımıza interceptor çıkmakta.

Interceptor

Interceptor’ belirli noktalarda metot çağrımları sırasında araya girerek çakışan ilgilerimizi işletmemizi ve yönetmemizi sağlamakta. Buda metotların çalışmasından önce veya sonra bir takım işlemleri gerçekleştirebilmemeizi sağlar ve AOP nin yapısı tamamiyle bunun üzerine kurulu desek yanlış olmaz heralde. Interceptor'u implemente etme olayına girmicem çünkü yukarıda da bahsettiğim gibi .Net tarafında Nuget üzerinden indirip kullanabileceğimiz Postsharp kütüphanesi bu işi diplerine kadar yapmakta ve bizlere sadece attribute tanımlamaları yapmayı bırakmakta. 

Şimdi yukarıda yazmış olduğumuz kodu gelin birde AOP standartlarına uygun şekilde yazalım.

        [UserAuthAspect]
        [LoggingAspect]
        [AppCacheAspect(25000)]
        [ExceptionAspect]
        public IEnumerable<Employee> GetEmployeeList()
        {
            var resultList = DbQuery("Select * from Employee");
            return resultList;
        }

[UserAuthAspect] [LoggingAspect] [AppCacheAspect] [ExceptionAspect] attribute'lerini tanımladık ve AOP nin dediği gibi Cross-Cutting yani kesişen yerleri Aspect'ler kullanarak attribute seviyesinde kullanılabilir hale getirdik.Yazmış olduğumuz 2. metot ile 1. metot arasındaki satır sayısı farkına baktığımızda dağlar kadar fark var ve en önemlisi daha okunabilir bir kod yazmış olduk.  

Aspect-Oriented Programming'in Sağladıkları

  1. İçi içe yazılmış ve sürekli tekrar eden kodlardan kurtulabiliyoruz,
  2. Daha temiz ve anlaşılır kodlar yazabiliyoruz,
  3. Yazmış olduğumuz kodları daha abstract hale getirerek modülerliğini arttırıyoruz,
  4. Bakım ve geliştirme maliyetlerini azaltıyoruz,
  5. Uygulamamızı daha yönetilebilir ve daha esnek hale getirebiliyoruz.

Görüldüğü üzre AOP yaklaşımı geliştirdiğimiz uygulamalar için bizlere bir çok faydalar sunmakta ve Postsharp gibi çeşitli tool'lar ile birlikte projenize AOP'ye uygun hale getirmek dahada kolay hale gelmiş durumda. Bundan sonraki AOP ile ilgili yazılarda Postsharp kullanarak Cache, Logging, ExceptionHandling gibi örnekler ile deva ediyor olacağız.  

Egosuz Programlama & Programcı Egosu

Biz developer'lar bazen yaptığımız iş gereği "dünyayı kurtarıyoruz" havasına girebiliyoruz (aslında sadece developer'lar değil test müh, analistler, tasarımcı arkadaşlar vs.). Sektörde her zaman bu gibi arkadaşlar hep varlar ve dehşet-ül vahşet düzeyde bir özgüven-ego patlaması yaşayabiliyorlar.Bu arkadaşlar istisnai olmadığı taktirde %99 oranında hep yazdıkları kodların veya ortaya attıkları tezlerin en iyisi olduğunu iddia ederler ve genelde "abi bundan daha iyi bir çözüm yok yaa.." gibi cümlelerle tanırız bu arkadaşları. Neden bu şekilde iddialı cümleler kurduklarını anlamak için bence biraz gerilere gidip bu arkadaşların staj dönemlerine inmek gerekir zira bu arkadaşlar çok büyük olasılıkla sağlam bir code review'lık dönemini kaçırmış olabilirler veya junior'lık dönemlerinde kodları inşaata kaçmış olabilir :)

Gereksiz ve anlamsızca ego sahibi olan bu arkadaşlar her şey hakkında en iyi ve en kabul görebilir öneriler sunduklarını düşünürler, her ortamda teknik bilgilerini değişik bir jargonla anlatarak ortaya koymaya çalışırlar, en iyi kodu onlar yazmıştır ve eleştiriye kapalıdırlar. Bazen öyle durumlar olur ki bir konu hakkında konuşuluyordur ve hiçbir fikri olmamasına rağmen sırf o konu hakkında expert olduğunu kanıtlamaya çalışmak adına tuhaf bir şekilde konuşmaya başlarlar. Tabiki de benim fikrim ancak bu arkadaşlarla kavgasız gürültüsüz iletişim kurabilmenin en iyi yolu bu tarz hareketler yaptıklarını anladığınızda öyle bir şey söyleyin ki bir daha benzeri hareketler yapmaya kalkışmasın. Bu tabii ki de küfretmek falan değil :) Ortaya koydukları tez'in sırf söylemiş olmak için söylediklerini düşünüyorsanız ve siz daha doğru bir tez'e sahipseniz bu tezinizi savunmaktan kesinlikle çekinmeyin ve onun tezini çürütmeye çalışın.

Böyle bir kişi eğer ekip arkadaşınızsa yani aynı projede beraber development yapıyorsanız şu gibi cümleler duymanız hiç zor değil "abi burayı böyle yazmasak daha iyi yaa..", "abi ben daha önce bunla ilgili çok kral bi çözüm bulmuştum yaa..","bu böylemi yapılır yaa.." falanlar filanlar. Bu gibi cümleler kuran bir ekip arkadaşınız var ise ve yüksek oranda ego sahibi olduğunu düşünüyorsanız benzer cümleler kurmasının asıl amacı üstünlük sağlamaya çalışmak veya benzer bir kodu oda yazmıştır zamanında ve o yazdığının ilelebet en iyi çözüm olacağını düşünür çünkü ezberlemiştir onun için hep bildiği yoldan gitmek gerekmektedir ve senide ısrarla o yola sokmaya çalışır.

Evet malesef bende bu arkadaşlardan biriyle bir süreliğine çalışmak zorunda kaldım ve yaşadığım bir örneği vermeden geçemicem. Eski çalıştığım şirkette bir mobil projesini geliştirme yapan arkadaştan devraldım ve geliştirmeye ben devam edecektim kendisi başka bir  departmana geçmişti. Projeyi devraldığımda markette bulunan versiyonu yanılmıyorsam 1.1 di ve ben yaklaşık 2 sene o projede çalışmıştım. 2 sene dolmasına yakın bir dün bu arkadaş burnu 5 karış kalkık vaziyette yanıma geldi ve ne hikmettir bilmem proje hakkında sorular sormaya başladı.Sorulardan biride uygulamanın bir sonraki versiyonunun ne olacağıydı. Bende 3.0 olacağını söyledim.O arkadaş sahip olduğun egoyla şöyle bir cümle kullandı "Ben sana bişey söylimmi siz bu versiyonlamayı kesin yanlış yapıyorsunuz..." bende dedim ki "wtf..? yani ne alaka nerden çıkardın bunu ?" oda "ben bu projeyi bıraktığımda v1.1 di.." arkadaş zannediyordu ki kendisi uygulamanın %25 inin geliştirmesini yapıp v1.1 ile markete çıkıp uygulama bitmişti. Geriye kalan 2 sene içerisinde uygulamanın %85'e yakının geliştirilip 6 defa update çıkıldığından haberi yok, haberi olmasa daha düşünmesine de gerek yok çünkü 2 sene önce o uygulamayı yaptı ve bitti. Ben naptım peki ? Bir güzel o kişiye konuyu açıklayıp arkasını dönüp fıtı fıtı gidişini izleyerek çayımı yudumladım.

Malesef ego sahibi insanlar IT sektöründe hep olacaktır, bu insanlar yarın bir gün bizlerde olabiliriz ama sahip olduğumuz ego'nun makul düzeyde olması çok önemli.

Peki gerçekten biz developer'lar makul düzeyde ego'ya nasıl sahip olabiliriz, neler yapmalıyız ..? Bununla ilgili bilgisayar bilimleri için bir çok makale yayınlamış olan yazar Gerard M. Weinberg "Egoless Programming" adında bir makale yazıyor. Üstad konu ile ilgili yaklaşık 40 yıl önce 10 tane kural tanımlamış. Bunlar;

1. Understand and accept that you will make mistakes

Türkçesi "herkes gibi sende hata yapacaksın arkadaş bunu anla ve kabul et.." diyor. Bug'ı olmayan uygulama olmaz ve her zaman uygulamalarda exception'lar meydana gelecektir. Önemli olan bu gibi durumlar production'ı etkilemeden yakalayıp müdahale edip uygulamamızı hatalardan arındırmaktır. Tabi bug'ları ortaya çıkartmak içinde çok iyi test süreçleri gerekmektedir.

 

2. You are not your code

Review yapmanın asıl amacının meydana gelmiş veya gelecek olan problemleri bulmak olduğun hatırla ve problemler olacaktır da. Review sırasında birisi projenizde herhangi bir problem bulduğunda veya eleştirel bir yorumda bulunduğunda bunu kişisel bir şey olarak algılama ve sadece geliştirme yapmaya devam et.

 

3. No matter how much you know, someone else will always know more

Hiç kimse ben iyi programcıyım dememelidir. Her zaman için herkesin farklı bakış açısından sorunları analiz edip çözümler ürettiğini düşünmek gerekir ve buda her zaman için daha iyisinin olabileceği gerçeğini unutmamamız gerektiğini işaret eder. Sahip olduğumuz bilgi ve beceriler tabiki çok değerli ancak bunun da bir limitinin olduğunu bilmemiz gerekir. Geliştirme yaparken her developer'ın izlediği farklı bir yol olabilir ve daha önce senin hiç bilmediğin-denemediğin bir şekilde sorunları çözüyor olabilir ve bu gibi case'leri çok fazla abartıp sidik yarışına girmeye gerek yoktur. Sadece şunu bilmek gerekir her zaman senden daha farklı veya senden daha iyisini bilen biri olacaktır.

 

4. Don’t rewrite code without consultation

Bu kural bize kodu fix etme ile yeniden yazma arasında ince bir çizgi olduğundan bahsediyor. Bu farkı iyi bir şekilde bil ve değişiklik yapacağın yerlerde core koda dokunup projeyi yeniden geliştirmene neden olacak şeylerden uzak dur.

 

5. Treat people who know less than you with respect, deference, and patience

Ekibinde veya etrafında her zaman senin kadar teknik bilgisi olmayan insanlar olacaktır. Bunlara karşı anlayışlı ve saygılı olmaya çalış. Eğer mümkünse onlara konudan bahset ve teknik tarafını anlamada yardımcı ol. 

 

6. The only constant in the world is change

Değişim yazılım dünyasında kaçınılmazdır ve değişime açık ol ve geldiğinde gülümseyerek kabul et :) İstenilen değişikliği bir challenge olarak gör ve kendine yeni bir şeyler katacağını düşünerekten hareket et.

 

7. The only true authority stems from knowledge, not from position

Belli konular hakkında bilgi sahibi olmak beraberinde yetkili olmayı da gerektirir ve yetkide beraberinde saygılı olmayı getirir. Eğer egosuz bir ortamda saygı istiyorsan öncelikle bilgi üretmen gerekir.

 

8. Fight for what you believe, but gracefully accept defeat

Bazen sahip olduğunuz fikirlerin veya ortaya attığınız tezlerin reddedilebileceği gerçeğini unutmayın bu her zaman ihtimal dahilindedir. Bazen haklı olduğun durumlarda bile asla intikam almaya çalışmayın hatta "ben sana demiştim.." vs gibi şeyler dahi söylememeye özen gösterin.

 

9. Don’t be the “coder in the corner”

Ofisin en karanlık köşesinde oturup mesai saati boyunca sadece kişisel ihtiyaçlarını karşılamak için yerinden kalkan kişi olmayın çünkü o developer gözden uzak olduğu gibi gönülden de ırak olur. Her zaman için ofis içinde olup bitenlerden haberiniz olsun ve her zaman kendinizi ekibinizin ve şirketinizin bir parçası olarak görün.

 

10. Critique code instead of people – be kind to the coder, not the code

Mümkün olduğunca yazacağın yorum satırlarında pozitif bir dil kullanmaya çalış ve yorumlarında dünyaları yeniden yarattığından çok kod kalitesinin gelişimine yönelik açıklamalarda bulun. Yorum standartlarınız standart olup resmi bir dil kullanmaya özen gösterin ve her zaman için projeye sizden sonra gelecek olan kişiyi düşünün.

Yazının başında da bahsettiğim gibi ego makul düzeyde olduğu sürece güzeldir. Yaptığımız işlerle övünürken başkalarını ezme düşüncesine girmemeliyiz ve bırakın başkaları bizi övsün. Böyle olduğu taktirde çalışma hayatı hem siz hemde çalışma arkadaşlarınız için daha eğlenceli ve çekilesi olacaktır.

 

Liskov Substitution Principle

Geldik Liskov prensibine. Bu yazıda SOLID' in "L" si olan "Liskov Substitution Principle (LSP)" prensibinden bahsedicez. 

LSP'nin tarihine bakacak olursak; bu prensip ilk olarak 1987 yılında Barbara Liskov tarafından tanıtıldı ve daha sonrasında Jeannette Wing ile birlikte 1993 yılında bu prensibi resmi olarak yayınladılar.

Bu prensibin orjinal tanımı "Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T." dır. Ancak bu tanımdan senin benim gibi hiç kimse bir şey anlamadığı için namı değer bob amca Robert C. Martin  "Agile Principles, Patterns, and Practices in C#" kitabında bu prensibi kısaca "Subtypes must be substitutable for their base types." diye tanımladı ve günümüze yazılım dünyasında da bu tanımıyla kabul görmektedir.

Bu kadar tarih ve ingilizce bilgisinden sonra gelelim Liskov'un Türkçe sine. Bu prensip bize şunu söyler ; Alt sınıflardan oluşturulan nesneler üst sınıfların nesneleriyle yer değiştirdiklerinde aynı davranışı göstermek zorundadırlar.. Daha bizim dilden konuşacak olursak ; alt sınıf üst sınıftan kalıtım alırken property, method vs gibi bazı kullanmayacağı özellikler kazanmamalıdır. Eğer böyle bir duruma sebep olacak bir inheritance işlemi var ise alt sınıfın kullanmadığı fonksyon, metod vs. için farklı bir çözüm (sadece ihtiyacı olan özelliklerin bulunduğu başka bir base class vs. gibi) düşünülmelidir çünkü alt sınıf üst sınıfın bütün özelliklerini tam anlamıyla kullanamadığından yer değiştirdiklerinde aynı davranışı gösteremeyeceklerdir ve Liskov'a ters düşen bir durumdur.

 

Örnek uygulama üzerinden ilerleyelim, case şu şekilde olsun ; Bir tane Bank isminde bir class ve bu class içersinde Withdraw adında ara çekm işlemini yapan bir virtual metod olsun, 2 tanede hesap tanımı yapalım. Bank objesini kullanarak bu hesaplardan para çekme işlemini yapalım ve tabi ki bunu LSP kurallarına uyarak yapmaya çalışalım.  

 

  public class Bank
    {
        public void Withdraw(Account acc, int amount)
        {
            acc.Withdraw(acc.Id, amount);
        }
    }

    public class Account
    {
        public Account(int AccountId)
        {
            this.Id = AccountId;
        }

        public virtual int Id { get; set; }

        public virtual void Withdraw(int accountId, int amount)
        {
            Console.WriteLine("In base withdraw");
        }
    }

    public class SavingAccount : Account
    {
        public SavingAccount(int savingAccountId) : base(savingAccountId)
        {

        }

        public override void Withdraw(int accountId, int amount)
        {
            Console.WriteLine("In SavingAccount withdraw");
        }
    }

    public class CurrentAccount : Account
    {
        public CurrentAccount (int currentAccountId) : base(currentAccountId)
        {

        }

        public override void Withdraw(int accountId, int amount)
        {
            Console.WriteLine("In CurrentAccount withdraw");
        }
    }

 Şimdide Main fonksiyonu içerisinde bu yazmış olduğumuz class'ları kullanarak para çekme işini yapalım.

 using System;

    public class Program
    {
        static void Main(string[] args)
        {
            Bank bank = new Bank();
            Account acc = new Account(1);
            bank.Withdraw(acc, 100);
        }
    }

Yukarıda ki örnekte olduğu gibi Bank class'ı içerisinde bulunan Withdraw metodu bir Account objesini parametre olarak alıyordu. İlk kullanımda bir adet acc isminde Account oluşturup Withdraw metoduna verdik ve acc de bulunan Withdraw metodunu kullanarak para çekme işlemini yaptık.

Ancak LSP bize ne diyordu ; Alt sınıflardan oluşturulan nesneler üst sınıfların nesneleriyle yer değiştirdiklerinde aynı davranışı göstermek zorundadırlar. Aşağıdaki örnekte de LSP ye uygun biçimde kullanımı göreceğiz

 using System;

    public class Program
    {
        static void Main(string[] args)
        {
            Bank bank = new Bank();

            Account saving = new SavingAccount(2); //LSP nin dediği gibi sub class'lar base class'larla yer değiştirdiklerinde aynı davranışı göstermeleri beklenir
            bank.Withdraw(saving, 100);
        }
    }

Yukarıda ki gibi ise saving  isminde bir SavingAccount oluşturduk ve bu objede Account'ın bir alt class'ı olduğu için onun yerine kullanılabilir durumda Account saving = new SavingAccount(2); dedik ve Bank class'ında bulunan Withdraw metoduna parametre olarak geçtik ve aynı ilk kullanımda yaptığımız gibi saving objesininde Withdraw metodunu çağırıp para çekme işlemini tamamladık.

 

İnternette Liskov için çoğunlukla Rectangle örneğini görmek mümkün, bende herkes onu yazmışken biraz daha farklı bir örnek ile ele alim istedim ve bu örnek üzerinden gittim umarım anlaşılır olmuştur :)

Open Closed Principle

SOLID prensipleri yazı serisinde daha öncesnde SOLID nedir ve Single Responsibility konularından bahsetmiştik. Şimdi ise sırada SOLID'in  "O" su olan Open-Closed Principle. Bu prensip 1988 yılında fransız akademist Bertrand Meyer tarafından ortaya atılıp şu şekilde tanımlandı;

"Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification."

Peki ne demek bu "gelişime açık değişime kapalı" sözü ? Şu bir gerçek ki bir kod yazacaksınız ve ilelebet hep aynı kalacak.. tamamen palavra. Hiç bir kod yıllar içinde değişime uğramadan kalamaz, sürekli olarak yeni bir feature ekleme durumu söz konusudur ve müşteri sürekli olarak "şunu da ekleyelim, bunu da ekleyelim, şu da olsun.." vs. vs. istekler hiçbir zaman bitmeyecektir. Bu tarz durumlar için Open-Closed bize yeni gelen değişiklik isteklerini projenize eklerken yazmış olduğunuz sınıfların genel davranışlarını değiştirmeden sadece birkaç ufak dokunuşla bu geliştirmeleri ekleyebileceğiniz class lar yazmamızı söylüyor. Yani Core koda gerekirse hiç müdahale etmeden yeni feature'ları ekleyin diyor. Sebebi ise mevcut koda yapılacak olan her müdahale yeni bug'ların çıkmasına neden olabilir ve buda yeniden test-analiz süreci demektir ki bunu hiçbir firma veya çalışan istemez. 

Örnek bir proje üzerinden ilerleyelim. Bad Example ve Better Example diye Open-Closed'u iki şekilde ele alalım.

 

Bad Example 

Örneğimiz şu şekilde olacak; Araba ve Otobüs üretimi yapan bir fabrikamız var diyelim. Bunun için bir tane aşağıdaki gibi Vehicle adında bir class'ımız olsun. Bu class içerisinde VehicleType isminde bir enum ve bu enum'ında Car-Bus diye 2 değeri olsun. Daha sonra Vehicle class'ından inherit olmuş Car ve Bus isminde 2 class oluşturalım ve constructor'larında gerekli enum değerlerini verelim.

Vehicle.cs

namespace BadExample
{
    public class Vehicle
    {
        public VehicleType VType { get; set; }
    }

    public enum VehicleType
    {
        Car,
        Bus
    }

    public class Car : Vehicle
    {
        public Car()
        {
            this.VType = VehicleType.Car;
        }
    }

    public class Bus : Vehicle
    {
        public Bus()
        {
            this.VType = VehicleType.Bus;
        }
    }
}

 

Şimdi ise bu araçları üretme kısmına geldi. VehicleFactory adında bir class oluşturalım ve bu class içerisinde ProduceVehicle isminde Vehicle  objesini parametre olarak alan bir metod olsun ve bu metoda verilen objedeki vehicleType enum değerine göre ilgili aracı üreten fonksiyonları çağırsın.

VehicleFactory.cs

namespace BadExample
{
    public class VehicleFactory
    {
        public void ProduceVehicle(Vehicle vehicle)
        {
            switch (vehicle.VType)
            {
                case VehicleType.Car:
                    ProduceCar((Car)vehicle);
                    break;
                case VehicleType.Bus:
                    ProduceBus((Bus)vehicle);
                    break;
            }
        }

        private void ProduceCar(Car car)
        {
            Console.WriteLine("Car Produced\n");
        }

        private void ProduceBus(Bus car)
        {
            Console.WriteLine("Bus Produced\n");
        }
    }
}

 

Şimdi sırada yazmış olduğumuz class'ları kullanarak araçları üretme işlemi var. Bunun için Program.cs class'ı aşağıdaki gibi olacak

Program.cs

namespace BadExample
{
    class Program
    {
        static void Main(string[] args)
        {
            VehicleFactory vf1 = new VehicleFactory();
            vf1.ProduceVehicle(new Car());
 
            VehicleFactory vf2 = new VehicleFactory();
            vf2.ProduceVehicle(new Bus());

            Console.ReadLine();
        }
    }
}

 Uygulamamızın Ekran çıktısı

 

Ne güzel araçlarımız ürettik kodumuz tıkır tıkır çalışıyor ve fabrika haftada 300 car-bus üretiyor. Peki patron çıldırdı dedi ki "Arkadaşlar 2 ay sonra kamyon üretmeye başlıyoruz, bütün altyapıyı hazır edin..". Hiç sorun değil nasıl olsa kodumuzu yazdık arabayı otobüsü nasıl ürettiysek kamyonu da öyle üretiriz deyip kamyon için aşağıdaki gibi kodlarımızı modify edip değişiklikleri yapalım.

1- İlk olarak => VehicleType enum'ına Truck diye yeni bir alan eklemeliyiz

 public enum VehicleType
    {
        Car,
        Bus,
        Truck//Truck enum değerini ekledik
    }

 

2- İkinci olarak => Vehicle class'ına Truck objesini oluşturma. Nasıl Car ve Bus için Vehicle'dan inherit olan class lar yazdık aynı şekilde Truck içinde bunu yapıyoruz

namespace BadExample
{
    public class Vehicle
    {
        public VehicleType VType { get; set; }
    }

    public enum VehicleType
    {
        Car,
        Bus,
        Truck
    }

    public class Car : Vehicle
    {
        public Car()
        {
            this.VType = VehicleType.Car;
        }
    }
    public class Bus : Vehicle
    {
        public Bus()
        {
            this.VType = VehicleType.Bus;
        }
    }

    public class Truck : Vehicle//Truck objesini tanımladık 
    {
        public Truck()
        {
            this.VType = VehicleType.Truck;
        }
    }
}

 

3- Üçüncü olarak =>  VehicleFactory class'ına  ProduceTruck class'ını ekleyip ProduceVehicle metoduna Truck için gerekli kontrolleri ekleyeceğiz

using System;

namespace BadExample
{
    public class VehicleFactory
    {
        public void ProduceVehicle(Vehicle vehicle)
        {
            switch (vehicle.VType)
            {
                case VehicleType.Car:
                    ProduceCar((Car)vehicle);
                    break;
                case VehicleType.Bus:
                    ProduceBus((Bus)vehicle);
                    break;
                case VehicleType.Truck://truck üretimi için logic kısmını yazdık
                    ProduceTruck((Truck)vehicle);
                    break;
            }
        }

        private void ProduceCar(Car car)
        {
            Console.WriteLine("Car Produced\n");
        }

        private void ProduceBus(Bus car)
        {
            Console.WriteLine("Bus Produced\n");
        }

        private void ProduceTruck(Truck truck) //truck üretimi yapan metodu ekledik
        {
            Console.WriteLine("Truck Produced\n");
        }
    }
}

 

4- Dördüncü olarak =>  Yazmış olduğumuz kodları kullanma vakti, Main fonksiyonda da Truck üretimi için gerekli metod çağrılarını yapacağız.

namespace BadExample
{
    class Program
    {
        static void Main(string[] args)
        {
            VehicleFactory vf1 = new VehicleFactory();
            vf1.ProduceVehicle(new Car());
            
            VehicleFactory vf2 = new VehicleFactory();
            vf2.ProduceVehicle(new Bus());
            
            VehicleFactory vf3 = new VehicleFactory();
            vf3.ProduceVehicle(new Truck());
            
            Console.ReadLine();
        }
    }
}

Uygulamamızın Ekran çıktısı

 

Kamyonumuzu ürettikkk. Patron mutlu alan mutlu satan mutlu.. Peki ama yeni bir araç yani Kamyon türünde bir Vehicle üretmek için neler yaptık öyle... Elimizi atmadığımız class kalmadı. Bu işlemi tam 4 farklı adımda halledebildik. Bu peki istediğimiz bir şey mi ?.. Ne diyordu Open-Closed prensibi "gelişime açık değişime kapalı" Peki biz ne yaptık; projede ki logic kısmı dahil her yere müdahale edip bir takım değişiklikler yaptık yani prensibe uygun hareket etmedik.

Peki nasıl olması gerekirdi ? Sadece Main fonksiyonunda bir parça kod ekleyip sorunu çözecek halimiz yok tabiki de ancak patron yarın tekrardan gelip "Motorsiklet üretmeye başlıyoruz, Bisiklet üretmeye başlıyoruz.." diye devam etme ihtimaline karşı daha generic ve core koda yani logic'in bulunduğu kod kısımlarına çok fazla dokunmadan bir kaç extended class yazarak yeni üretim işlemine başlıyor olmamız gerekirdi.

 

Better Example

Şimdi gelin Truck üretim işlemimizi biraz daha "Better than the previous example" sloganıyla yazalım 

İlk olarak Vehicle.cs ile başlayalım. Bu sefer Vehicle class'ımız abstract içerisinde bir adet abstract olarak tanımlı Produce() metodu var ve Car, Bus ve Truck objeleri de yine Vehicle class'ını implemente edip ve Produce metodunu kullanacaklar.

using System;

namespace GoodExample.MyFolder
{
    public abstract class Vehicle
    {
        public abstract void Produce();
    }

    public class Car : Vehicle
    {
        public override void Produce()
        {
            Console.WriteLine("Car Produced\n");
        }
    }
    
    public class Bus : Vehicle
    {
        public override void Produce()
        {
            Console.WriteLine("Bus Produced\n");
        }
    }

    public class Truck : Vehicle
    {
        public override void Produce()
        {
            Console.WriteLine("Truck Produced\n");
        }
    }
}

 

VehicleFactory.cs class'ımızda artık hiçbir if/else yada switch/case condition'ı bulunmicak. Bu class ta yine Vehicle tipinde parametre alan ProduceVehicle() adında bir metod olacak ve tek görevi parametre olarak aldığı abstract Vehicle'dan türeyen objeyi alıp Produce() metodunu çağırmak. 

namespace GoodExample.MyFolder
{
    public class VehicleFactory
    {
        public void ProduceVehicle(Vehicle vehicle)
        {
            vehicle.Produce();
        }
    }
}

 

Program.cs'ın diğer örnekte olduğu gibi aynısını kullanıcaz yani üretmek istediğimiz objenin instance'ını alıp üretime başlicaz.

using System;

namespace GoodExample
{
    class Program
    {
        static void Main(string[] args)
        {
            VehicleFactory vf1 = new VehicleFactory();
            vf1.ProduceVehicle(new Car());

            VehicleFactory vf2 = new VehicleFactory();
            vf2.ProduceVehicle(new Bus());

            VehicleFactory vf3 = new VehicleFactory();
            vf3.ProduceVehicle(new Truck());
            
            Console.ReadLine();
        }
    }
}

Uygulamamızın Ekran çıktısı

 

Şimdi içimizden şu soruyu sorabiliriz.. "Eeee noldu şimdi aynı işi yaptık, hedefimiz Truck üretimi yapmaktı Bad Example'da da yaptık Better Example'da da..". Cevabı açık ve net arkadaşlar 

  • Projemizi daha generic hale getirdip hiçbir condition'a bağımlı tutmadık,
  • Abstraction kullanarak projedeki bazı yerleri daha kolay geliştirebilir hale getirdik,
  • Core taraftaki kodu gelişime açık çok büyük köklü değişimlere kapalı hale getirdik,
  • Yeni bir üretim işlemi  başlasın Vehicle objesinden inherit olan class'ımızı olluşturup Produce metodunun içerisini doldurduktan sonra kolayca üretime başlayabilecek hale geldik,
  • Yani kısaca projemizi Open-Closed prensibine uygun hale getirdik

BadExample'da yaptığımız gibi yeni bir araç üretimine başlamak için yapmış olduğumuz o 4-5 farklı değişiklikten kurtulup BetterExample'da olduğu gibi sadece üretilecek olan nesneyi Vehicle objesinden inherit edilmiş şekilde tanımlayıp Main fonksiyonunda Üretim işlemini başlatmak yeterli olacaktır.

Hadi son olarak Motorcycle üretelim.  İlk olarak nesnemizi tanımlıyoruz 

    public class Motorcycle : Vehicle
    {
        public override void Produce()
        {
            Console.WriteLine("Motorcycle Produced\n");
        }
    }

Sonrasında Main fonksiyonunda üretime başla diyoruz

using System;

namespace GoodExample
{
    class Program
    {
        static void Main(string[] args)
        {
            VehicleFactory vf1 = new VehicleFactory();
            vf1.ProduceVehicle(new Motorcycle());


            Console.ReadLine();
        }
    }
}

 

That's it :)