DEV Community: selcuk yildirim

A Fresh Perspective: Pragmatic and Adaptive Approaches to SOLID Principles

selcuk yildirim — Fri, 06 Sep 2024 11:24:16 +0000

Hey team! 🌍

In software development, SOLID principles have long been considered a gold standard for creating clean, maintainable code. However, in practice, rigidly adhering to these principles can sometimes introduce unnecessary complexity and hinder flexibility. Here, we explore each SOLID principle from a different perspective, suggesting alternative approaches that can be more practical and adaptable in modern development contexts.

1. Single Responsibility Principle (SRP) – Rethinking the “Single Responsibility”
The SRP states that every class should have only one responsibility. However, in contemporary software projects, it might not always be practical or efficient to adhere strictly to this rule. For instance, in a web application, a UserService class might need to handle multiple tasks like creating, updating, and deleting users. Sticking rigidly to SRP could lead to the creation of numerous tiny classes, which can increase unnecessary complexity and reduce code maintainability.

Alternative Approach: ‘Contextual Responsibility’

Instead of insisting on a single responsibility for every class, it might be more effective for classes to carry multiple, related responsibilities within a specific domain. For example, a UserManager class could handle all tasks related to user management. This approach keeps the code more understandable and avoids the over-fragmentation of responsibilities while still adhering to the spirit of SRP.

2. Open/Closed Principle (OCP) – The “Open to Extension, Closed to Modification” Paradox

The OCP suggests that software entities should be open for extension but closed for modification. However, this principle can sometimes lead to overly abstract and complex codebases. Creating new classes for every new functionality instead of modifying existing code can make the software harder to understand and lead to unnecessary growth.

Alternative Approach: ‘Evolutionary Development’

Allowing the code to evolve organically as needs change may be more practical in certain cases. Instead of enforcing strict adherence to OCP, developers can modify existing code directly and optimize it when adding new features. This avoids unnecessary abstractions and complexities while keeping the code adaptable to change.

3. Liskov Substitution Principle (LSP) – The “Strict Substitutability” Dilemma

LSP states that derived classes should be substitutable for their base classes. However, in modern software development, strict application of this principle might not always be meaningful. Forcing every subclass to support all the functionalities of its base class can lead to redundant code and unnecessary complexity.

Alternative Approach: ‘Functional Compatibility’

Instead of enforcing complete substitutability, it can be more effective to ensure that subclasses are only compatible with the base class where it makes logical sense. For example, a Penguin subclass under an Animal base class might not need to support a fly method. By focusing on logical compatibility, the code remains more straightforward and easier to maintain.

4. Interface Segregation Principle (ISP) – The “Minimal Interface” Misconception

ISP encourages that classes should only depend on the interfaces they need. However, creating separate interfaces for every small function can make the software harder to read and manage. Excessively granular interfaces can lead to unnecessary fragmentation and complexity.

Alternative Approach: ‘Context-Oriented Interfaces’

Instead of splitting interfaces too finely, a more flexible interpretation of ISP can be applied by grouping related functionalities within context-based interfaces. This reduces the number of interfaces, making the codebase more manageable and readable while maintaining modularity.

5. Dependency Inversion Principle (DIP) – The “Everything Must Be Abstracted” Fallacy

DIP states that high-level modules should not depend on low-level modules, but both should depend on abstractions. However, over-abstracting every dependency can lead to an overly complex code structure, slowing down development and making the code harder to understand.

Alternative Approach: ‘Pragmatic Dependency Management’

Abstractions should only be used where necessary. Instead of abstracting every single dependency, focus on abstracting only critical dependencies that impact the flexibility and sustainability of the software. This approach keeps the code lean and easier to understand by avoiding unnecessary abstractions.

Conclusion: Embracing a New, Flexible Approach to SOLID

While SOLID principles provide valuable guidelines, their rigid application can sometimes increase complexity and reduce flexibility. By adopting a context-aware, pragmatic approach to these principles, developers can create more maintainable and adaptive software. Rethinking SOLID principles in this way ensures that the code remains efficient, sustainable, and aligned with the real-world needs of the project.

“O Olmazcı” Yazılımcılar: Ürün Ekiplerinin Korkulu Rüyası

selcuk yildirim — Tue, 03 Sep 2024 10:50:39 +0000

Hey team! 🌍

Ürün ekibinin müthiş bir fikirle toplantıya girdiği, gözlerinin heyecandan parladığı o anları hatırlıyor musunuz? “Yeni özellikler, kullanıcıyı daha da mutlu edecek geliştirmeler ve büyük bir lansman…” Ama sonra, o olur ya, toplantının köşesinde oturan bir yazılımcı derin bir nefes alır ve “Olmaz…” der. İşte, ürün ekiplerinin kabusu “o olmazcı” yazılımcılar sahnede!

