/*
 * Module 2: Engineering Singleton in JavaScript
 * This section demonstrates various implementations of the Singleton pattern in JavaScript,
 * from traditional closure-based approaches to modern ES6 classes and the module pattern.
 * Each implementation guarantees only one instance of the object is created.
 */

// 1. Classic ES5 Closure-Based Singleton
// This approach leverages a closure to hide the instance and a immediately invoked function expression (IIFE)
// to create a private scope, ensuring the 'instance' variable is not globally accessible.

const DatabaseConnectionES5 = (function () {
    let instance;

    function init() {
        // Private methods and properties for the database connection
        let connectionString = "mongodb://localhost:27017/my_app_es5";
        let isConnected = false;

        console.log("ES5 Singleton: Initializing a new database connection...");

        return {
            connect: function () {
                if (!isConnected) {
                    console.log(`ES5 Singleton: Connecting to ${connectionString}`);
                    isConnected = true;
                } else {
                    console.log(`ES5 Singleton: Already connected to ${connectionString}`);
                }
            },
            getConnectionStatus: function () {
                return isConnected;
            },
            // Expose a method to show it's always the same instance
            getInstanceId: function() {
                return `ES5-DB-Instance-${Math.random().toString(36).substring(2, 10)}`;
            }
        };
    }

    return {
        // The public method to get the instance
        getInstance: function () {
            if (!instance) {
                instance = init();
            }
            return instance;
        }
    };
})();

console.log("--- ES5 Closure Singleton Demonstration ---");
const db1ES5 = DatabaseConnectionES5.getInstance();
const db2ES5 = DatabaseConnectionES5.getInstance();

db1ES5.connect();
console.log(`DB1 Status: ${db1ES5.getConnectionStatus()}`);
console.log(`Are db1 and db2 the same instance? ${db1ES5 === db2ES5}`); // Should be true
console.log(`DB1 Instance ID (unique per object, but this property will be the same for both): ${db1ES5.getInstanceId()}`);
console.log(`DB2 Instance ID: ${db2ES5.getInstanceId()}`);


// 2. Modern ES6 Class-Based Singleton
// This approach uses ES6 classes and static methods to manage the single instance.
// The constructor is not strictly private in JavaScript classes, but we can throw an error
// to prevent direct instantiation using 'new'.

class ConfigurationManagerES6 {
    constructor() {
        if (ConfigurationManagerES6.instance) {
            throw new Error("ES6 Singleton: Use ConfigurationManagerES6.getInstance() instead of new.");
        }
        // Private properties for the configuration
        this._settings = {
            theme: 'dark',
            language: 'en',
            version: '1.0.0'
        };
        console.log("ES6 Singleton: Initializing a new Configuration Manager...");

        // Assign this instance to the static property only if it's the first time.
        ConfigurationManagerES6.instance = this;
    }

    static getInstance() {
        if (!ConfigurationManagerES6.instance) {
            ConfigurationManagerES6.instance = new ConfigurationManagerES6();
        }
        return ConfigurationManagerES6.instance;
    }

    getSetting(key) {
        return this._settings[key];
    }

    setSetting(key, value) {
        this._settings[key] = value;
        console.log(`ES6 Singleton: Setting '${key}' updated to '${value}'.`);
    }
}

console.log("\n--- ES6 Class Singleton Demonstration ---");
const config1ES6 = ConfigurationManagerES6.getInstance();
const config2ES6 = ConfigurationManagerES6.getInstance();

console.log(`Initial theme: ${config1ES6.getSetting('theme')}`);
config1ES6.setSetting('theme', 'light');
console.log(`Updated theme (via config2): ${config2ES6.getSetting('theme')}`); // Reflects change made by config1
console.log(`Are config1 and config2 the same instance? ${config1ES6 === config2ES6}`); // Should be true

// Attempting to instantiate directly will throw an error:
// try {
//     const config3ES6 = new ConfigurationManagerES6();
// } catch (e) {
//     console.error(e.message);
// }


// 3. JavaScript Module Pattern (Natural Singleton)
// JavaScript modules, by their nature, are singletons. When you import a module multiple times,
// you always get the same instance of the module's exported values.
// This is often the most idiomatic way to achieve singleton-like behavior in modern JavaScript.

// Imagine 'logger.js' as a separate file:
// // logger.js
// let logCount = 0;
// function log(message) {
//     logCount++;
//     console.log(`[LOG ${logCount}] ${message}`);
// }
// export { log, logCount }; // Exporting logCount for demonstration, usually you wouldn't expose internal state like this directly

// For demonstration purposes, we'll simulate the module here:
const LoggerModule = (function() {
    let logCount = 0; // Private state

    function log(message) {
        logCount++;
        console.log(`Module Singleton: [LOG ${logCount}] ${message}`);
    }

    function getLogCount() {
        return logCount;
    }

    // Expose only the necessary public API
    return {
        log: log,
        getLogCount: getLogCount
    };
})(); // IIFE to create a module-like scope


console.log("\n--- JavaScript Module Pattern Demonstration (Natural Singleton) ---");
const logger1 = LoggerModule;
const logger2 = LoggerModule;

