Clean Architecture bu noktada sadece katmanları ayırmakla kalmaz, sorumlulukları da net bir şekilde ayrıştırmayı hedefler. Command / Query ayrımı ve MediatR Pipeline Behavior’lar bu yaklaşımın pratikte en güçlü uygulamalarından biridir.

Command ve Query Ayrımı Neden Önemlidir?

Sistemde gerçekleştirilen her operasyonun bir niyeti vardır ve bu niyetin kod üzerinden açıkça okunabilmesi büyük önem taşır. Command’lar uygulamanın state’ini değiştirirken, Query’ler yalnızca veri okuma amacıyla çalışır. İlk bakışta basit görünen bu ayrım, proje büyüdükçe kodun anlaşılabilirliğini ve bakım kolaylığını ciddi ölçüde artırır.

Örneğin bir kullanıcı oluşturma işlemi ile kullanıcı detayı getirme işlemi aynı handler’da yer almamalıdır. Çünkü bu iki operasyonun sorumlulukları tamamen farklıdır.

public record CreateUserCommand(string Name, string Email)
    : IRequest<Guid>;

public record GetUserByIdQuery(Guid Id)
    : IRequest<UserDto>;

public record CreateUserCommand(string Name, string Email)
    : IRequest<Guid>;

public record GetUserByIdQuery(Guid Id)
    : IRequest<UserDto>;

Bu yaklaşım sayesinde bir geliştirici sadece class adına bakarak bile ilgili operasyonun veri değiştirip değiştirmediğini anlayabilir.

MediatR ve Pipeline Behavior Mantığı

MediatR, Command ve Query’lerin tek bir merkezden yönetilmesini sağlar. Ancak asıl gücünü Pipeline Behavior yapısıyla gösterir. Pipeline Behavior’lar, handler çalışmadan önce ve sonra araya girerek ortak işlemleri merkezi bir noktadan yönetmemize olanak tanır.

Bu yapı sayesinde validation, logging veya transaction gibi tekrar eden kodları her handler’ın içine yazmak yerine, tek bir yerden kontrol edebiliriz. Böylece handler’lar yalnızca iş kuralına odaklanır.

Validation Pipeline ile Fail-Fast Yaklaşımı

Validation, çoğu projede handler içinde yapılan ve zamanla karmaşıklaşan bir süreçtir. Oysa validation, iş kuralı değil bir ön koşuldur. Bu nedenle handler’a hiç ulaşmadan kontrol edilmelidir.

FluentValidation ile oluşturulan bir Validation Pipeline, gelen request’i önce doğrular. Hata varsa işlem hiç başlamadan durdurulur.

public class ValidationBehavior<TRequest, TResponse>
    : IPipelineBehavior<TRequest, TResponse>
{
    public async Task<TResponse> Handle(
        TRequest request,
        RequestHandlerDelegate<TResponse> next,
        CancellationToken cancellationToken)
    {
        // Validation işlemleri
        return await next();
    }
}

public class ValidationBehavior<TRequest, TResponse>
    : IPipelineBehavior<TRequest, TResponse>
{
    public async Task<TResponse> Handle(
        TRequest request,
        RequestHandlerDelegate<TResponse> next,
        CancellationToken cancellationToken)
    {
        // Validation işlemleri
        return await next();
    }
}

Bu yaklaşımın en büyük faydası, sistemin fail-fast çalışması ve handler’ların gereksiz koddan arındırılmasıdır.

Logging Pipeline ile İzlenebilirlik

Kurumsal uygulamalarda bir işlemin ne zaman, hangi parametrelerle ve kim tarafından tetiklendiğini bilmek kritik öneme sahiptir. Logging Pipeline, her Command veya Query’nin giriş ve çıkış noktalarını merkezi olarak loglamamıza olanak tanır.

_logger.LogInformation(
    "Handling {RequestName} with {@Request}",
    typeof(TRequest).Name,
    request);

_logger.LogInformation(
    "Handling {RequestName} with {@Request}",
    typeof(TRequest).Name,
    request);

Bu sayede:

• Handler’larda log tekrarı olmaz
• Log formatı standartlaşır
• Üretim ortamında hata ayıklamak kolaylaşır

Transaction Pipeline ile Tutarlı Veri Yönetimi

Transaction yönetimi, özellikle veri güncelleyen Command’lar için vazgeçilmezdir. Ancak bu işlemi her handler içinde yapmak, hem hata riskini artırır hem de kodu şişirir.

Transaction Pipeline, yalnızca Command’lar için transaction başlatır ve handler başarıyla tamamlandığında commit eder. Bir hata oluştuğunda ise rollback otomatik olarak devreye girer.

await _dbContext.BeginTransactionAsync();
var response = await next();
await _dbContext.CommitAsync();

await _dbContext.BeginTransactionAsync();
var response = await next();
await _dbContext.CommitAsync();

Bu yapı sayesinde transaction yönetimi tek bir noktadan kontrol edilir ve tutarlılık sağlanır.

Pipeline Sırası Neden Kritik?

Pipeline Behavior’ların sırası, sistemin davranışını doğrudan etkiler. Genellikle önerilen sıra şu şekildedir:

• Validation
• Logging
• Transaction
• Handler

Bu sıralama sayesinde:

• Hatalı request’ler transaction açılmadan elenir
• Log’lar anlamlı ve tutarlı olur
• Performans gereksiz yüklerden korunur

Gerçek Hayatta Ne Kazandırır?

Bu yaklaşım, özellikle uzun süre yaşayan ve sürekli evrilen projelerde büyük avantaj sağlar. Kod okunabilirliği artar, yeni geliştiricilerin projeye adapte olması kolaylaşır ve değişen iş kurallarına daha hızlı yanıt verilebilir.

Clean Architecture, CQRS ve Pipeline Behavior birlikte kullanıldığında, sistem sadece çalışan değil, aynı zamanda yaşayan ve büyüyebilen bir yapıya kavuşur.

The post Clean Architecture’ta Pipeline Behavior Kullanımı appeared first on Halil Durmus.

Neden Kurumsal CRM Projelerinde SOLID Zorunludur?

Kurumsal CRM projelerinde kullanıcı sayısı, entegrasyon hacmi ve iş kuralları sürekli büyür. Bu nedenle SOLID prensipleri sadece “iyi uygulama” değildir; değişen iş kurallarına hızlı adapte olabilmek için zorunlu bir mimari disiplindir. Özellikle öğrenci, mezun, bursiyer ve okul gibi hiyerarşik yapılar SOLID uygulanmadığında hızla yönetilemez hâle gelir.

1) Single Responsibility Principle (SRP)

Bir sınıfın değişmesi için tek bir sebebi olmalı.

Gerçek Senaryo:

Dynamics 365’ten öğrenci bilgisi çekip CRM’e kaydediyoruz. Ama aynı sınıf içinde hem mapping yapılıyor hem de veri kaydediliyor hem de log atılıyor.

❌ Yanlış Tasarım

public class StudentService
{
    public void SyncStudent(D365Student d365)
    {
        // Mapping
        var student = new Student
        {
            Name = d365.FullName,
            School = d365.SchoolName,
            ScholarshipType = d365.ScholarshipType
        };

        // Save
        Database.Save(student);

        // Log
        File.AppendAllText("log.txt", $"{student.Name} synced");
    }
}

public class StudentService
{
    public void SyncStudent(D365Student d365)
    {
        // Mapping
        var student = new Student
        {
            Name = d365.FullName,
            School = d365.SchoolName,
            ScholarshipType = d365.ScholarshipType
        };

        // Save
        Database.Save(student);

        // Log
        File.AppendAllText("log.txt", $"{student.Name} synced");
    }
}

3 ayrı sorumluluk → değiştiğinde sınıf patlar.

✅ Doğru Tasarım (SRP uygulanmış)