O Olmazcı Kimdir?
“O olmazcı” yazılımcı (derneği kurulsa başkanı olurum 🤪), her projede, her şirkette karşımıza çıkan o yazılımcıdır. Ürün ekibinin ortaya attığı yenilikçi ve heyecan verici her fikre bir “olmaz” diyerek cevap verir. Ama yanlış anlaşılmasın; bu, o yazılımcının huysuz, olumsuz veya tembel olduğundan değil. Aslında, tam tersi: Onlar, bir işin gerçekten yapılabilir olduğundan emin olmak için anında zihninde binlerce satır kodu çalıştıran, muhtemel hata senaryolarını ve performans problemlerini anında görebilen dahilerden biridir! (ben kıllığına yapıyorum 🤪)

Ama maalesef, “olmaz” kelimesi ürün ekibinin moralini yerle bir eder.

Ürün Ekiplerinin Kabusu
Ürün ekiplerinin bakış açısına göre, yazılımcıların “olmaz” demesi, onların heyecanlarını ve yenilikçi ruhlarını baltalayan bir darbe gibidir. “Olmaz” kelimesi, yaratıcı fikirlerin üstüne serilen soğuk bir buz gibi gelebilir. Peki ya bu aslında bir yardım çığlığıysa? Ya yazılımcılar sadece, projelerin son kullanıcıya mükemmel bir şekilde ulaşması için gerekli olan binlerce teknik ayrıntıyı düşünüyorsa?

Bir ürün ekibinin en büyük hayali, fikirlerinin hızla hayata geçirilmesidir. Ancak yazılımcıların karşılaştığı teknik zorluklar, bu süreci yavaşlatabilir. Ürün ekibi “Kullanıcı profilini kişiselleştirelim!” diye önerdiğinde, yazılımcının aklında aniden güvenlik açıkları, performans düşüşleri ve beklenmedik hatalar canlanır.

Yazılımcının Bakış Açısı
Yazılımcılar, hızla çözüm bulmaya ve teknik olarak her detayı düşünmeye odaklanmıştır. Çoğu zaman, çözüm odaklı bir yaklaşımla “olmaz” dediklerinde, aslında “Bu şekilde olmaz ama başka bir yolu olabilir” demek istemektedirler. Ancak, hızlı düşünmek bazen düşündüğün ile anlattığın arasında farklara sebep olabilir. Hızlı düşünme ve anlatma arasındaki bu kopukluk, yanlış anlaşılmalara neden olabilir.

Yazılımcılar genellikle bir problemi hızla analiz eder ve mevcut teknoloji yığını, sistem mimarisi ve kullanıcı gereksinimlerine göre anında bir yargıya varır. Ancak, bu yargının arkasındaki mantığı ifade etmek bazen zor olabilir. “Olmaz” aslında “Bir dakika, bu sorunu en iyi şekilde çözmenin yolunu bulmalıyım” anlamına gelir.

Çözüm: Köprüleri Kurmak
Peki, bu iki ekip arasındaki bu anlaşmazlıkları nasıl çözebiliriz? İşte bazı öneriler:

1.Açık İletişim: Ürün ekipleri ve yazılımcılar birbirlerini anlamak için daha fazla zaman ayırmalı. “Olmaz” kelimesinin ardındaki endişeleri anlamak ve bu endişeleri gidermek için açık bir diyalog kurulmalıdır.
2.Prototipleme ve Hızlı Testler: Bir fikrin uygulanabilir olup olmadığını görmek için küçük prototipler ve hızlı testler yapılabilir. Bu, hem ürün ekiplerinin hem de yazılımcıların fikirlerini görselleştirmesine yardımcı olabilir.
3*.Esprili Yaklaşımlar:* Ekiplerin birbirleriyle olan etkileşimlerini daha keyifli hale getirmek için mizahi bir dil kullanmak, gergin anları hafifletebilir. Örneğin, toplantı odasının duvarında “O olmazcı’nın Günlüğü” köşesi açılabilir ve yazılımcıların “olmaz” deme nedenleri esprili bir dille paylaşılabilir.

Velhasıl Kelam …

Yazılım ekipleri ve ürün ekipleri aslında aynı hedefe doğru ilerleyen iki farklı dünyadır.Kullanıcılara en iyi deneyimi sunmak. Ancak bu yolculukta, farklı düşünme şekilleri ve öncelikler bazen çatışmalara yol açabilir. “O olmazcı” yazılımcılar, aslında projelerin başarıya ulaşması için gerekli olan teknik bilginin ve analitik düşüncenin savunucularıdır. Ürün ekipleri ise kullanıcı odaklı düşünmenin ve yenilikçiliğin temsilcileridir.