logger1.log("User logged in.");
logger2.log("Item added to cart.");
logger1.log("Payment processed.");

console.log(`Total logs recorded (via logger1): ${logger1.getLogCount()}`);
console.log(`Total logs recorded (via logger2): ${logger2.getLogCount()}`);
console.log(`Are logger1 and logger2 the same instance? ${logger1 === logger2}`); // Should be true, as they reference the same object exported by the module

/*
 * Key Takeaway for Implementations:
 * - ES5 Closure: Utilizes IIFEs and closures for private state and controlled instantiation.
 * - ES6 Class: Employs static methods and a constructor check to enforce single instance.
 * - Module Pattern: Leverages JavaScript's module system where modules are naturally singletons,
 *   often the preferred, more idiomatic approach for shared utilities or state.
 */

/*
 * Module 3: Deconstructing Singleton's Latent Risks
 * This section illustrates how the Singleton pattern can lead to an anti-pattern,
 * particularly by introducing global state and tight coupling, making testing difficult.
 */

// Simulate a Logger Singleton that tightly couples to a global state (e.g., logging to a file or console)
// This is a simplified version to highlight issues, not a full-fledged logger.

class UnsafeLoggerSingleton {
    constructor() {
        if (UnsafeLoggerSingleton.instance) {
            return UnsafeLoggerSingleton.instance;
        }
        this.logs = []; // Simulates internal state that accumulates over time
        UnsafeLoggerSingleton.instance = this;
        console.log("Unsafe Logger Singleton: Initializing.");
    }

    static getInstance() {
        if (!UnsafeLoggerSingleton.instance) {
            UnsafeLoggerSingleton.instance = new UnsafeLoggerSingleton();
        }
        return UnsafeLoggerSingleton.instance;
    }

    log(message) {
        const timestamp = new Date().toISOString();
        const logEntry = `${timestamp} - ${message}`;
        this.logs.push(logEntry);
        console.log(`[Log Entry] ${logEntry}`);
    }

    getLogs() {
        return [...this.logs]; // Return a copy to prevent external modification of the internal array directly
    }

    clearLogs() {
        this.logs = [];
        console.log("Unsafe Logger Singleton: Logs cleared.");
    }
}

// --- Demonstration of Risks ---

console.log("\n--- Unsafe Singleton Demonstration: Tight Coupling & Global State ---");

// Scenario 1: Feature A logs messages
const featureALogger = UnsafeLoggerSingleton.getInstance();
featureALogger.log("Feature A: User clicked button.");

// Scenario 2: Feature B logs messages, unknowingly affecting Feature A's context
const featureBLogger = UnsafeLoggerSingleton.getInstance();
featureBLogger.log("Feature B: Data loaded successfully.");

console.log("All accumulated logs:", featureALogger.getLogs()); // Both A and B logs are here

// Risk 1: Testability Issue - Difficult to isolate tests
// If we want to test Feature A in isolation, we can't easily reset its logger state
// without affecting other parts of the application that use the same singleton.

function testFeatureA() {
    console.log("\n--- Testing Feature A (Attempting Isolation) ---");
    const logger = UnsafeLoggerSingleton.getInstance();
    // Problem: If previous tests or parts of the app logged something,
    // `logger.getLogs()` will contain those, making this test non-isolated.
    // We'd have to clear it, which affects other 'tests' or 'features'.
    logger.clearLogs(); // This impacts any other part of the app that uses the same logger!
    logger.log("Feature A Test: Operation X completed.");
    const logs = logger.getLogs();
    if (logs.length === 1 && logs[0].includes("Operation X")) {
        console.log("Feature A Test: PASSED (but isolation problematic).");
    } else {
        console.log("Feature A Test: FAILED.");
    }
    logger.clearLogs(); // Clean up, but still a global side effect
}

function testFeatureB() {
    console.log("\n--- Testing Feature B (Further Isolation Challenge) ---");
    const logger = UnsafeLoggerSingleton.getInstance();
    // If testFeatureA didn't clear the logs, testFeatureB would see its logs.
    // If it did clear them, testFeatureA's logs are gone for other checks.
    // This tightly coupled global state makes tests brittle.
    logger.clearLogs(); // Again, a global side effect
    logger.log("Feature B Test: User input validated.");
    const logs = logger.getLogs();
    if (logs.length === 1 && logs[0].includes("User input validated")) {
        console.log("Feature B Test: PASSED (still battling global state).");
    } else {
        console.log("Feature B Test: FAILED.");
    }
    logger.clearLogs();
}

testFeatureA();
testFeatureB();

// Risk 2: Tight Coupling
// Any part of the application that calls `UnsafeLoggerSingleton.getInstance()` is directly tied
// to this specific implementation. Swapping out the logging mechanism (e.g., from console logging
// to a remote service) requires modifying every call site or creating complex proxies.
// This violates the Dependency Inversion Principle and makes the system less flexible.

// Risk 3: Single Responsibility Principle (SRP) Violation (potential)
// A Singleton often takes on the responsibility of managing its own instance lifecycle
// in addition to its primary function (e.g., logging, configuration). This dual responsibility
// can complicate changes and make the class harder to reason about.