public class StudentMapper
{
    public Student Map(D365Student d365) =>
        new Student
        {
            Name = d365.FullName,
            School = d365.SchoolName,
            ScholarshipType = d365.ScholarshipType
        };
}

public class StudentRepository
{
    public void Save(Student student)
    {
        Database.Save(student);
    }
}

public class Logger
{
    public void Log(string message)
    {
        File.AppendAllText("log.txt", message);
    }
}

public class StudentSyncService
{
    private readonly StudentMapper _mapper;
    private readonly StudentRepository _repo;
    private readonly Logger _logger;

    public StudentSyncService(StudentMapper mapper, StudentRepository repo, Logger logger)
    {
        _mapper = mapper;
        _repo = repo;
        _logger = logger;
    }

    public void Sync(D365Student d365)
    {
        var student = _mapper.Map(d365);
        _repo.Save(student);
        _logger.Log($"{student.Name} synced");
    }
}

public class StudentMapper
{
    public Student Map(D365Student d365) =>
        new Student
        {
            Name = d365.FullName,
            School = d365.SchoolName,
            ScholarshipType = d365.ScholarshipType
        };
}

public class StudentRepository
{
    public void Save(Student student)
    {
        Database.Save(student);
    }
}

public class Logger
{
    public void Log(string message)
    {
        File.AppendAllText("log.txt", message);
    }
}

public class StudentSyncService
{
    private readonly StudentMapper _mapper;
    private readonly StudentRepository _repo;
    private readonly Logger _logger;

    public StudentSyncService(StudentMapper mapper, StudentRepository repo, Logger logger)
    {
        _mapper = mapper;
        _repo = repo;
        _logger = logger;
    }

    public void Sync(D365Student d365)
    {
        var student = _mapper.Map(d365);
        _repo.Save(student);
        _logger.Log($"{student.Name} synced");
    }
}

2) Open/Closed Principle (OCP)

“Bir sınıf geliştirmeye açık, değişikliğe kapalı olmalı.”

Gerçek Senaryo:

Okul → fakülte → bölüm gibi hiyerarşik yapılarda farklı kaynaklardan veri geliyor.
Yeni kaynak eklenince servisi değiştirmemek istiyoruz.

❌ Yanlış Tasarım

public class FacultyImporter
{
    public List<Faculty> Import(string sourceType)
    {
        if (sourceType == "D365")
        {
            // Dynamics 365 mapping
        }
        else if (sourceType == "SAP")
        {
            // SAP mapping
        }
        else if (sourceType == "CSV")
        {
            // CSV mapping
        }

        return new List<Faculty>();
    }
}

public class FacultyImporter
{
    public List<Faculty> Import(string sourceType)
    {
        if (sourceType == "D365")
        {
            // Dynamics 365 mapping
        }
        else if (sourceType == "SAP")
        {
            // SAP mapping
        }
        else if (sourceType == "CSV")
        {
            // CSV mapping
        }

        return new List<Faculty>();
    }
}

Her yeni kaynakta else if ekleniyor → OCP ihlali.

✅ Doğru Tasarım: Strategy Pattern ile OCP

public interface IFacultySource
{
    List<Faculty> Import();
}

public class D365FacultySource : IFacultySource
{
    public List<Faculty> Import()
    {
        // Mapping logic
        return new();
    }
}

public class CsvFacultySource : IFacultySource
{
    public List<Faculty> Import()
    {
        // CSV parsing logic
        return new();
    }
}

public class FacultyImporter
{
    private readonly IFacultySource _source;

    public FacultyImporter(IFacultySource source)
    {
        _source = source;
    }

    public List<Faculty> Import() => _source.Import();
}

public interface IFacultySource
{
    List<Faculty> Import();
}

public class D365FacultySource : IFacultySource
{
    public List<Faculty> Import()
    {
        // Mapping logic
        return new();
    }
}

public class CsvFacultySource : IFacultySource
{
    public List<Faculty> Import()
    {
        // CSV parsing logic
        return new();
    }
}

public class FacultyImporter
{
    private readonly IFacultySource _source;

    public FacultyImporter(IFacultySource source)
    {
        _source = source;
    }

    public List<Faculty> Import() => _source.Import();
}

Yeni kaynak → Yeni sınıf ekleyip IFacultySource implement etmek yeterlidir.
Mevcut kod değişmez.

3) Liskov Substitution Principle (LSP)

“Türetilmiş sınıflar, temel sınıfın yerine kullanılabilmelidir.”

Gerçek Senaryo:

CRM’de Kullanıcı Türü hesaplayan bir servisimiz var:

• Lise Öğrencisi
• Üniversite Öğrencisi
• Mezun

Yanlış kalıtım → alt sınıf davranışı bozuyor.

❌ Yanlış Tasarım

public class UserTypeCalculator
{
    public virtual string CalculateType(User user) 
        => "GeneralUser";
}

public class GraduateUserTypeCalculator : UserTypeCalculator
{
    public override string CalculateType(User user)
    {
        throw new Exception("Graduate user cannot be processed here");
    }
}

public class UserTypeCalculator
{
    public virtual string CalculateType(User user) 
        => "GeneralUser";
}

public class GraduateUserTypeCalculator : UserTypeCalculator
{
    public override string CalculateType(User user)
    {
        throw new Exception("Graduate user cannot be processed here");
    }
}

Ana sınıfın beklediği davranış alt sınıfta bozulmuş.

✅ Doğru Tasarım

public interface IUserTypeCalculator
{
    string CalculateType(User user);
}

public class GraduateUserTypeCalculator : IUserTypeCalculator
{
    public string CalculateType(User user) 
        => "Graduate";
}

public class StudentUserTypeCalculator : IUserTypeCalculator
{
    public string CalculateType(User user) 
        => "Student";
}

public interface IUserTypeCalculator
{
    string CalculateType(User user);
}

public class GraduateUserTypeCalculator : IUserTypeCalculator
{
    public string CalculateType(User user) 
        => "Graduate";
}

public class StudentUserTypeCalculator : IUserTypeCalculator
{
    public string CalculateType(User user) 
        => "Student";
}

Artık tüm sınıflar aynı kontratı düzgün şekilde uyguluyor.

4) Interface Segregation Principle (ISP)

“Kullanmadığın metodu içeren interface’i implemente etme.”

Gerçek Senaryo:

CRM’de kullanıcıya SMS, mail veya push bildirim gönderen bir servis var. Ancak bazı entegre sistemler SMS desteklemiyor, bu yüzden tek bir arayüz tüm ihtiyaçları karşılamıyor.

❌ Yanlış Tasarım

public interface INotificationService
{
    void SendEmail();
    void SendSms();
    void SendPush();
}

public class EmailService : INotificationService
{
    public void SendEmail() { }
    public void SendSms() => throw new NotImplementedException();
    public void SendPush() => throw new NotImplementedException();
}

public interface INotificationService
{
    void SendEmail();
    void SendSms();
    void SendPush();
}

public class EmailService : INotificationService
{
    public void SendEmail() { }
    public void SendSms() => throw new NotImplementedException();
    public void SendPush() => throw new NotImplementedException();
}

Kullanmadığımız metotları implement etmek zorunda kalıyoruz → ISP ihlali.

✅ Doğru Tasarım

public interface IEmailNotification
{
    void SendEmail();
}

public interface ISmsNotification
{
    void SendSms();
}

public interface IPushNotification
{
    void SendPush();
}

public class EmailService : IEmailNotification
{
    public void SendEmail() { }
}

public class SmsService : ISmsNotification
{
    public void SendSms() { }
}

public interface IEmailNotification
{
    void SendEmail();
}

public interface ISmsNotification
{
    void SendSms();
}

public interface IPushNotification
{
    void SendPush();
}

public class EmailService : IEmailNotification
{
    public void SendEmail() { }
}

public class SmsService : ISmsNotification
{
    public void SendSms() { }
}

Her servis sadece ihtiyacı olan interface’i implement eder.

5) Dependency Inversion Principle (DIP)

