Coder Legion - Recent posts tagged solid

The Indispensable Practice of Abstraction: Decoupling Your Frontend Logic from External Libraries

Mon, 20 Oct 2025 11:14:55 +0000

In modern frontend architecture, the principle of separation of concerns is paramount. Your application's core logic (business rules, state, and UI) must be entirely isolated from the specific Application Programming Interfaces (APIs) of third-party libraries. This best practice, known as creating an Anti-Corruption Layer (ACL), is the difference between a flexible, maintainable codebase and a fragile, tightly coupled one.

The Problem: Tight Coupling and Vendor Lock-in

When you directly integrate a library's specific methods into your components, you create a dependency that is rigid and difficult to change. For instance, directly using window.Stripe.redirectToCheckout() in a checkout button component couples your UI directly to the Stripe SDK.

The Core Risks:

Vendor Lock-in: You are locked into a specific vendor (e.g., Supabase, Auth0, Stripe). If a better, cheaper, or more performant alternative emerges, changing libraries means a massive, error-prone refactor across your entire application.
Difficult Testing: Unit testing a component that directly calls an external SDK requires complex mocking of that entire library's API, cluttering your test setup.
Inconsistent Code: Error handling, data formatting, and asynchronous logic become inconsistent when repeated across many components.

The Solution: The Abstraction Layer

The solution is an intermediate layer—a Service, Repository, or Utility module—that acts as the single point of entry for all library interactions.

How Abstraction Works:

Generic Interface: Define functions using domain language (e.g., getProducts, processPayment) that describe what your app needs to do, not how it's done.
Encapsulation: All library-specific imports and calls are encapsulated within this single module.
Standardization: The layer is responsible for translating the external library's quirky response formats and error structures into the simple, predictable formats your application expects.

1. Abstracting Data Access (The Repository Pattern)

This is the most critical area for separation. We separate the database library (like Supabase) from the code itself by creating a Service or Repository layer with generic names.

Example: Decoupling Data Fetching (Supabase vs. Custom REST API)

Let's assume our application needs to fetch product data.

Tightly Coupled (Bad)

// src/components/ProductList.jsx

import { supabase } from '../lib/supabaseClient'; // Directly importing the library

const fetchProducts = async () => {
  // Hard dependency on Supabase API structure (from, select, etc.)
  const { data: products, error } = await supabase.from('products').select(`
    id,
    name,
    price_cents,
    inventory:product_inventory(stock_count)
  `);

  if (error) throw new Error(error.message);

  // Data requires complex, specific formatting here
  return products.map(p => ({
      ...p,
      price: p.price_cents / 100,
      stock: p.inventory[0]?.stock_count || 0
  }));
};

Decoupled (Good) with a Service

First, the abstraction layer handles the library call and data standardization:

// src/services/productService.js (The Abstraction Layer)

import { supabase } from '../lib/supabaseClient'; // Encapsulates the library dependency

// Defines a predictable structure for the rest of the application
const formatProduct = (productData) => ({
    id: productData.id,
    name: productData.name,
    price: productData.price_cents / 100, // Standardize cents to dollars
    stock: productData.product_inventory[0]?.stock_count || 0,
});

export const productService = {
  // Generic function name: getProducts
  getProducts: async () => {
    // 1. Library-specific call is confined here
    const { data, error } = await supabase.from('products').select(`
      id,
      name,
      price_cents,
      product_inventory(stock_count)
    `);

    if (error) {
      // 2. Standardize error handling
      throw new Error("Failed to retrieve products from data source.");
    }
    // 3. Standardize and return clean, formatted data
    return data.map(formatProduct);
  },
};

Second, the component uses the clean interface:

// src/components/ProductList.jsx

import { productService } from '../services/productService'; // Generic interface

const fetchProducts = async () => {
  // Clean, generic call. The component doesn't know (or care) about Supabase
  const products = await productService.getProducts();
  // ... use products
};

The Flexibility: If you replace Supabase with a custom REST API using Axios, you only change productService.js. The component code remains untouched.

// src/services/productService.js (Rewritten for Custom REST API via Axios)

import axios from 'axios'; // Encapsulates the new dependency

// formatProduct function remains the same!

