Inversion of Control #

// ANTI-PATTERN: tight coupling — OrderService creates all its dependencies itself
type OrderService struct{}

func NewOrderService() *OrderService {
    return &OrderService{}
}

func (s *OrderService) CreateOrder(req CreateOrderRequest) error {
    // Tight coupling to concrete implementations
    db := mysql.NewConnection("localhost:3306", "orders_db") // hardcoded!
    emailSvc := smtp.NewClient("smtp.gmail.com", 587)        // hardcoded!
    logger := zap.NewProduction()                             // hardcoded!
    
    // Now OrderService knows too much:
    // - How to create a MySQL connection
    // - SMTP server config
    // - How to create a logger
    
    order := createOrder(req)
    db.Save(order)
    emailSvc.Send(req.UserEmail, "Order confirmed")
    logger.Info("order created", zap.String("id", order.ID))
    return nil
}

// Impact:
// 1. Can't unit test without a real MySQL and SMTP connection
// 2. Can't switch MySQL to PostgreSQL without changing OrderService
// 3. Can't inject mocks for testing

// CORRECT: IoC — dependencies are declared, not created
type OrderService struct {
    db       OrderRepository  // interface, not concrete
    emailSvc EmailSender      // interface, not concrete
    logger   Logger           // interface, not concrete
}

// The constructor only accepts dependencies, doesn't create them
func NewOrderService(db OrderRepository, email EmailSender, log Logger) *OrderService {
    return &OrderService{db: db, emailSvc: email, logger: log}
}

func (s *OrderService) CreateOrder(req CreateOrderRequest) error {
    order := createOrder(req)
    s.db.Save(order)                                   // doesn't know the DB implementation
    s.emailSvc.Send(req.UserEmail, "Order confirmed")  // doesn't know the email implementation
    s.logger.Info("order created", "id", order.ID)    // doesn't know the logger implementation
    return nil
}

// Immediate benefits:
// 1. Unit testing → inject mock DB and mock EmailSender
// 2. Switching MySQL to PostgreSQL → only change the wiring in the container, not OrderService
// 3. Dependencies are clearly visible from the constructor signature

// Constructor Injection — most recommended
type PaymentService struct {
    gateway   PaymentGateway  // interface
    repo      PaymentRepo     // interface
    notifier  Notifier        // interface
}

func NewPaymentService(gw PaymentGateway, repo PaymentRepo, n Notifier) *PaymentService {
    return &PaymentService{gateway: gw, repo: repo, notifier: n}
}

// For testing: inject mocks
func TestPaymentService_Process(t *testing.T) {
    mockGateway  := &MockPaymentGateway{shouldSucceed: true}
    mockRepo     := &MockPaymentRepo{}
    mockNotifier := &MockNotifier{}
    
    svc := NewPaymentService(mockGateway, mockRepo, mockNotifier)
    err := svc.Process(PaymentRequest{Amount: 100000})
    
    assert.NoError(t, err)
    assert.True(t, mockNotifier.WasCalled)
}

// For production: inject real implementations
func main() {
    gw       := stripe.NewGateway(os.Getenv("STRIPE_KEY"))
    repo     := postgres.NewPaymentRepo(db)
    notifier := fcm.NewNotifier(os.Getenv("FCM_KEY"))
    
    svc := NewPaymentService(gw, repo, notifier)
    // ... wire to the handler
}

// ANTI-PATTERN: your code controls the lifecycle
func main() {
    server := http.NewServeMux()
    server.HandleFunc("/", handler)
    
    // You decide when to listen, when to shut down
    go server.ListenAndServe(":8080")
    time.Sleep(10 * time.Second) // bad way to wait
    server.Shutdown(context.Background())
}

// CORRECT: the framework controls the lifecycle, you only register hooks
func main() {
    app := fiber.New()
    
    // IoC: you register handlers, Fiber calls them
    app.Get("/users", getUsers)        // the framework calls this on GET /users
    app.Post("/orders", createOrder)   // the framework calls this on POST /orders
    
    // IoC: you register lifecycle hooks, the framework decides when to call them
    app.Hooks().OnListen(func(ld fiber.ListenData) error {
        log.Printf("Server started on port %s", ld.Port)
        return nil
    })
    app.Hooks().OnShutdown(func() error {
        return db.Close() // cleanup on shutdown
    })
    
    app.Listen(":8080") // the framework takes control from here
}

// The framework defines the flow — you fill in the specific implementation
type BaseConsumer struct{}

// The framework calls this for every message
func (b *BaseConsumer) ProcessMessage(msg Message) {
    b.BeforeProcess(msg)   // hook: before processing
    b.DoProcess(msg)       // hook: main processing (must be implemented)
    b.AfterProcess(msg)    // hook: after processing
}

func (b *BaseConsumer) BeforeProcess(msg Message) { /* default: log */ }
func (b *BaseConsumer) AfterProcess(msg Message)  { /* default: ack */ }

// ANTI-PATTERN: overriding all methods including the main flow
type OrderConsumer struct{ BaseConsumer }
func (c *OrderConsumer) ProcessMessage(msg Message) {
    // Breaks the flow — BeforeProcess and AfterProcess are never called
    c.handleOrder(msg)
}

