Merhaba,
Bugün temiz kod hakkında konuşacağız. Gerçekten gerekli mi? Kodlarımız dağınık görünüyorsa gelecekte bizi neler bekliyor? Temiz kod yalnızca, okunması kolay ve basitlik anlamına mı geliyor? Yoksa bundan çok daha fazlası mı?
Her şeyden önce, kimsenin bu kadar zamanı olmadığını biliyorum. Patron projenin sonuçlandırılmasını bekler. Ayrıntıları umursamaz. Kendinizi müşterinin önünde bir kasap olarak düşünebilirsiniz. Patron sizin müşteriniz ve siz kasapsınız. Müşteri hijyeninizi umursamıyor. Sadece etini olabildiğince çabuk almak istiyor. Yani patron her müşteri için ellerini yıkamanı istemiyor. Neden, çünkü zaman(vakit) nakittir. Son olarak, eğer ellerinizi yıkamazsanız ve zamanınızı boşa harcamazsanız (Bu örnekten farklı olarak, her zaman ellerinizi yıkayın, lütfen!), günün sonunda belki siz hariç herkes mutlu olabilirSonuçta, okunması kolay kod ile değiştirilmesi kolay kod arasında bir fark vardır.
- "Büyük" Dave Thomas
Ama gelecekte , müşteriler hasta olabilirler ve şirkete dava açabilirler. En sonunda ,kimse mutlu olmayacak. Patron detayları bilmez. Riskleri sadece sen bilirsin. Bu yüzden tüm sorumluluğu alın ve kodunuzu mümkün olduğunca temiz hazırlayın.Bu makalenin sonunda çok karmaşık AI uygulama kodlarını yeniden değerlendireceğiz. Ama önce, sonunda o karmaşık kodları yeniden düzenlemek için kullanacağımız bu üç tasarım deseni stratejisini anlamamız gerekiyor. Belki çoğunuz bunları zaten biliyorsunuzdur ama güzel bir şeyi tekrar etmenin zararı olmaz
Kısacası sonraki iki tasarım deseni sizi son örneğe hazırlayacaktır. Ve bu dağınık AI uygulamasında sonuncusunu derinlemesine inceleyeceğiz. Tıpkı iş eğitiminde olduğu gibi Tekrarlanabilir kodlardan kaçınmalısınız…
Tek Sorumluluk prensibi. Bir sınıfı değişmek için bir ve yalnızca bir nedeni olmalıdır. Neden, çünkü kolay okunabilmesi, kolayca test edilmesi ve basitlik için. Şu koda bakın; her mantığın kendi işi vardır. CRM, Finans ve Servis. Yazılım Hepsi Bir Arada Kampanya değildir. Dağıtılmış bir süreçtir. CRM sürecini değiştirmek isterseniz, bu sınıfta kullanılan tüm uygulamalar bu güncellemeden etkilenir. Ve bir iş değişikliği için diğer tüm süreçleri yeniden inşa etmeniz gerekir. Bu, “CRM” sürecinin değişmesi için “Finans” ve “Hizmet”in durdurulması gerektiği anlamına gelir. Enum kullanmak bu koddaki tek iyi şeyAşağıdaki C# Konsol Uygulaması kodunda çoklu iş mantığını görebilirsiniz. Bu, S.O.L.I.D.’in ilk kuralına aykırıdır.
Bu koddaki diğer kötü kokuyu hissedebiliyor musun?
Gelecekte, bir işleme daha ihtiyacınız olursa, bu sınıfı bulmalı ve başka bir “if koşulu” eklemelisiniz. Bu çılgınca ve sürdürülebilir değil. Bu sınıfa on yeni mantık daha gelirse, kod okunamaz hale gelir.
Kod: Tümünü seç
using System;
namespace SolidStrategy
{
public enum ProcessType
{
Finance,
Service,
Crm
}
class Program
{
static void Main(string[] args)
{
ProcessCalculation(ProcessType.Crm);
}
public static void ProcessCalculation(ProcessType type)
{
try
{
if (type == ProcessType.Crm)
{
CallCrm("Update Crm DB");
}
else if (type == ProcessType.Finance)
{
CallFinance("Send Mail to Customers");
}
else if (type == ProcessType.Service)
{
CallService("Backup all Data");
}
}
catch
{
}
}
public static void CallCrm(string message)
{
Console.WriteLine($"Process Crm! :{message}");
}
public static void CallFinance(string message)
{
Console.WriteLine($"Process Finance! :{message}");
}
public static void CallService(string message)
{
Console.WriteLine($"Process Service! :{message}"); }
}
}
}Öncelikle tüm işlemleri farklı sınıflara ayıralım. Ve tüm sınıflar başka bir sınıftan veya ara yüzden miras alınmalıdır. Çıplak sınıf, nesne yönelimli programlamada istenmeyen bir şeydir.
IBussineLogic :
Tüm iş mantığı aynı ara birimden (IBussinesLogic) devralınmalıdır. Ve tüm sınıflar aynı “WorkProcess()” yöntemini geçersiz kılmalıdır. Bu Tasarım Modelini hatırlıyor musunuz?
Kod: Tümünü seç
using System;
namespace SolidStrategy
{
public interface IBussinesLogic
{
void WorkProcess(string message);
}
}İlk işletme sınıfı CRM'dir. “IBusinessLogic”ten miras alınır. Bu nedenle “WorkProcess()” yöntemi uygulanmalıdır. Her “WorkProcess()” yöntemi, farklı üst sınıfa aittir. Yani hepsinin mantığı farklı.
Crm Sınıfı :
Kod: Tümünü seç
using System;
namespace SolidStrategy
{
public class Crm : IBussinesLogic
{
public void WorkProcess(string message)
{
Console.WriteLine($"Process Crm! :{message}");
}
}
}Finance:
İkinci işletme sınıfı Finanstır. CRM gibi “IBusinessLogic”ten miras alınır. Ayrıca farklı Finansal mantık için “WorkProcess()” yöntemini uygulamak zorundadır.
Kod: Tümünü seç
using System;
namespace SolidStrategy
{
public class Finance : IBussinesLogic
{
public void WorkProcess(string message)
{
Console.WriteLine($"Process Finance! :{message}");
}
}
}(Service)Hizmet:
Son işletme sınıfı Hizmet'tir. Diğer işletme sınıfları gibi, “IBusinessLogic”ten miras alınır. Ayrıca, farklı Servis mantığı için “WorkProcess()” yöntemini uygulamak zorundadır.
Kod: Tümünü seç
using System;
namespace SolidStrategy
{
public class Service : IBussinesLogic
{
public void WorkProcess(string message)
{
Console.WriteLine($"Process Service! :{message}");
}
}
}Şimdi tüm iş mantığını tek bir kapsayıcı da ele almamız gerekiyor. Neden; çünkü müşteriler bu durumda, aslında diğer geliştiriciler yalnızca bir sınıfla ilgilenmelidir. Çünkü sadelik her şeydir. “Ve şehre yeni bir iş mantığı gelirse, hiç kimse bu ana Süreç kodunu değiştirmek zorunda kalmamalı”
Tüm sınıfların ortak özelliği nedir?Process sınıfı, Constructor() içindeki "IBussinesLogic" öğesinden devralınan bir mantık sınıfı gerektirir.
Tabii ki “WorkProcess()” yöntemi. Process sınıfından “WorkProcess()” yöntemi çağrıldığında, Constructor'dan alınan “IBussinesLogic” sınıfına bağlı olarak mantık farklılık gösterir.
Kod: Tümünü seç
using System;
namespace SolidStrategy
{
public class Process
{
IBussinesLogic _bussines = null;
public Process(IBussinesLogic bussines)
=> _bussines = bussines;
public void WorkProcess(string message)
{
_bussines.WorkProcess(message);
}
}
}