export const productService = {
  getProducts: async () => {
    try {
      // New library-specific call
      const response = await axios.get('/api/v1/products');
      // Assume the API returns raw data that still needs to be formatted
      return response.data.map(formatProduct);
    } catch (error) {
      throw new Error("Failed to retrieve products from REST API.");
    }
  },
};

2. Abstraction for All External Dependencies

This principle should be applied to every external dependency to ensure your application is future-proof and agile when a library becomes obsolete or unsuitable.

A. Payment SDKs (e.g., Stripe)

Your checkout flow must be protected from library changes.

Component's Need	Tightly Coupled (Bad)	Decoupled (Good)
Payment: Redirect to checkout screen.	Component calls: `window.Stripe.redirectToCheckout({ /... config / })`	Component calls: `paymentService.initiateCheckout(cartId)`
Abstraction Layer:	None	`paymentService.js` handles all Stripe SDK imports, configurations, and API calls.
Flexibility:	Switching to PayPal or Square requires modifying every component that touches payment.	Only `paymentService.js` needs to be rewritten. The `initiateCheckout` function signature is preserved.

B. Internationalization (i18n) Libraries (e.g., FormatJS vs. react-i18next)

Components should only request a translated string using a generic key.

Component's Need	Tightly Coupled (Bad)	Decoupled (Good)
Translation: Get a welcome message.	Component uses: `const { formatMessage } = useIntl(); return formatMessage(messages.welcome)` (FormatJS-specific)	Component uses: `const { T } = useAppTranslation(); return T('welcome_message', { name: user.name })`
Abstraction Layer:	None	`useAppTranslation.js` wraps the specific library's translation hook/functionality.
Flexibility:	Switching to a different i18n library means changing hook imports and function names in every component.	Only the implementation inside `useAppTranslation.js` changes, maintaining the generic `T` interface.

C. Client-Side Authentication (e.g., Auth0 vs. Firebase Auth)

Decoupling auth ensures your routing and UI logic are stable regardless of the provider.

Component's Need	Tightly Coupled (Bad)	Decoupled (Good)
Auth Status: Check if a user is logged in.	Router guard calls: `Auth0Client.isAuthenticated()`	Router guard calls: `authService.isLoggedIn()`
Abstraction Layer:	None	`authService.js` or `useAuth` hook handles token storage, session checks, and specific library methods.
Flexibility:	If you migrate from Auth0 to Firebase Auth, you need to update logic everywhere Auth0's specific methods are called.	Only `authService.js` is rewritten to use Firebase SDK methods, keeping the generic interface intact.

Key Takeaways for Robust Frontend Architecture

Practice	Principle	Rationale
Name Generically	Domain Language Over Technology: Use names like `userService` or `paymentService`, not `clerkAuthService` or `supabasePosts`.	The name reflects the domain concept, not the implementation detail.
Standardize Data	ACL Responsibility: The service layer must convert the library's output (e.g., a complex object with metadata) into the exact clean object your app needs.	The rest of your application code deals with a single, predictable data format.
Error Handling	Translate Errors: Catch library-specific errors and re-throw them as simple, standardized application-level errors (e.g., a `DataFetchError`).	Components only need to handle a few generic error types, simplifying UI feedback.
Apply Universally	Systematic Abstraction: If you use a library, abstract it. This applies to data access, state management, auth, analytics, utility functions, and more.	Maximizes code agility, testability, and reduces maintenance complexity across the board.

By committing to this principle of universal abstraction, you build a frontend application that is architecturally sound, easier to test, and perfectly positioned to adapt to the technological shifts of tomorrow.

SOLID for Rails Developers, real-life tour (with code)

Thu, 16 Oct 2025 09:47:21 +0000

You’ve heard “keep controllers skinny, models thin” but how? The SOLID principles are a compact set of habits that keep Rails apps change-friendly as they grow. Here’s a practical, with bite-size Rails examples you can use today.

What is SOLID?

Before we jump into code, let’s meet the SOLID squad five principles that save your codebase from chaos, confusion, and late-night debugging sessions.

S ingle Responsibility Principle (SRP): Every class should have one job. Not two. Not three. Just one.
O pen/Closed Principle (OCP): Your code should be open for extension, but closed for modification.
L iskov Substitution Principle (LSP): If your code says it’s a duck, it should quack like a duck.
I nterface Segregation Principle (ISP): Don’t force your classes to implement methods they don’t need.
D ependency Inversion Principle (DIP): Depend on abstractions, not concrete things.