console.log("\n--- Summary of Risks ---");
console.log("1. Global State: Difficult to track changes and predict behavior.");
console.log("2. Testability: Hard to isolate units of code for testing without affecting global state.");
console.log("3. Tight Coupling: Components are directly tied to the concrete Singleton implementation.");
console.log("4. Hidden Dependencies: It's not immediately obvious that a function relies on a global Singleton.");
console.log("5. Concurrency Issues (less common in JS single-threaded, but still relevant for async ops): Potential for race conditions if instance creation isn't properly synchronized in more complex environments or specific JS runtimes.");

/*
 * Module 4: Navigating Alternatives: Architecting Robust and Flexible Systems
 * This section demonstrates robust alternatives to the Singleton pattern,
 * focusing on Dependency Injection and the Factory pattern for better testability and flexibility.
 */

// 1. Dependency Injection (DI) Example
// Instead of having a component fetch its dependencies (like a logger) from a global singleton,
// we pass those dependencies to the component via its constructor or methods.

// Define a generic Logger interface (or simply a function/class to be injected)
class CustomLogger {
    constructor(prefix = "") {
        this.prefix = prefix ? `[${prefix}] ` : '';
    }
    log(message) {
        console.log(`${this.prefix}DI Logger: ${message}`);
    }
    error(message) {
        console.error(`${this.prefix}DI Logger ERROR: ${message}`);
    }
}

// Component that needs a Logger - it doesn't create the logger, it receives it.
class DataProcessor {
    constructor(logger) {
        if (!logger || typeof logger.log !== 'function') {
            throw new Error("DataProcessor requires a valid logger instance.");
        }
        this.logger = logger;
    }

    process(data) {
        this.logger.log(`Processing data: ${data}`);
        // Simulate some processing that might fail
        if (data.length > 10) {
            this.logger.error(`Data too long: ${data.length} characters.`);
            return false;
        }
        this.logger.log("Data processed successfully.");
        return true;
    }
}

console.log("\n--- Dependency Injection Demonstration ---");

// Application setup: create and provide dependencies
const appLogger = new CustomLogger("App");
const processor = new DataProcessor(appLogger); // Injecting the logger

processor.process("short data");
processor.process("this is some very long data that will cause an error");

// Benefit for Testing:
// We can easily inject a 'mock' logger for testing, without affecting a global singleton.
class MockLogger {
    constructor() {
        this.messages = [];
    }
    log(message) {
        this.messages.push(`MOCK_LOG: ${message}`);
    }
    error(message) {
        this.messages.push(`MOCK_ERROR: ${message}`);
    }
    getRecordedMessages() {
        return this.messages;
    }
}

console.log("\n--- Dependency Injection: Testing with Mocks ---");
const mockLogger = new MockLogger();
const testProcessor = new DataProcessor(mockLogger); // Injecting the mock logger

testProcessor.process("test data");
const recordedLogs = mockLogger.getRecordedMessages();
console.log("Mock Logger Recorded Messages:", recordedLogs);
// We can assert on `recordedLogs` without worrying about global state.


// 2. Factory Pattern Example
// A Factory provides an interface for creating objects in a superclass,
// but allows subclasses to alter the type of objects that will be created.
// It can also manage the lifecycle of objects, including creating a single instance if needed,
// but without the global access point of a traditional Singleton.

// Define a Product interface or base class
class ReportGenerator {
    generate(data) {
        throw new Error("Method 'generate()' must be implemented.");
    }
}

class PDFReportGenerator extends ReportGenerator {
    generate(data) {
        console.log(`Factory: Generating PDF report for data: ${data}`);
        return "PDF Report Content";
    }
}

class CSVReportGenerator extends ReportGenerator {
    generate(data) {
        console.log(`Factory: Generating CSV report for data: ${data}`);
        return "CSV Report Content";
    }
}

// The Factory class
class ReportFactory {
    static createReportGenerator(type) {
        switch (type.toLowerCase()) {
            case 'pdf':
                return new PDFReportGenerator();
            case 'csv':
                return new CSVReportGenerator();
            default:
                throw new Error(`Unknown report type: ${type}`);
        }
    }
}

console.log("\n--- Factory Pattern Demonstration ---");
const pdfGenerator = ReportFactory.createReportGenerator('pdf');
const csvGenerator = ReportFactory.createReportGenerator('csv');

console.log(pdfGenerator.generate("Sales Figures"));
console.log(csvGenerator.generate("Inventory List"));

// Factory can also incorporate Singleton-like behavior internally for specific products IF needed,
// but without forcing it onto the overall application architecture.
// For instance, a factory might ensure only one instance of a 'HeavyResourceWorker' exists,
// but other products it creates can be new instances.

// Conclusion:
// - Dependency Injection promotes loose coupling and testability by passing dependencies.
// - Factory Pattern centralizes object creation, offering flexibility in choosing object types
//   and managing their lifecycle without global state.
// These patterns lead to more robust, maintainable, and testable applications compared to a rigid Singleton.