“Üst seviye sınıflar, alt seviye sınıflara değil soyutlamalara bağlı olmalı.”

Gerçek Senaryo:

CRM’e veri kaydeden bir servis var; ancak repository sınıfı doğrudan concrete bir sınıfa bağımlı olduğu için test yazılamıyor. Bu nedenle, yapı hem esnekliğini kaybediyor hem de bağımlılıklar artıyor.

❌ Yanlış Tasarım (Test edilemez yapı)

public class UserService
{
    private readonly UserRepository _repo = new UserRepository();

    public void Save(User user)
    {
        _repo.Save(user);
    }
}

public class UserService
{
    private readonly UserRepository _repo = new UserRepository();

    public void Save(User user)
    {
        _repo.Save(user);
    }
}

Unit test yazılamaz, çünkü yapı doğrudan gerçek database’e bağlıdır; bu yüzden test ortamında izole edilemez.

✅ Doğru Tasarım (Mocklanabilir ve test edilebilir)

public interface IUserRepository
{
    void Save(User user);
}

public class UserRepository : IUserRepository
{
    public void Save(User user)
    {
        // DB logic
    }
}

public class UserService
{
    private readonly IUserRepository _repo;

    public UserService(IUserRepository repo)
    {
        _repo = repo;
    }

    public void Save(User user)
    {
        _repo.Save(user);
    }
}

public interface IUserRepository
{
    void Save(User user);
}

public class UserRepository : IUserRepository
{
    public void Save(User user)
    {
        // DB logic
    }
}

public class UserService
{
    private readonly IUserRepository _repo;

    public UserService(IUserRepository repo)
    {
        _repo = repo;
    }

    public void Save(User user)
    {
        _repo.Save(user);
    }
}

Artık test yazabiliriz:

[Fact]
public void Save_Should_Call_Repository()
{
    var repo = new Mock<IUserRepository>();
    var service = new UserService(repo.Object);

    service.Save(new User());

    repo.Verify(x => x.Save(It.IsAny<User>()), Times.Once);
}

[Fact]
public void Save_Should_Call_Repository()
{
    var repo = new Mock<IUserRepository>();
    var service = new UserService(repo.Object);

    service.Save(new User());

    repo.Verify(x => x.Save(It.IsAny<User>()), Times.Once);
}

SOLID Uygulamasının En Büyük Kazancı

SOLID uygulandığında kod tabanı öngörülebilir hale gelir. Böylece ekip değiştiğinde veya yeni bir modül eklendiğinde mevcut kodu kırma riski minimuma düşer. Entegrasyon projelerinde bu esneklik, değişiklik maliyetini ciddi şekilde azaltır.

Sonuç

SOLID prensipleri çoğu zaman teorik başlıklar gibi görünse de CRM yapıları, mikroservisler, entegrasyonlar ve kurumsal projelerde gerçek sorunları çözen pratik kurallardır:

• SRP → Kod karmaşasını azaltır
• OCP → Yeni özellik eklemeyi güvenli hâle getirir
• LSP → Kalıtım kaynaklı hataları engeller
• ISP → Sınıfları gereksiz bağımlılıklardan kurtarır
• DIP → Test edilebilir, izole edilebilir bir yapı sağlar

Bu örneklerle proje kodlarınızı gözden geçirip daha sürdürülebilir bir mimari oluşturabilirsiniz.

Mini Check-List: Projen SOLID mi?

Bu örnekleri değerlendirirken kendi projenize şu soruları sorabilirsiniz: Bir sınıf tek bir işi mi yapıyor? Yeni bir kaynağı desteklemek için mevcut kodu değiştirmek zorunda kalıyor musunuz? Türeyen sınıflar beklenen davranışı bozuyor mu? Servisler gereksiz metodlara mı bağımlı? Birimi test etmek istediğinizde mock kullanabiliyor musunuz? Bu sorulara “hayır” cevabı verebildiğiniz her alan daha sürdürülebilir bir mimariye yaklaştığınız anlamına gelir.

The post Gerçek CRM Senaryolarıyla SOLID Prensipleri appeared first on Halil Durmus.

1. Garbage Collector (GC) Nedir, Ne Yapar?

.NET’te bellek yönetimi büyük ölçüde Garbage Collector tarafından otomatik olarak yapılır.

GC’nin temel görevleri:

• Heap üzerinde tahsis edilen nesneleri takip etmek
• Artık erişilmeyen (unreachable) nesneleri temizlemek
• Belleği compact ederek fragmentation’ı azaltmak

⚠️ Önemli: GC bir memory leak önleyici değildir. Yanlış referans yönetimi hâlâ bellek sızıntısına yol açabilir.

2. Generation (Gen 0 – Gen 1 – Gen 2) Mantığı

GC, performans için nesneleri yaşam sürelerine göre sınıflandırır.

🔹 Gen 0

• Yeni oluşturulan nesneler
• Çok kısa ömürlüdür
• En sık temizlenen nesildir

var user = new User(); // Gen 0

var user = new User(); // Gen 0

🔹 Gen 1

• Gen 0’dan sağ çıkan nesneler
• Ara geçiş nesilleri

🔹 Gen 2

• Uzun ömürlü nesneler (cache, singleton, static referanslar)
• Temizlemesi pahalıdır

static readonly List<string> _cache = new(); // Gen 2 adayı

static readonly List<string> _cache = new(); // Gen 2 adayı

📌 GC Kuralı:

Çoğu nesne genç ölür → Bu yüzden Gen 0 sık, Gen 2 nadir toplanır.

3. Large Object Heap (LOH)

LOH Nedir?

• 85.000 byte üzerindeki nesneler LOH’a gider
• Gen 2 ile birlikte toplanır
• Varsayılan olarak compact edilmez (fragmentation riski)

byte[] buffer = new byte[100_000]; // LOH

byte[] buffer = new byte[100_000]; // LOH

LOH Problemleri

• Fragmentation
• Uzun GC pause süreleri

4. IDisposable ve Finalizer Mantığı

IDisposable Ne Zaman Gerekli?

Managed olmayan kaynaklar varsa:

• File handle
• DB connection
• Stream
• Socket

public class FileLogger : IDisposable
{
private StreamWriter _writer;


public FileLogger(string path)
{
_writer = new StreamWriter(path);
}


public void Dispose()
{
_writer.Dispose();
}
}

public class FileLogger : IDisposable
{
private StreamWriter _writer;


public FileLogger(string path)
{
_writer = new StreamWriter(path);
}


public void Dispose()
{
_writer.Dispose();
}
}

using Statement

using (var logger = new FileLogger("log.txt"))
{
logger.Log("Hello");
}

using (var logger = new FileLogger("log.txt"))
{
logger.Log("Hello");
}

5. Finalizer ve GC.SuppressFinalize

Finalizer (~ClassName)

~FileLogger()
{
Dispose(false);
}

~FileLogger()
{
Dispose(false);
}

Doğru Disposable Pattern

public class ResourceHolder : IDisposable
{
  private bool _disposed;
  
  public void Dispose()
  {
    Dispose(true);
    GC.SuppressFinalize(this);
  }


  protected virtual void Dispose(bool disposing)
  {
    if (_disposed) return;
    if (disposing)
    {
      // managed resources
    }


    // unmanaged resources
    _disposed = true;
  }
}

public class ResourceHolder : IDisposable
{
  private bool _disposed;
  
  public void Dispose()
  {
    Dispose(true);
    GC.SuppressFinalize(this);
  }


  protected virtual void Dispose(bool disposing)
  {
    if (_disposed) return;
    if (disposing)
    {
      // managed resources
    }


    // unmanaged resources
    _disposed = true;
  }
}

📌 GC.SuppressFinalize çağrılmazsa nesne iki kez GC sürecine girer.

6. Span ve Memory / Modern Bellek Dostu Yapılar

Neden Gerekli?