Ready to SOLIDify your Rails code? Let’s go!

A running scenario

Imagine a small trading API for “Tomato” prices:

We fetch intraday PriceTicks.
We compute the best daily gain (buy low, sell high once).
We expose endpoints for analytics.

We’ll use this scenario to illustrate each principle.

S Single Responsibility Principle (SRP)

A class should have one reason to change.

Bad (a God Controller)

class AnalyticsController < ApplicationController
  def show
    date = Date.iso8601(params[:date])
    ticks = PriceTick.where(time: date.all_day).order(:time)
    # validation, parsing, domain logic, formatting… all here 
    min = ticks.first.value_cents
    best = 0
    ticks.drop(1).each do |t|
      best = [best, t.value_cents - min].max
      min = [min, t.value_cents].min
    end
    render json: { date: date, best_gain_cents: best * 100 }
  end
end

Good (split responsibilities)

Query loads just what’s needed
Service computes the gain
Controller orchestrates and renders

app/services/best_gain_calculator.rb:

class BestGainCalculator
  def self.call(ticks, quantity: 100)
    enum = ticks.each
    first = enum.next rescue (return 0)
    min   = first.value_cents
    best  = 0
    enum.each do |t|
      diff = t.value_cents - min
      best = diff if diff > best
      min  = t.value_cents if t.value_cents < min
    end
    best * quantity
  end
end

app/queries/price_ticks_on_day.rb:

class PriceTicksOnDay
  def self.call(date)
    PriceTick.where(time: date.all_day).select(:time, :value_cents).order(:time)
  end
end

app/controllers/api/v1/best_gains_controller.rb

class Api::V1::BestGainsController < ApplicationController
  def show
    ticks = PriceTicksOnDay.call(date)
    render json: { best_gain_cents: BestGainCalculator.call(ticks) }
  end
end

Win: Each class changes for exactly one reason.

O Open/Closed Principle (OCP)

Open for extension, closed for modification. Add behaviors without rewriting stable code.

Real life: new gain strategies without editing the controller

app/services/gain_strategies/base.rb:

module GainStrategies
  class Base
    def call(ticks) = raise NotImplementedError
  end
end

app/services/gain_strategies/single_trade.rb

module GainStrategies
  class SingleTrade < Base
    def call(ticks) = BestGainCalculator.call(ticks)
  end
end

app/services/gain_strategies/multi_trade.rb

module GainStrategies
  class MultiTrade < Base
    def call(ticks)
      # example: sum of all positive deltas
      prev = nil
      profit = 0
      ticks.each do |t|
        if prev
          delta = t.value_cents - prev
          profit += delta if delta.positive?
        end
        prev = t.value_cents
      end
      profit * 100 # quantity stub
    end
  end
end

app/controllers/api/v1/best_gains_controller.rb:

def show
  ticks = PriceTicksOnDay.call(date)

  strategy = params[:mode] == "multi" ? GainStrategies::MultiTrade.new : GainStrategies::SingleTrade.new
  render json: { best_gain_cents: strategy.call(ticks) }
end

Win: Adding WeekOverWeek or TrailingStop strategies doesn’t touch controller code.

L Liskov Substitution Principle (LSP)

Subtypes must be usable wherever their base type is expected.

Real life: STI pitfalls vs composition

If you have PriceTick and you try STI for FxPriceTick < PriceTick but change value_cents semantics (e.g., store pips), substituting FxPriceTick where PriceTick is expected will break calculations.

Better: keep interface and units consistent, or compose.

class PriceTick < ApplicationRecord
  # always expose value in cents
  def value_cents
    super # guaranteed integer cents
  end
end

class FxPriceValue
  def initialize(pips:, pip_value_cents:)
    @pips = pips
    @pip_value_cents = pip_value_cents
  end

  def to_cents = @pips * @pip_value_cents
end

Win: Anything expecting value_cents continues to work.

I Interface Segregation Principle (ISP)

Prefer small, focused interfaces over fat ones. Consumers shouldn’t depend on what they don’t use.

Real life: split service interfaces

Bad:

class ReportService
  def generate_csv_for_day(date); end
  def generate_pdf_for_week(date); end
  def email_pdf_to(user); end
  def email_csv_to(user); end
