Singleton Pattern #

Dalam pengembangan perangkat lunak, sering kali kita menghadapi kebutuhan untuk memastikan sebuah objek hanya memiliki satu instance dan dapat diakses secara global oleh berbagai bagian aplikasi. Pola desain ini dikenal sebagai Singleton Pattern, salah satu creational design pattern yang populer dalam software engineering.

Singleton Pattern membantu menjaga konsistensi data, efisiensi resource, dan menyediakan akses terkontrol ke instance tunggal. Dengan memahami konsep, implementasi, dan best practice-nya, developer dapat menghindari kesalahan umum sekaligus memanfaatkan pola ini secara optimal.

Apa itu Singleton Pattern? #

Singleton Pattern adalah salah satu creational design pattern yang bertujuan memastikan bahwa hanya ada satu instance dari sebuah class / struct selama lifecycle aplikasi, serta menyediakan global access point ke instance tersebut.

Dengan kata lain:

• Instance dibuat satu kali
• Instance tersebut digunakan bersama oleh seluruh bagian aplikasi
• Tidak ada instance lain yang bisa dibuat secara sembarangan

Pattern ini sering digunakan untuk merepresentasikan resource yang:

• Mahal untuk dibuat
• Harus konsisten di seluruh aplikasi
• Tidak boleh ada duplikasi state

Tujuan Pattern #

Tujuan utama Singleton Pattern adalah:

1. Kontrol terhadap jumlah instance Menjamin hanya ada satu instance yang aktif.

2. Global access yang terkontrol Instance bisa diakses dari mana saja, tetapi tetap melalui satu pintu.

3. Shared state yang konsisten Cocok untuk objek yang menyimpan konfigurasi atau koneksi.

4. Efisiensi resource Menghindari pembuatan object berulang yang mahal (misalnya koneksi DB).

Kapan Cocok Digunakan? #

Singleton cocok digunakan jika:

• Aplikasi membutuhkan satu sumber kebenaran (single source of truth)

• Objek:

  • Database connection pool
  • Logger
  • Configuration loader
  • Metrics / telemetry client
  • Cache manager

• State harus sinkron dan konsisten di seluruh aplikasi

• Instance bersifat stateless atau state-nya memang shared secara global

Contoh Use Case Nyata #

• Logger: semua modul menulis log ke instance logger yang sama
• Config: konfigurasi dibaca sekali, dipakai di mana-mana
• DB Pool: pool koneksi database tidak boleh ganda

Kapan Tidak Dianjurkan? #

Singleton sering disalahgunakan. Hindari jika:

• Objek punya banyak state yang mudah berubah
• Menyulitkan testing (mocking)
• Membuat dependency menjadi implicit (tersembunyi)
• Digunakan hanya sebagai alasan “biar gampang diakses”

Singleton yang berlebihan sering berubah menjadi global variable terselubung.

Contoh Implementasi (Golang) #

Golang tidak memiliki konsep class seperti OOP klasik, tetapi Singleton dapat diimplementasikan dengan package-level variable dan sync.Once.

Contoh Implementasi (Thread-Safe) #

package config

import (
    "sync"
)

type Config struct {
    AppName string
}

var (
    instance *Config
    once     sync.Once
)

func GetConfig() *Config {
    once.Do(func() {
        instance = &Config{
            AppName: "My App",
        }
    })

    return instance
}

Cara Menggunakannya #

cfg := config.GetConfig()
fmt.Println(cfg.AppName)

Kenapa sync.Once? #

• Dijamin hanya dieksekusi sekali
• Aman untuk concurrent access
• Tidak perlu manual locking

Alternatif Tanpa sync.Once #

Untuk kasus sederhana (tanpa concurrency):

var instance *Config

func GetConfig() *Config {
    if instance == nil {
        instance = &Config{}
    }
    return instance
}

⚠️ Tidak thread-safe — tidak disarankan untuk production.

Singleton vs Dependency Injection #

Banyak aplikasi modern lebih memilih Dependency Injection (DI) daripada Singleton.

Best practice modern:

Gunakan Singleton hanya untuk resource, bukan business logic.

Kesalahan Umum #

• Menggunakan Singleton sebagai global variable
• Menyimpan terlalu banyak state
• Menggunakan Singleton untuk semua service
• Tidak mempertimbangkan lifecycle aplikasi

Best Practices #

1. Pastikan benar-benar perlu satu instance Jangan gunakan Singleton hanya karena malas passing dependency.

2. Gunakan sync.Once untuk concurrency

3. Hindari logic bisnis di dalam Singleton Idealnya hanya sebagai infrastructure layer.

4. Jaga agar tetap stateless atau read-mostly

5. Pertimbangkan testability Jika sulit di-test, mungkin itu tanda Singleton bukan pilihan tepat.

6. Jangan expose mutable state sembarangan

Penutup #

• Singleton Pattern memastikan satu instance saja
• Cocok untuk shared resource
• Golang menyediakan sync.Once sebagai solusi ideal
• Jangan berlebihan — Singleton bukan solusi untuk semua masalah

Jika digunakan dengan tepat, Singleton membantu menjaga konsistensi dan efisiensi aplikasi. Jika disalahgunakan, ia menjadi sumber technical debt.

“Singleton is a tool, not a default choice.”