• Allocation azaltmak
• High-performance senaryolar
• Copy yerine slice mantığı

Span

• Stack üzerinde çalışır
• Heap allocation yapmaz
• Async/await ile kullanılamaz

Span<int> numbers = stackalloc int[5];
numbers[0] = 10;
void Process(Span<byte> buffer)
{
  // slicing
  var header = buffer[..4];
}

Span<int> numbers = stackalloc int[5];
numbers[0] = 10;
void Process(Span<byte> buffer)
{
  // slicing
  var header = buffer[..4];
}

Memory

• Heap üzerinde çalışır
• Async uyumludur
• Daha güvenli ama biraz daha maliyetlidir

Memory<byte> memory = new byte[1024];
await stream.ReadAsync(memory);

Memory<byte> memory = new byte[1024];
await stream.ReadAsync(memory);

Span vs Memory

7. Gerçek Hayat Senaryosu (Web API)

public async Task<IActionResult> Upload(IFormFile file)
{
  using var stream = file.OpenReadStream();
  byte[] buffer = ArrayPool<byte>.Shared.Rent(81920);

  try
  {
    int read;
    while ((read = await stream.ReadAsync(buffer)) > 0)
    {
      // process
    }
  }
  finally
  {
    ArrayPool<byte>.Shared.Return(buffer);
  }
  return Ok();
}

public async Task<IActionResult> Upload(IFormFile file)
{
  using var stream = file.OpenReadStream();
  byte[] buffer = ArrayPool<byte>.Shared.Rent(81920);

  try
  {
    int read;
    while ((read = await stream.ReadAsync(buffer)) > 0)
    {
      // process
    }
  }
  finally
  {
    ArrayPool<byte>.Shared.Return(buffer);
  }
  return Ok();
}

📌 Bu yapı:

• LOH kullanımını azaltır
• GC baskısını düşürür

8. Özet ve Best Practices

• Kısa ömürlü nesneleri Gen 0’da tut
• LOH allocation’larından kaçın
• IDisposable kullanmayı ihmal etme
• Finalizer’ı zorunlu değilse yazma
• High-performance alanlarda Span<T> ve ArrayPool<T> kullan

GC’yi “nasıl çalıştığını bilen” bir geliştirici olmak, kurumsal projelerde seni bir adım öne taşır. Özellikle yüksek trafikli CRM, entegrasyon ve API projelerinde doğru memory yönetimi, performans sorunlarının %80’ini daha oluşmadan engeller.

The post C#’ta Memory Management, GC Nasıl Çalışır? appeared first on Halil Durmus.

Async/Await’in Temeli: IO-bound ile CPU-bound Ayrımını Anlamak

Asenkron programlama denince birçok kişinin aklına hızlanma geliyor. Ancak gerçekte async kod çoğu zaman hız kazandırmaz. Asıl amaç, tıkanmayan thread’leri serbest bırakmaktır. IO-bound işlemler buna iyi bir örnektir. Örneğin ağ istekleri, dosya okumaları veya veritabanı çağrıları bekleme sırasında thread’i meşgul etmez. Bu nedenle await tam bu noktada devreye girer.

Diğer yandan CPU-bound işlemler farklıdır. Uzun hesaplamalar, image processing veya kriptografik operasyonlar tamamen CPU gücüne ihtiyaç duyar. Bu durumda async tek başına fayda sağlamaz. İşlemi Task.Run() ile havuza atmak gerekir. Böylece UI veya request thread’i boş kalır. Bu fark doğru anlaşılmazsa yanlış async kullanımı ortaya çıkar. Sonuç olarak gereksiz overhead ve hatalı mimari kararlar oluşur.

Async/Await ve Deadlock Gerçekleri: ConfigureAwait’in Rolü

En klasik deadlock örneği:

var result = GetDataAsync().Result;

var result = GetDataAsync().Result;

veya

var result = GetDataAsync().GetAwaiter().GetResult();

var result = GetDataAsync().GetAwaiter().GetResult();

Eğer çağrıyı yapan thread (özellikle UI thread veya ASP.NET’in eski SynchronizationContext’leri) senkron bekliyorsa ve async metot result dönerken bağlamına dönmeye çalışıyorsa deadlock oluşur. Bunu önlemenin en güçlü yolu ise hepimizin bildiği ama çoğu zaman “ihmal ettiği” küçük bir detaydır: ConfigureAwait(false).

Bir kütüphane, SDK veya utility sınıfı yazarken çoğunlukla çağıranın context’ine dönmeye ihtiyaç yoktur. Bu nedenle tüm await’lerinize şu eklemeyi yapmanız sizi birçok potansiyel sorunlardan kurtarır:

await SomeIoOperation().ConfigureAwait(false);

await SomeIoOperation().ConfigureAwait(false);

Böylece kodunuz UI veya request context’i gibi bir “tekil thread” geri dönme zorunluluğu olan ortamlara takılmaz. Modern .NET’te ASP.NET Core zaten SynchronizationContext kullanmadığı için deadlock riski azalmış olsa da, library geliştiricileri için ConfigureAwait hâlâ altın değerinde.

Async LINQ Pattern’leri: En Çok Yanlış Anlaşılan Konulardan Biri

LINQ doğası gereği senkron bir API’dir ve async pattern’lerle birebir çalışması çoğu zaman beklenildiği kadar kolay değildir. Örneğin, şu kullanım hatalıdır:

var results = items.Select(async item => await DoWorkAsync(item)).ToList();

var results = items.Select(async item => await DoWorkAsync(item)).ToList();

Bu noktada results bir List<Task<T>> döner, işlerin tamamlanıp tamamlanmadığı belirsizdir. Doğrusu ise genellikle iki aşamalı bir pattern izlemektir:

var tasks = items.Select(item => DoWorkAsync(item));
var results = await Task.WhenAll(tasks);

var tasks = items.Select(item => DoWorkAsync(item));
var results = await Task.WhenAll(tasks);

Hem kontrol sizde olur hem de paralel yürütme avantajı kazanırsınız.
Aynı zamanda EF Core gibi async query destekleyen ortamlarda LINQ ifadelerinin tamamı asenkron olmayabilir. Sorgunun en son ToListAsync() veya FirstOrDefaultAsync() vb. çağrısına kadar deferred execution devam eder. Bu fark, özellikle performans odaklı API’lerde kritik bir noktadır.

BackgroundService ile Async İş Akışları

BackgroundService, .NET uygulamalarında arka plan işler için oldukça ideal bir yapı sunar. Ancak async yapılar burada da dikkat gerektirir. Döngü tabanlı bir servis:

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    while (!stoppingToken.IsCancellationRequested)
    {
        await ProcessJobsAsync(stoppingToken);
        await Task.Delay(TimeSpan.FromSeconds(10), stoppingToken);
    }
}

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    while (!stoppingToken.IsCancellationRequested)
    {
        await ProcessJobsAsync(stoppingToken);
        await Task.Delay(TimeSpan.FromSeconds(10), stoppingToken);
    }
}

Burada dikkat edilmesi gereken iki kritik nokta vardır:
(1) CancellationToken’ın tüm beklemelerde ve IO-bound çağrılarında gerçekten kullanılması.
(2) Servisin kesinlikle fire-and-forget iş döndürmemesi; async void yerine async Task pattern’ine sıkı sıkıya bağlı kalması.

Ayrıca BackgroundService içerisindeki exception’ların swallow edilmesi çok yaygın bir hatadır. Servis çöker, sistem hiçbir şey söylemeden çalışmayı durdurur. Bu nedenle try/catch ile loglama veya global handler kullanımı bir zorunluluktur.

Gerçek Hayatta Async/Await Nasıl Tasarlanmalı?