end

Good:

class CsvReport
  def call(date); end
end

class PdfReport
  def call(week); end
end

class ReportMailer
  def send_pdf(user, pdf); end
  def send_csv(user, csv); end
end

Win: Each client depends on only what it needs; easier to test and swap.

In Rails, ISP often means small POROs instead of piling methods into one “service class.”

D Dependency Inversion Principle (DIP)

Depend on abstractions, not concrete classes.

Real life: inject gateways (HTTP, cache, payments)

app/services/price_sync.rb:

class PriceSync
  def initialize(client: External::PricesClient.new, cache: Rails.cache)
    @client = client
    @cache  = cache
  end

  def call(date)
    @cache.fetch("prices:#{date}", expires_in: 10.minutes) do
      @client.fetch_for(date) # abstraction: responds to `fetch_for`
    end
  end
end

In tests:

fake = Class.new { def fetch_for(date) = [{ time: Time.now, value_cents: 10000 }] }.new
result = PriceSync.new(client: fake, cache: ActiveSupport::Cache::MemoryStore.new).call(Date.today)

Win: Swap implementations without changing business logic. Fewer brittle tests.

Pulling it together: a tiny SOLID checklist

SRP: Does this class change for exactly one reason?
OCP: Can I add a variation without editing existing classes?
LSP: Will any subtype respect the expected inputs/outputs/units?
ISP: Is this interface minimal for its consumer?
DIP: Are external details injected (e.g., clients, storage, time)?

A realistic, SOLID endpoint (end-to-end)

app/controllers/api/v1/best_gains_controller.rb

class Api::V1::BestGainsController < ApplicationController
  def show
    ticks = PriceTicksOnDay.call(date)
    strategy = strategy_for(params[:mode])
    best = strategy.call(ticks)
    return render json: { error: "no valid trades" }, status: :unprocessable_entity if best <= 0
    render json: { date: date, best_gain_cents: best }
  end

  private

  def strategy_for(mode)
    mode == "multi" ? GainStrategies::MultiTrade.new : GainStrategies::SingleTrade.new
  end
end

Everything above respects SOLID:

The controller just orchestrates.
Strategies extend behavior (OCP).
Calculators keep contracts consistent (LSP).
Tiny interfaces (ISP).
Dependencies injected (DIP).

Final thought

Rails gives you speed; SOLID gives you sustainable speed. Start small: extract one PORO today (calculator or query), inject one dependency, and keep your interfaces tiny. Your future self and your teammates will thank you.

Bonus: If SOLID were a superhero team...

SRP: Captain Focus only fights one villain at a time.
OCP: The Extender always ready for new powers, never rewrites their origin story.
LSP: Duckman if it walks like a duck and quacks like a duck, it’s Duckman!
ISP: The Minimalist only carries what’s needed for the mission.
DIP: The Abstractionist never depends on sidekicks, only on the idea of sidekicks.

Now go forth and SOLIDify your Rails app and remember, with great principles comes great maintainability!

Koin vs Dagger 2 vs Hilt: Which should we use?

Wed, 23 Apr 2025 04:26:52 +0000

Have you ever heard about Dependency Injection? If you haven’t heard it before, let’s break down Dependency Injection (DI) in the simplest way possible.

Imagine you’re building a coffee machine. Instead of the machine creating its own coffee beans and water, you provide them from the outside. This way, you can easily swap out different types of beans or water sources without rebuilding the entire machine.

In coding, Dependency Injection (DI) works the same way. Instead of a class creating its own dependencies, they’re injected from the outside. This makes your code more flexible, testable, and easier to manage. Android frameworks like Dagger 2, Hilt, and Koin help automate this process, so you don’t have to manually pass everything around.

These three are popular DI frameworks used in Android development. They help manage object creation and dependency resolution, making code cleaner, more modular, and easier to maintain. Let’s deep dive into among of these three and compare them by performance, usability, and community support.

Performance

When comparing Koin, Dagger 2, and Hilt for dependency injection in Android development, performance plays a crucial role. Dagger 2 is a compile-time dependency injection framework, meaning it generates code at build time, leading to optimal runtime performance with minimal overhead. Hilt, built on top of Dagger 2, maintains the same compile-time benefits while simplifying its setup. Koin, on the other hand, is a runtime dependency injection framework that uses reflection and service locators, making it slightly slower than Dagger 2 and Hilt, especially in large-scale applications. While the difference may not be significant for smaller apps, it can impact performance in more complex dependency graphs.