İletişim, mizah ve karşılıklı anlayış ile bu iki dünyayı bir araya getirmek mümkün. Unutulmamalıdır ki, “olmaz” her zaman son söz değildir; bazen sadece “biraz daha düşünelim” demektir. Her iki ekip de birbirlerinin perspektiflerini anlamaya çalıştıkça, bu zorlu süreçler daha az stresli, daha eğlenceli ve kesinlikle daha verimli hale gelecektir.

Ve unutmayalım, bir sonraki toplantıda “olmaz” diyen yazılımcıya bir kahve ısmarlamak her zaman işe yarar!

NET 8 and Microservices: New Tools and Techniques to Integrate

selcuk yildirim — Mon, 02 Sep 2024 09:19:10 +0000

Hey team! 🌍

If you've been in the development world for a while, you've likely seen the increasing adoption of microservices architectures. They offer flexibility, scalability, and a more efficient way to build complex applications. Now, with NET 8 on the scene, there are some new tools and techniques that make working with microservices even better. Let's dive into what's new and how you can take advantage of these updates in your next project!

1. Improved gRPC Support for Microservices Communication 📡

One of the biggest challenges with microservices is communication between different services. That’s where gRPC comes in. With NET 8, gRPC support has been significantly enhanced to provide a more reliable and efficient way for services to communicate.

What's New?

Better HTTP/3 Integration : NET 8 offers improved integration with HTTP/3, which is optimized for faster and more secure connections. This makes your microservices more responsive and reduces latency.
Streaming Support: Now, gRPC in NET 8 has better support for real-time streaming, which is perfect for scenarios where services need to exchange data continuously, like real-time analytics or monitoring tools.

Code Example : Setting Up a Basic gRPC Service

Here's a simple example to show you how to set up a basic gRPC service in

using Grpc.Core;
using Microsoft.Extensions.Hosting;

public class Program
{
    public static void Main(string[] args)
    {
        var host = Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            })
            .Build();

        host.Run();
    }
}

public class GreeterService : Greeter.GreeterBase
{
    public override Task<HelloReply> SayHello(HelloRequest request, ServerCallContext context)
    {
        return Task.FromResult(new HelloReply
        {
            Message = "Hello " + request.Name
        });
    }
}

In the above code, we're setting up a basic gRPC server that listens for incoming requests and responds with a simple message. You can see how easy it is to get started with gRPC in .NET 8!

2. Enhanced Distributed Tracing and Observability 🔍

Monitoring and troubleshooting microservices can sometimes feel like finding a needle in a haystack. But NET 8 brings some new features to make this easier.

What's New?

OpenTelemetry Integration : NET 8 has better support for OpenTelemetry, a set of APIs and tools to help you collect and analyze telemetry data from your services. This makes it easier to understand what’s happening in your system in real-time.

Code Example : Setting Up OpenTelemetry in NET 8

To enable OpenTelemetry for distributed tracing in your microservices, you can use the following example:

using Microsoft.Extensions.DependencyInjection;
using OpenTelemetry.Resources;
using OpenTelemetry.Trace;

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddOpenTelemetryTracing(builder => builder
            .SetResourceBuilder(ResourceBuilder.CreateDefault().AddService("MyMicroservice"))
            .AddAspNetCoreInstrumentation()
            .AddHttpClientInstrumentation()
            .AddJaegerExporter());
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        // Standard ASP.NET Core middleware setup...
    }
}

With just a few lines of code, you’ve set up OpenTelemetry in your .NET 8 microservices app, ready to export traces to a Jaeger backend for analysis.

3. Simplified Deployment with Dapr Integration 🚀
Dapr (Distributed Application Runtime) is another tool that makes working with microservices easier. It helps handle state management, service discovery, pub/sub messaging, and more.

What's New?

Improved Dapr Integration : NET 8 offers tighter integration with Dapr, making it easier to add reliable communication patterns, state management, and more to your microservices.

Code Example : Using Dapr with .NET 8

Here’s a basic example of how to use Dapr in a .NET 8 microservice:

public class WeatherService
{
    private readonly DaprClient _daprClient;

    public WeatherService(DaprClient daprClient)
    {
        _daprClient = daprClient;
    }

    public async Task<WeatherForecast> GetForecastAsync(string city)
    {
        var state = await _daprClient.GetStateAsync<WeatherForecast>("statestore", city);
        return state;
    }
}

With this setup, we’re using Dapr to handle state management for a weather forecasting service. It’s simple, efficient, and scales well with your app.

Conclusion 🏁
NET 8 is making microservices development more powerful and easier than ever before. With improved gRPC communication, enhanced observability tools like OpenTelemetry, and better Dapr integration, you’ve got a full toolbox to build reliable and scalable microservices.

By the way, if you noticed any mistakes or if things weren’t clear in this first write-up, my bad! 😅 I’m still learning and always looking to improve. Appreciate your patience, and thanks for sticking with me! Sending love to you all! 💖 Keep coding and keep experimenting – the best is yet to come! 🚀