Bir projede async mimari tasarlanırken kritik olan şey, async’i her yere enjekte etmek değil; ihtiyaç duyulan yere doğru şekilde yerleştirmektir. Servis metotları IO ağırlıklı ise async kullanmak doğru; ancak her fonksiyonu async yapmak, gereksiz Task objeleri üretmek ve thread havuzunu şişirmek, performansı artırmak yerine düşürebilir. Bu yüzden en iyi pratik her zaman hepimizin bildiği ama bazen uygulamaktan kaçındığı küçük bir prensiptir: Async all the way.

Yani bir metot async ise çağıran da async, onun çağıranı da async olmalıdır. Uçta bir UI veya Controller’a gelindiğinde “await” ile işlem sonlandırılır.

Sonuç: Async/Await Sadece Bir Söz Dizimi Değil, Bir Mimaridir

.NET’te async/await, daha hızlı bir uygulama yazmak için değil; daha esnek, ölçeklenebilir ve thread pool’u verimli kullanan bir mimari inşa etmek içindir. Gerçek dünyada kullanılan asenkron kodlar; ConfigureAwait kullanımından arka plan servislerinde exception yönetimine, async LINQ pattern’lerinden IO-bound vs CPU-bound farkına kadar birçok noktada özen gerektirir.

Doğru kullanıldığında async/await hem kodunuzu daha temiz hale getirir hem de yüksek trafik altında dahi uygulamanızın daha stabil çalışmasını sağlar. Yanlış kullanıldığında ise fark edilmesi en zor performans ve concurrency problemlerinin kaynağı olabilir.

The post .NET Async/Await: Deadlock, Performans ve Modern Teknikler appeared first on Halil Durmus.

Code review, yazılım geliştirme döngüsünün ayrılmaz bir parçasıdır ve genellikle versiyon kontrol sistemleri ile entegre bir şekilde yürütülür. Git gibi popüler araçlarda, pull request veya merge request mekanizmaları üzerinden uygulanır.

Code Review’un Amaçları

1. Kod Kalitesini Artırma:
   • Kodun okunabilirliği, sürdürülebilirliği ve standardizasyona uygunluğu kontrol edilir.
   • Kodun tasarım prensiplerine (SOLID, DRY, KISS vb.) uygun olup olmadığı değerlendirilir.
2. Hataları Önleme:
   • Koddaki potansiyel hatalar, performans sorunları veya çakışma problemleri çözülmeden önce tespit edilir.
   • Güvenlik açıkları veya eksiklikler erken aşamada belirlenir.
3. Ekip İçi Bilgi Paylaşımı:
   • Ekip üyeleri arasında bilgi paylaşımı ve işbirliği teşvik edilir.
   • Yeni ekip üyeleri, projeye daha hızlı adapte olur ve mevcut standartları öğrenir.
4. Kod Standartlarını Koruma:
   • Projede belirlenen kodlama standartlarına uyulması sağlanır.
   • Tutarlı bir kod tabanı oluşturulur.

Code Review Neden Yapılır?

1. Hata Yakalama ve Güvenlik
Code review, hataların erken aşamada tespit edilmesine yardımcı olur. Bu, hatanın daha sonra ortaya çıkması durumunda artacak maliyeti önler. Güvenlik açıklarının erken tespiti ise sistemin siber tehditlere karşı dayanıklılığını artırır.

2. Sürdürülebilirlik
Okunabilir ve iyi tasarlanmış kod, uzun vadede projeyi sürdürülebilir kılar. Kod incelemeleri, geliştiricilerin kodu daha iyi yazmasını sağlar.

3. Ekip Dinamikleri ve Gelişim
Bir ekip içinde yapılan kod incelemeleri, ortak bir kodlama dili geliştirilmesine yardımcı olur. Aynı zamanda, geliştiriciler birbirlerinden öğrenme fırsatı bulurlar.

Code Review Nasıl Yapılır?

1. Kodun Anlaşılabilirliğini Kontrol Etmek:
   • Kodun okunabilirliğini değerlendirin. Karmaşık yapıların sadeleştirilmesini önerin.
2. Hata ve Eksiklikleri Belirlemek:
   • Kodun test senaryolarının yeterli olup olmadığını kontrol edin.
   • Kenar durumların uygun bir şekilde ele alınıp alınmadığını inceleyin.
3. Performans ve Optimizasyon:
   • Kodun performansını etkileyecek şekilde iyileştirilebilecek alanları bulun.
4. Standartlara Uyumluluk:
   • Kodlama standartlarına uygunluk denetimi yapın.
5. Yapısal Tutarlılık:
   • Değişikliklerin projenin genel yapısıyla uyumlu olmasına dikkat edin.

Code Review Araçları

• GitHub/GitLab Pull Requests: Kod incelemeleri için yaygın olarak kullanılır.
• Crucible: Atlassian’ın profesyonel bir kod inceleme aracıdır.
• Phabricator: Facebook tarafından geliştirilmiş bir kod inceleme platformudur.
• SonarQube: Kod kalitesini otomatik olarak analiz eden bir araçtır.

Code review, bir yazılım geliştirme ekibinin hem bireysel hem de ekip olarak kaliteyi ve verimliliği artırmasını sağlayan kritik bir süreçtir. Doğru yapılandığında, yalnızca hataları tespit etmekle kalmaz, aynı zamanda daha iyi bir kodlama kültürü oluşturur ve ekip içindeki bilgi birikimini artırır. Bu nedenle, yazılımcıların code review sürecine aktif olarak katılmaları ve bu pratikten maksimum faydayı sağlamaları önemlidir.

Kaynakça: Smartbear, Sonarsource

The post Code Review: Yazılımda Kalite ve İşbirliğinin Anahtarı appeared first on Halil Durmus.

Luhn Algoritması, düşük işlem maliyeti ve basit kullanımıyla sistem performansını düşürmeden veri doğrulama süreçlerine entegre edilebilir. Güvenlik odaklı bir algoritma olmadığı için, sahtecilik önleme gibi durumlarda tek başına yeterli değildir. Bu yazıda, algoritmanın çalışma prensibini, nasıl çalıştığını, bir örnekle nasıl kullanıldığını ve avantajları ve dezavantajlarını ele alacağız.

Luhn Algoritmasının Çalışma Prensibi

Luhn Algoritması, bir dizi sayının (genellikle bir numaranın) doğru olup olmadığını kontrol etmek için tasarlanmıştır. Bu algoritma, şu adımları takip eder:

1. Adım 1: Sayı Dizisinin Hazırlanması
   • Doğrulama yapılacak sayılar sağdan sola doğru değerlendirilir.
   • İlk sayı (en sağdaki) kontrol basamağı olarak ayrılır.
2. Adım 2: Her İkinci Sayıyı Çiftleme
   • Kontrol basamağı hariç diğer tüm sayılar sırayla alınır.
   • Sağdan sola doğru her ikinci sayı ikiyle çarpılır.
3. Adım 3: Çarpım Sonuçlarının Toplanması
   • İkiyle çarpılan sayılarda sonuç tek basamaklıysa aynen alınır; iki basamaklıysa basamaklar toplanır.
4. Adım 4: Tüm Sayıların Toplanması
   • Çiftleme sonrası elde edilen sayılar ve çiftlenmeyen diğer sayılar toplanır.
5. Adım 5: Modulo İşlemi ile Doğrulama
   • Toplamın 10’a bölünmesi sonucu kalan 0 ise numara geçerli sayılır.

Örnek: Kredi Kartı Numarası Doğrulama

Bir kredi kartı numarasının doğruluğunu kontrol etmek için Luhn Algoritmasını uygulayalım. Numara: 4539 1488 0343 6467

1. Kontrol Basamağını Ayırma
   • Kontrol basamağı: 7
   • Geri kalan: 4539 1488 0343 646
2. Her İkinci Sayıyı Çiftleme
   • Sağdan sola: 6, 4, 3, 6, 8, 4, 9, 5
   • Çiftlenenler: 6×2=12, 4×2=8, 3×2=6, 6×2=12, 8×2=16, 4×2=8, 9×2=18, 5×2=10
   • Basamakları Toplama: (1+2) + 8 + 6 + (1+2) + (1+6) + 8 + (1+8) + (1+0) = 34