Let say we demonstrate a “hello world” app using among of them and this is the result:

from the illustration above we can conclude:

Koin: Koin’s compile-time is the fastest because it primarily relies on Kotlin’s reflection and doesn’t involve extensive code generation.
Dagger 2: Dagger 2’s compile-time is significantly longer due to the code generation process, even for a simple app.
Hilt: Hilt, being built on Dagger 2, also involves code generation, but it’s often more optimized for Android and might have slightly faster compile times than raw Dagger 2 in a very small project.

Usability

In terms of usability, Koin is the easiest to implement, requiring minimal boilerplate code with a simple DSL for defining dependencies. Dagger 2 is more complex due to its annotation-based approach, requiring knowledge of components, modules, and generated code. Hilt simplifies Dagger 2’s complexity by introducing annotations like @HiltAndroidApp and @Inject, making dependency injection easier to manage while still leveraging compile-time validation.

Community Support and Documentation

Regarding community support and documentation, Dagger 2 has been widely adopted in the Android ecosystem for years and has extensive documentation. Hilt, as an official AndroidX library, benefits from strong Google backing and comprehensive guides. Koin, while popular among Kotlin developers, has a smaller but growing community. Its documentation is clear but not as extensive as Google’s offerings. Ultimately, Dagger 2 and Hilt are preferred for performance-sensitive and large-scale projects, while Koin is an excellent choice for developers seeking simplicity and faster integration.

Below are example implementations of Koin, Dagger 2, and Hilt:

Koin Implementation

// Define a module
val appModule = module {
    single { UserRepository() }
}

// Start Koin
class MyApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        startKoin {
            modules(appModule)
        }
    }
}

// Inject dependency
class MyViewModel(private val repository: UserRepository)

Dagger 2 Implementation

// Define a module
@Module
class AppModule {
    @Provides
    fun provideUserRepository(): UserRepository {
        return UserRepository()
    }
}

// Define a component
@Component(modules = [AppModule::class])
interface AppComponent {
    fun inject(activity: MainActivity)
}

// Inject dependency
class MainActivity : AppCompatActivity() {
    @Inject lateinit var repository: UserRepository
}

Hilt Implementation

// Define a module
@InstallIn(SingletonComponent::class)
@Module
object AppModule {
    @Provides
    fun provideUserRepository(): UserRepository {
        return UserRepository()
    }
}

// Inject dependency
@HiltAndroidApp
class MyApplication : Application()

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
    @Inject lateinit var repository: UserRepository
}

Choose wisely what framework you want to use, these trio have pros and cons. You can choose and implement it based on your need. Happy coding :)

If you want to know more about Koin framework setup, refer this

Documentation:
Dagger2,
Hilt,
Koin

Koin vs Hilt

Sun, 16 Mar 2025 07:37:25 +0000

In object-oriented programming (OOP), especially in Android Development, to make our program code cleaner and maintainable, one of the principles we are used to apply is SOLID. one of the points in the SOLID principle is Dependency Inversion.

One should depend upon abstractions, not concretions.

Inversion of Control (IoC) is a design pattern used to represent Dependency Inversion in real software.

That makes Dependency Injection popular.

What is Dependency Injection?

Dependency injection (DI) is a software engineering technique that involves making the interactions between objects as thin as possible through specific dependencies. This allows for loosely coupled code — or code that only depends on the required portion of a separate class — to run. And it reduces hard-coded dependencies and allows for cleaner, more flexible code.

some of most popular Dependency Injection frameworks are Koin and Hilt.

Then what's different between Koin and Hilt?

Let’s start by talking about Koin first.

Koin stands out for its simplicity and flexibility. It is a simple DI framework that does not require annotations or code generation. Instead, it makes use of the Domain Specific Language (DSL) provided by Kotlin to specify dependencies and modules.

Koin’s ease of use is one of its benefits. Its minimum setup requirements and its ability to create dependencies with a clear, readable syntax are the aspects that make it stand out. Therefore, Koin is easy for developers who are new to DI.