// CORRECT: only override the methods that need customization
type OrderConsumer struct{ BaseConsumer }
func (c *OrderConsumer) DoProcess(msg Message) {
    // Order-specific implementation
    var event OrderCreatedEvent
    json.Unmarshal(msg.Body, &event)
    c.processOrder(event)
}
// The framework still calls BeforeProcess and AfterProcess automatically

// ANTI-PATTERN: can't be tested without real infrastructure
func TestCreateOrder_WithoutIoC(t *testing.T) {
    svc := NewOrderService() // creates real MySQL + SMTP connections
    // This test needs: MySQL running, SMTP server, network
    // If any one is missing → the test fails even though the logic is correct
}

// CORRECT: tests without infrastructure — fast, deterministic, focused
func TestCreateOrder_Success(t *testing.T) {
    mockDB    := &MockOrderRepo{shouldSucceed: true}
    mockEmail := &MockEmailSender{}
    mockLog   := &MockLogger{}
    
    svc := NewOrderService(mockDB, mockEmail, mockLog)
    err := svc.CreateOrder(CreateOrderRequest{
        UserID: "user-123",
        Items:  []Item{{ProductID: "prod-1", Qty: 2}},
    })
    
    assert.NoError(t, err)
    assert.Equal(t, 1, mockDB.SaveCallCount)
    assert.Equal(t, 1, mockEmail.SendCallCount)
}

func TestCreateOrder_DBFailure(t *testing.T) {
    mockDB    := &MockOrderRepo{shouldFail: true, failErr: errors.New("db timeout")}
    mockEmail := &MockEmailSender{}
    
    svc := NewOrderService(mockDB, mockEmail, &MockLogger{})
    err := svc.CreateOrder(CreateOrderRequest{UserID: "user-123"})
    
    assert.Error(t, err)
    assert.Equal(t, 0, mockEmail.SendCallCount) // email not sent if the DB fails
}

// ANTI-PATTERN: hidden dependencies — hard to understand from the outside
type ReportService struct{}

func (s *ReportService) Generate(reportID string) Report {
    // New engineers don't know this needs MySQL, Redis, S3, and an email sender
    db := globalDB    // hidden global variable
    cache := redisPool.Get()
    storage := s3Client
    mailer := smtpConn
    // ...
}

// CORRECT: explicit dependencies — immediately readable from the signature
func NewReportService(
    db      ReportRepository,
    cache   CacheClient,
    storage FileStorage,
    mailer  EmailSender,
) *ReportService {
    return &ReportService{db: db, cache: cache, storage: storage, mailer: mailer}
}
// New engineers immediately know: this service needs a DB, cache, storage, and email

// ANTI-PATTERN: manual wiring — long, error-prone ordering
func main() {
    db     := postgres.New(os.Getenv("DB_URL"))
    cache  := redis.New(os.Getenv("REDIS_URL"))
    mailer := smtp.New(os.Getenv("SMTP_HOST"))
    logger := zap.New()

    userRepo    := repository.NewUserRepo(db, cache)
    orderRepo   := repository.NewOrderRepo(db)
    emailSvc    := service.NewEmailService(mailer, logger)
    orderSvc    := service.NewOrderService(orderRepo, emailSvc, logger)
    userSvc     := service.NewUserService(userRepo, emailSvc, logger)
    orderHdl    := handler.NewOrderHandler(orderSvc, logger)
    userHdl     := handler.NewUserHandler(userSvc, logger)
    // ... 50 more lines
}

// CORRECT: the IoC container manages wiring automatically (example with Uber FX)
func main() {
    app := fx.New(
        fx.Provide(
            postgres.New,
            redis.New,
            smtp.New,
            zap.New,
            repository.NewUserRepo,
            repository.NewOrderRepo,
            service.NewEmailService,
            service.NewOrderService,
            service.NewUserService,
            handler.NewOrderHandler,
            handler.NewUserHandler,
        ),
        fx.Invoke(startServer), // FX manages the order and lifecycle
    )
    app.Run()
}

// ✗ Service locator — IoC but still hidden dependencies
func (s *OrderService) CreateOrder(req Request) error {
    db := container.Get("database").(Database) // still hidden, hard to test
    return db.Save(order)
}
// ✓ Constructor injection — explicit and testable
func NewOrderService(db Database) *OrderService { ... }

// ✗ Injecting the container into a service — the service knows about the container
type OrderService struct {
    container *DIContainer // WRONG: services must not know about the container
}
func (s *OrderService) CreateOrder(req Request) error {
    db := s.container.Get("database").(Database)
    ...
}
// ✓ Inject the dependency directly, not the container
type OrderService struct {
    db Database // interface, injected directly
}

// ✗ Constructor with too many parameters — a sign SRP is being violated
func NewOrderService(db DB, cache Cache, email Email, sms SMS, push Push,
    analytics Analytics, audit Audit, logger Logger) *OrderService { ... }
// If > 4-5 parameters → consider whether this service is doing too much

// ✗ Optional dependencies via setters — dependencies aren't clear
func (s *OrderService) SetLogger(l Logger) { s.logger = l }
// ✓ Required dependencies via the constructor, optional ones via functional options
func NewOrderService(db DB, opts ...OrderServiceOption) *OrderService { ... }