3. Çiftlenmeyen Sayılar ve Toplam
   • Çiftlenmeyenler: 7, 3, 8, 4, 3, 9, 5
   • Toplam: 7 + 3 + 8 + 4 + 3 + 9 + 5 = 39
4. Toplam
   • 34 + 39 = 73
5. Doğrulama
   • 73 mod 10 = 3 ≠ 0, bu numara geçerli değildir.

// C# program to implement
// Luhn algorithm
using System;
 
class GFG {
     
// Returns true if given 
// card number is valid
static bool checkLuhn(String cardNo)
{
    int nDigits = cardNo.Length;
 
    int nSum = 0;
    bool isSecond = false;
    for (int i = nDigits - 1; i >= 0; i--) 
    {
 
         int d = cardNo[i] - '0';
 
        if (isSecond == true)
            d = d * 2;
 
        // We add two digits to handle
        // cases that make two digits 
        // after doubling
        nSum += d / 10;
        nSum += d % 10;
 
        isSecond = !isSecond;
    }
    return (nSum % 10 == 0);
}
 
    // Driver code
    static public void Main()
    {
        String cardNo = "79927398713";
        if (checkLuhn(cardNo))
            Console.WriteLine("This is a valid card");
        else
            Console.WriteLine("This is not a valid card");
     
    }
}
 

// C# program to implement
// Luhn algorithm
using System;
 
class GFG {
     
// Returns true if given 
// card number is valid
static bool checkLuhn(String cardNo)
{
    int nDigits = cardNo.Length;
 
    int nSum = 0;
    bool isSecond = false;
    for (int i = nDigits - 1; i >= 0; i--) 
    {
 
         int d = cardNo[i] - '0';
 
        if (isSecond == true)
            d = d * 2;
 
        // We add two digits to handle
        // cases that make two digits 
        // after doubling
        nSum += d / 10;
        nSum += d % 10;
 
        isSecond = !isSecond;
    }
    return (nSum % 10 == 0);
}
 
    // Driver code
    static public void Main()
    {
        String cardNo = "79927398713";
        if (checkLuhn(cardNo))
            Console.WriteLine("This is a valid card");
        else
            Console.WriteLine("This is not a valid card");
     
    }
}
 

Çıktı:

This is a valid card

Luhn algoritması, tek basamaklı hataların yanı sıra, bitişik basamaklardaki hemen hemen tüm transpozisyonları da tespit eder. 

Kullanım Alanları

Luhn Algoritması aşağıdaki alanlarda yaygın olarak kullanılır:

• Kredi Kartı ve Banka Kartları: Kart numaralarının doğruluğunu kontrol etmek için.
• IMEI Numaraları: Mobil cihazların uluslararası kimlik doğrulaması için.
• Sosyal Güvenlik Numaraları: Bazı ülkelerde kimlik numaralarının doğruluğunu sağlamak için.
• Online Ödeme Sistemleri: Hatalı numara girişlerini önlemek için.

Avantajları

• Basitlik: Algoritma kolayca anlaşılır ve uygulanabilir.
• Hız: Doğrulama işlemi hızlı bir şekilde gerçekleştirilir.
• Yanlış Veri Girişini Önleme: Hatalı numara girişlerini engelleyerek veri doğruluğunu artırır.
• Kaynak Verimliliği: Düşük işlem gücü gerektirir, bu da küçük cihazlarda bile çalışabilir olmasını sağlar.

Dezavantajları

• Güvenlik Zayıflığı: Algoritma sadece doğrulama için tasarlanmıştır; güvenlik sağlayamaz. Numaranın doğruluğunu kontrol eder ancak numaranın sahte mi yoksa gerçek mi olduğunu anlamaz.
• Basit Hatalar: Algoritma sadece tek bir basamağın yanlış girilmesini ya da iki basamağın yer değiştirilmesini tespit edebilir.

Luhn Algoritması, doğrulama işlemlerinde etkili bir araçtır. Özellikle kimlik numaraları ve kredi kartları gibi verilerin doğruluğunu sağlamada önemli bir rol oynar. Bununla birlikte, güvenlik açısından tek başına yeterli değildir ve daha sofistike güvenlik sistemleriyle desteklenmelidir. Günümüzde bile, hatalı girişleri engellemek için bu algoritma sıklıkla kullanılmaktadır.

Kaynakça:investopedia, medium, academia

The post Luhn Algoritması appeared first on Halil Durmus.

Şifrelerin Temel İşleyişi

Şifreler, kullanıcıların kimlik doğrulamasını sağlamak ve hassas verileri korumak amacıyla kullanılır. İşte şifrelerin temel işleyişi:

Şifre Oluşturma ve Karmaşıklık: Bir hesap oluşturduğunuzda veya mevcut bir hesap için şifre belirlediğinizde, karmaşık karakterlerin (harf, rakam, sembol) kombinasyonlarından oluşan güçlü bir şifre seçmelisiniz. Bu, şifrenizin tahmin edilmesini zorlaştırarak güvenliğinizi artırır.

Hashing İşlemi: Web siteleri, kullanıcıların şifrelerini açık metin olarak saklamak yerine, “hashing” denilen bir işlemi kullanarak şifrelerin güvenliğini sağlar. Hashing, girdi olarak aldığı veriyi (şifre) matematiksel bir algoritmaya tabi tutarak sabit uzunluklu bir çıktı (hash) üretir. Bu çıktı, orijinal veriye geri dönüştürülemez ve tersine mühendislik yapılamaz.

Tuzlama (Salting): Hashing tek başına yeterli değildir çünkü aynı veri her zaman aynı hash değerini üretir. Bu, saldırganların “rainbow table” saldırıları gibi yöntemlerle şifreleri kırmalarına olanak tanır. Bu nedenle, web siteleri her kullanıcının şifresine rastgele bir dize ekleyerek (tuzlama) hash işlemini güçlendirir. Bu şekilde, aynı şifrenin farklı kullanıcılar için farklı hash değerleri üretmesi sağlanır.

Şifrelerin Güvenliği ve Depolanması

Şifrelerin güvenliği, kullanıcı verilerinin yetkisiz erişime karşı korunması için temel bir gerekliliktir. İşte şifrelerin güvenliği ve depolanması hakkında bazı temel kavramlar:

Hash Fonksiyonları: Web siteleri, güvenliği artırmak için özel olarak tasarlanmış hash algoritmaları kullanır. Bu algoritmalar, hesaplamalı olarak maliyetli ve tersine mühendislik yapılması zor olan yapıları içerir. Popüler hash algoritmaları arasında SHA-256, MD5 ve bcrypt bulunur.

Veri Tabanları ve Şifrelenmiş Depolama: Kullanıcı şifreleri, genellikle şifrelenmiş veri tabanlarında saklanır. Bu, şifrelerin yetkisiz erişimden korunmasına yardımcı olur. Şifrelenmiş depolama, verilerin sadece yetkili kişiler tarafından anlaşılabilir hale getirilmesini sağlar.

Şifreler, çevrimiçi güvenliği sağlamak ve kullanıcı verilerini korumak için önemli bir rol oynar. Karmaşık ve tahmin edilmesi zor şifreler oluşturmak, hash işlemi ve tuzlama gibi yöntemlerin kullanılması, kullanıcıların güvenliğini artırır. Web siteleri, kullanıcı şifrelerini güvenli veri tabanlarında şifrelenmiş olarak saklayarak güvenlik önlemlerini artırır. Kullanıcılar da düzenli olarak şifrelerini güncellemeli ve hesap güvenliğine özen göstermelidir.

Güvenli şifreler oluşturmak ve çevrimiçi hesaplarınızı korumak, dijital dünyada güvende kalmanın temel adımlarından biridir.

Online-Tools-Md5