On the other hand, this features of Koin might come with trade-offs in certain scenarios. Its runtime resolution might lead to potential issues during compile-time if dependencies are not properly configured. Additionally, Koin might not offer the same level of performance optimizations that some other DI frameworks, like Hilt, provide.

How to use Koin?

First, add dependencies to our project’s build.gradle file,

dependencies {
    // Koin core features
    implementation 'org.koin:koin-core:3.2.0'

    // Koin Android features
    implementation 'org.koin:koin-android:3.2.0'
    implementation 'org.koin:koin-androidx-viewmodel:3.2.0'
}

Then, create Koin modules,

import org.koin.dsl.module

val myKoinModule = module {
    single { UserRepository() } 
    factory { UserViewModel(get()) }
    // Define other dependencies...
}

single: create an object that persistent with the entire container lifetime. It does not create a new instance with each call.
factory: create a new object each time. Short live. No persistence in the container

Then in Application class, initialize Koin by loading the modules,

class MyKoinApplication : Application() {
    override fun onCreate() {
        super.onCreate()
        startKoin {
            androidContext(this@MyKoinApplication )
            modules(myKoinModule )
        }
    }
}

This is how we call at Activity

class HomeActivity : AppCompatActivity() {
    private val viewModel by viewModel<UserViewModel>()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // Use viewModel or other dependencies...
    }
}

how about Hilt?

Hilt, developed by Google and built on top of Dagger, is a powerful dependency injection (DI) framework tailored for Android. It simplifies DI by leveraging annotations and compile-time checks to ensure correctness and performance. Additionally, it integrates seamlessly with Jetpack libraries like ViewModel and WorkManager, making it easier to manage dependencies across different Android components.

One of Hilt’s biggest advantages is its strong alignment with the Android development ecosystem, making it a preferred choice for larger projects following architectural patterns like MVVM or Clean Architecture. However, its learning curve can be steep due to its reliance on Dagger and the specific annotations required. Compared to Koin, Hilt may also involve a more complex setup, but it offers better compile-time safety and performance benefits.

How to use Hilt

Add Hilt dependency at our project’s build.gradle file,

dependencies {
    // Other dependencies...
    implementation "com.google.dagger:hilt-android:$hilt_version"
    kapt "com.google.dagger:hilt-compiler:$hilt_version"
    implementation "androidx.hilt:hilt-lifecycle-viewmodel:$hilt_lifecycle_version"
    kapt "androidx.hilt:hilt-compiler:$hilt_lifecycle_version"
}

Enable Hilt to our Application

@HiltAndroidApp
class MyHiltApplication : Application()

Creating Hilt modules

@Module
@InstallIn(ApplicationComponent::class)
object MyModule {
    @Provides
    fun provideMyRepository(): MyRepository {
        return MyRepository()
    }
    
    @Provides
    fun provideMyViewModel(repository: MyRepository): MyViewModel {
        return MyViewModel(repository)
    }
}

Using dependencies in Activity/Fragment,

@AndroidEntryPoint
class MyActivity : AppCompatActivity() {
    private val viewModel: MyViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
    }
}

There is 3 different characteristics between Koin and Hilt:

Syntax and Configuration: Koin offers a simple and readable syntax without relying on annotations or code generation, while Hilt heavily depends on annotations like @Inject and @Module for dependency injection.

Learning Curve and Complexity: Koin is beginner-friendly with minimal setup, making it easier to adopt. In contrast, Hilt has a steeper learning curve due to its integration with Dagger and required annotations.

Performance and Optimization: Koin has faster build times and a smaller APK size since it doesn’t generate code, but it is slightly slower at runtime due to resolving dependencies dynamically. Hilt, using code generation, ensures better runtime performance but can lead to longer build times and a larger APK.

So when to use Koin and Hilt?

_Koin _is ideal for smaller projects due to its simplicity and flexibility, making code more modular and maintainable. However, for larger projects requiring deep integration with Android components, _Hilt _is preferable for its performance optimizations and alignment with Android architecture.

references:
_https://medium.com/ibtech/hilt-vs-koin-f3532b5796eb
https://en.wikipedia.org/wiki/Dependency_injection
https://simple.wikipedia.org/wiki/SOLID_(object-oriented_design)_
https://medium.com/@srimanikandan92/hilt-vs-koin-a-simple-guide-to-android-dependency-injection-ef77d00e7cf6