The post Şifrelerin Çalışma Prensibi ve Güvenliği appeared first on Halil Durmus.

Kriptolojide orijinal metne, düz metin (plaintext), şifrelenmiş metne ise şifreli metin (ciphertext) denilmektedir. Düz metnin içeriğini saklamak için şifreleme (encryption) işleminin yapılması gerekmektedir. Bu sayede metnin içindeki bilgi başkalarının anlayamayacağı hale gelmektedir. Şifrelenmiş metni okuyacak olan kişilerin elinde şifreyi çözecek anahtar bulunmalıdır. Bu anahtar sayesinde şifrelenmiş olan metin düz metne çevrilmektedir. Bu işleme şifre çözme (decryption) işlemi denilmektedir. Şekilde şifreleme ve şifre çözme adımları gösterilmiştir.

Kriptoloji, hem şifre bilimini (kriptografi) hem de şifre analizini (kripto analiz) kapsayan matematiksel tekniklerle ifade edilen bir bilim dalıdır. Kriptografinin temel amacında veri güvenliğinin sağlanması için açık verileri gizli verilere dönüştürme işleminin yapılması vardır.

Şifreleme Algoritmaları

Şifreleme ve şifre çözme işlemleri için çeşitli algoritmalar kullanılmaktadır. Bu algoritmalara kriptografik algoritmalar denilmektedir. Kriptografik algoritmalar, şifreleme ve şifre çözme işlemlerini anahtar kullanarak yapmaktadır. Şifreli metin sadece metin şifreleme işlemi için kullanılan anahtar ile çözülebilmektedir. Anahtar kullanan şifreleme algoritmaları simetrik şifreleme (gizli anahtar şifreleme) ve asimetrik şifreleme (açık anahtar şifreleme) algoritmaları olmak üzere ikiye ayrılmaktadır.

1.Simetrik Şifreleme Algoritmaları

Simetrik şifreleme, gizli anahtarlı şifreleme olarak adlandırılmaktadır. Simetrik şifreleme algoritmalarında bilginin şifrelenmesi ve şifrelenmiş bilginin çözülmesi işlemi aynı anahtar kullanılarak gerçekleştirilmektedir. Bu anahtar sadece şifreleme işlemi ve şifre çözme işlemini yapacak olan kişilerde bulunmaktadır. Simetrik şifreleme algoritması açık metni ile gizli anahtarı veri girişi olarak alıp, çıktı olarak şifreli metni üretir. Düz metne erişmek ise sadece gizli anahtarın bilinmesiyle mümkün olmaktadır. Yani
şifreli metni düz metne çevirme işlemi gizli anahtar kullanarak gerçekleştirilmektedir. Simetrik şifreleme algoritması diyagramı verilmiştir.

Birçok simetrik algoritma çeşitleri bulunmaktadır. Bu algoritmalardan bazılarının adı, geliştiricisi ve geliştirme tarih bilgilerine yer verilmiştir.

2.Asimetrik Şifreleme Algoritmaları

Asimetrik şifreleme, açık anahtarlı şifreleme olarak adlandırılmaktadır. Simetrik şifreleme algoritmasından farklı olarak asimetrik şifreleme algoritmasında açık ve özel anahtar olmak üzere iki farklı anahtar bulunmaktadır. Şifreleme anahtarına açık anahtar, şifre çözüm anahtarına ise özel anahtar ismi verilmektedir. Şifre çözme işlemi için kullanılan anahtar ile şifreleme işlemi için kullanılan anahtarlar birbirinden farklıdır. Şifre anahtarının herkese açık olması gerektiğinden bu algoritmalara açık anahtarlı algoritmalar denilmiştir. Bu sebepten dolayı bir kullanıcının açık anahtarı ile şifrelenen bir metin sadece bu kullanıcıya ait olan özel anahtar ile metnin şifresi çözülebilmektedir. Asimetrik şifreleme algoritması diyagramı gösterilmiştir.

Birçok asimetrik şifreleme algoritması bulunmaktadır. Asimetrik şifreleme algoritmalarından bazıları
verilmiştir.

Avantaj ve Dezavantajları

Her iki tip şifrelemenin de diğerine kıyasla avantajları ve dezavantajları bulunur. Simetrik şifreleme algoritmaları çok daha hızlıdır. Daha az hesaplama gücü gerektirir. Fakat bunların başlıca zayıflığı anahtar paylaşımıdır. Bilgiyi şifrelemek ve bilginin şifresini açmak için aynı anahtar kullanıldığından, bu anahtarın veriye erişmesi gereken herhangi bir kişiyle paylaşılması gereklidir. Bu durum da doğal olarak güvenlik riskleri meydana getirir.

Bunun aksine asimetrik şifrelemede şifre paylaşımı sorunu, şifreleme için açık anahtar, şifreyi açmak için de özel anahtar kullanılmasıyla çözülür. Fakat bu durumda da, asimetrik şifreleme sistemleri simetrik sistemlere kıyasla çok yavaş hale gelir ve çok daha uzun anahtarlar nedeniyle daha fazla hesaplama gücünü zorunlu kılar.

Hibrid Sistemler

Birçok uygulamada, simetrik ve asimetrik şifreleme bir arada kullanılır. Bu tip hibrid sistemlerin en tipik örnekleri, internet içinde güvenli iletişim sağlamak üzere tasarlanmış Güvenli Yuva Katmanı (SSL) ve Taşıma Katmanı Güvenliği (TLS) kriptografik protokolleridir. SSL protokolleri artık güvensiz kabul edilirler. Bunların kullanımına devam edilmemelidir. TLS protokolleri güvenli kabul edilirler. Tüm web tarayıcılarında yaygın olarak kullanılırlar. 

Kaynakça: ssl2buy, encryptionconsulting

Kodaz, H., & Botsali, F. M. (2010). Simetrik ve asimetrik şifreleme algoritmalarının karşılaştırılması. Selçuk Teknik Dergisi, 9(1), 10-23

Erkan, H. (2010). ASELSAN Kriptografik Algoritma Tasarım Yetenekleri. Aselsan, 23(81), 26.

The post Kriptoloji Nedir? Şifreleme Algoritmaları appeared first on Halil Durmus.

Graf Nedir?

Bir graf G = (V,E) kümelerinden oluşur. Burada V = {v₁,v₂,…} kümesinin elemanlarına düğüm; E = {e₁,e₂ ,…} kümesinin elemanlarına da kenar adı verilir. Bir e_k kenarı sırasız bir çift (v_i, v_j) ile belirlenir. Sözü edilen v_i ve v_j düğümleri e_k kenarının başlangıç ve bitiş düğümleridir. Grafların en yaygın gösterimi şekilde gösterildiği gibi, düğümlerin birer nokta, kenarların ise kendi başlangıç ve bitiş düğümleri arasında doğru parçaları ile gösterildiği diyagramlardır. Diyagramın kendisi graf olarak olarak adlandırılır.

Bir grafta, herhangi bir e_k kenarı bir (v_i, v_j) düğüm çifti ile eşleşir. Başlangıç ve bitiş düğümleri aynı olan kenar döngü olarak adlandırılır. Şekilde e₇ kenarı bir döngüdür. Başlangıç ve bitiş düğümü aynı olan birden fazla kenar var ise bu kenarlara paralel denir. Şekilde e₂ ve e₃ kenarları paraleldir.

Basit (Simple) Graf

Aynı iki düğümün sadece bir hatla bağlandığı, herhangi bir düğümü yine kendisine bağlayan bir hattın (çevrimin) olmadığı, hatların bir değer almadığı ve yönünün tanımlanmadığı, düğüm ve hatların sınıflandırılmadığı graflara basit graf denir.

Çoklu (Multi) Graf

İki yada daha fazla düğüm arasında birden fazla hat (paralel hatlar) varsa bu tür graflara çoklu (multi) graf denir. Çoklu graflar da yönsüz ve çevrimsizdir. Örneğin iki şehir arasında iki farklı yol varsa, bu durum çoklu grafla temsil edilir.

Dipnot: Basit graflar, çoklu graftir fakat çoklu graflar basit graf degildir.

Pseudo Graf

Çoklu grafların yeterli olmadığı durumlarda kullanılır. Yönsüz, paralel kenarı olan ve döngü içeren graflardır. Yönsüz grafların en temel halidir.

Yönlü Graf

Bir graftaki hatlar yön bilgisine sahipse bu tür graflara yönlü graf (Directed graph) denir. Bu yön bilgisi bağlantının nereden başlayıp nereden bittiğini belirtir. Yön bilgisi olan graflarda düğümler arasındaki bağlantının yönü vardır.

Çoklu Yönlü Graf

İki yönde bağlantı varsa ters yönde iki ayrı hat kullanılır ve bu tür graflara çoklu yönlü graf denir. Graf yapısında bütün kenarlar aynı çeşittir. Yani ya hepsi yönlüdür ya da değildir. Yol ağını temsil eden bir grafta trafiğin tek yada çift yönlü oluşu yönlü graflar için birörnektir.

Grafların Karşılaştırılması

Maaliyetli (Ağırlıklı) Graf

Graf yapısındaki hatlar değer alabilir ve bu değerler grafın yapısına katılabilir. Aşağıdaki örnekte olduğu gibi, bir grafın üzerindeki hatların değerleri eşit değilse ve her biri farklı bir değer alabiliyorsa bu tip graflara maliyetli yada ağırlıklı graf (weighted graph) denir. Bütün hatların değeri aynı ise bu graf maliyetli graf olarak anılamaz. Ağırlıkların bir anlamı yoktur ve her hattın değerinin 1 olduğu basit graf gibi değerlendirilir. Şehirlerin arasındaki mesafelerin hatlara değer olarak atandığı yol haritasını temsil eden graflar maliyetli graflar için örnek verilebilir.

Düzlemsel Graf

Soldaki graf, kesişmeyen hatlardan oluşacak şekilde sağdaki gibi de çizilebilir. Bu şekilde birbirini kesmeyen hatlardan oluşacak şekilde çizilebilen graflara düzlemsel graf denir

Kaynakça: Medium, Freefeast

Data Structures: Introduction To Graphs

The post Graf Teorisi appeared first on Halil Durmus.

1. Düğümler derecelerine göre büyükten küçüğe doğru sıralanır.
2. İlk renk birinci sıradaki düğüme ve bu düğümün komşusu olmayan düğümlere atanır.
3. Bir sonraki renge geçilir ve bu renk sıradaki derecesi en yüksek olan düğüme ve bu düğümün komşusu olmayan düğümlere atanır.
4. Süreç bu şekilde renklendirilmemiş düğüm kalmayana kadar devam ettirilir.

Yukarıdaki algoritmayı aşağıdaki örnek graf üzerinde açıklayacak olursak;

1.İlk renk birinci sıradaki düğüme atanır (en yüksek derecesi olan) ve daha sonra aynı renk birbirlerine bitişik olmayacak biçimde diğer düğümlere verilir.

2.Bir sonraki renge geçilir, bu renk sıradaki derecesi en yüksek olan düğüme atanır; ve sonra bu renk, daha önce renklendirilmemiş düğümlere birbirlerine bitişi olmayacak şekilde atanır.

4.Tüm düğümlere renk verilinceye kadar işlem tekrar edilir.

Uygulama Alanları;

• Harita renklendirme,
• İşlemcilerin işlem sırasını belirleme,
• Ders ve sınav programı ayarlama
• Hava alanlarında iniş ve kalkış sırasını belirleme vs.

Uygulamada, graf renklendirmenin kullanılacağı alanların başında, ilk akla gelen, harita üzerindeki bölgelerin renklendirilmesi olabilir. Graf renklendirme bilgisayar biliminde ve günlük yaşamdaki birçok problemin çözümüne ciddi bir yaklaşımdır. Şimde de günlük hayatımız da kullandığımız graf renklendirme işlemini, çakışmadan sınav oturumlarının belirlenmesi örneğinde inceleyeceğiz.

Problem

Bir üniversitede final sınavları öyle yerleştirilmek istenmektedir ki öğrencilerin farklı derslerine ait sınavları çakışmasın. Üniversitede 4 tane öğrenci ve 6 tane ders vardır ve herhangi bir öğrenci tabi ki aynı anda birden çok ders almaktadır. Bir de elimizde hangi öğrencinin hangi dersleri aldığı liste vardır.

4 tane öğrenci 6 tane ders varsa ilgili kümelerimiz:

D={d0, d1, d2, d3, d4, d5}
Ö={Öğrenci-1, Öğrenci-2, Öğrenci-3, Öğrenci-4}

Her bir öğrencinin aldığı dersler de aşağıdaki gibi olsun:

Öğrenci-1: d0, d1, d4 Öğrenci-2: d0, d2, d4
Öğrenci-3: d2, d3, d5 Öğrenci-4: d3, d4, d5

Soru: Herhangi bir öğrencinin sınavı çakışmayacak şekilde yerleştirme yapılmasına yönelik olarak sınavlar için kaç farklı oturum gerektiği ve aynı anda hangi derslere ait sınavların yapılabileceğini belirleyiniz.

Çözüm:

Bu problem graf renklendirme ile çözülebilir. Dersler graf üzerindeki düğümler olarak kabul edilip öğrencilerin aldığı dersler de düğümler arasındaki hatları belirler. Bu grafın renklendirilmesi sonucu hangi dersin aynı anda yapılabileceği sonucu çıkar; aynı renge ait dersler aynı anda yapılabilir denilir. Kromatik sayı sınavların yapılması için gerekli toplam oturum sayısını verir.

İlk yapılması gereken bu verilerden ilgili grafın ortaya çıkarılmasıdır; derslerin kendileri grafın düğümlerini,
alınan dersler de düğümler arasındaki bağlantıyı belirler.

Graf elde edildikten sonra Welch ve Powel algoritmasına göre düğümler derecelerine göre sıralanır. En yüksek dereceli düğüme ilk renk atanır.

Welch ve Powel algoritmasına göre renklendirilirse aynı renge sahip olan dersler arasında ilişki olmadığı ve sınavların aynı anda yapılabileceği ortaya çıkar.

Dolayısıyla Sonuç

Kromatik sayı 4 çıkmıştır; toplam dört oturum yapılmalıdır. Buna göre d4 dersinin ve d5 dersinin sınavı tek başına ayrı oturumlarda yapılmalıdır; ancak d2 ile d1 veya d0 ile d3 derslerinin sınavları aynı anda yapılabilir.

Soru: Öğrenci-4 d4 dersini almaktan vazgeçip bırakırsa sınav yerleştirimi nasıl olur?

Bu durumda Öğrenci-4’ün alacağı dersler d3 ve d5 olacaktır ve daha önce d4’den dolayı oluşan d3-d4 ve d4-d5 hatları, eğer bu kenarlar başka bir öğrenci tarafından da oluşturulmuyorsa graftan çıkarılacaktır. Bu durumda grafın yeni durumu ve renklendirme aşağıdaki gibi olur.

Görüldüğü gibi kromatik sayı 3 çıkmıştır; bu durumda tüm oturum yeterlidir ve derslere ait sınavları aşağıdaki gibi yapılabilir:

Not:Düzlemsel bir G=(D, K) grafı en fazla 4 renk kullanılarak renklendirilebilir; yani, kromatik sayı 4’tür.

Kaynakça: Geeksforgeeks, Princeton,

Gould, R. (Ed.). Graph Theory. Menlo Park, CA: Benjamin-Cummings, 1988.

Lec 6 | MIT 6.042J Mathematics for Computer Science, Fall 2010 | Video Lecture 

The post Graf Renklendirme (Welsh-Powell Algoritması) appeared first on Halil Durmus.