Android计算器开发：更高效的单位转换实现方案咨询

Hey there! I totally get your frustration—handling a growing list of unit conversions with individual methods or static variables gets really unwieldy fast, especially when you’re planning to expand your calculator down the line. Let’s walk through some cleaner, more scalable approaches that’ll make maintaining and adding new units a breeze in your Android project:

This is my go-to for most unit conversion scenarios. Instead of hardcoding logic for every pair of units, define a data class to hold unit metadata, then store all units in a map grouped by category (length, weight, temperature, etc.). This way, adding a new unit only requires a single line of data, not a new method.

Example in Kotlin:

// Data class to store core unit info
data class Unit(
    val displayName: String,
    val symbol: String,
    val conversionFactorToBase: Double // Factor to convert this unit to a shared "base" unit (e.g., meters for length)
)

// Group units by their category
val lengthUnits = mapOf(
    "meter" to Unit("Meter", "m", 1.0),
    "kilometer" to Unit("Kilometer", "km", 1000.0),
    "centimeter" to Unit("Centimeter", "cm", 0.01),
    "inch" to Unit("Inch", "in", 0.0254)
)

// Universal conversion method
fun convertUnit(
    value: Double,
    fromUnitKey: String,
    toUnitKey: String,
    unitGroup: Map<String, Unit>
): Double? {
    val fromUnit = unitGroup[fromUnitKey] ?: return null
    val toUnit = unitGroup[toUnitKey] ?: return null

    // Convert to base unit first, then to target unit
    val baseValue = value * fromUnit.conversionFactorToBase
    return baseValue / toUnit.conversionFactorToBase
}

To add a new length unit (like feet), just append "foot" to Unit("Foot", "ft", 0.3048) to the lengthUnits map—no new conversion logic needed.

If your unit sets are fixed (unlikely to change often), enums are a great choice for type safety. They eliminate the risk of passing invalid unit strings and keep all related logic bundled together.

Example:

enum class LengthUnit(val symbol: String, val factorToMeter: Double) {
    METER("m", 1.0),
    KILOMETER("km", 1000.0),
    CENTIMETER("cm", 0.01),
    INCH("in", 0.0254);

    // Built-in conversion method
    fun convertTo(target: LengthUnit, value: Double): Double {
        val baseValue = value * factorToMeter
        return baseValue / target.factorToMeter
    }
}

// Usage example
val kmToCm = LengthUnit.KILOMETER.convertTo(LengthUnit.CENTIMETER, 2.5)

For units that don’t use simple multiplication/division (like temperature: Celsius ↔ Fahrenheit), the strategy pattern lets you encapsulate unique conversion logic while keeping a unified interface.

Example:

// Base interface for all conversion strategies
interface ConversionStrategy {
    fun convert(value: Double, fromUnit: String, toUnit: String): Double
}

// Strategy for temperature (non-linear conversion)
class TemperatureStrategy : ConversionStrategy {
    override fun convert(value: Double, fromUnit: String, toUnit: String): Double {
        return when {
            fromUnit == "celsius" && toUnit == "fahrenheit" -> (value * 9/5) + 32
            fromUnit == "fahrenheit" && toUnit == "celsius" -> (value - 32) * 5/9
            else -> value // Return original if units match or are invalid
        }
    }
}

// Strategy for simple linear conversions (like length)
class LinearConversionStrategy(private val unitMap: Map<String, Double>) : ConversionStrategy {
    override fun convert(value: Double, fromUnit: String, toUnit: String): Double {
        val fromFactor = unitMap[fromUnit] ?: return value
        val toFactor = unitMap[toUnit] ?: return value
        return value * fromFactor / toFactor
    }
}

// Manager to handle different conversion categories
class UnitConverter {
    private val strategies = mapOf(
        "temperature" to TemperatureStrategy(),
        "length" to LinearConversionStrategy(mapOf(
            "meter" to 1.0, "km" to 1000.0, "cm" to 0.01
        ))
    )

    fun convert(category: String, value: Double, from: String, to: String): Double {
        return strategies[category]?.convert(value, from, to) ?: value
    }
}

If you want to update units without modifying code (e.g., for localization or quick tweaks), store conversion rules in a JSON/XML resource file (like res/raw/unit_conversions.json). Parse this file on app startup and load the data into your data classes.

Sample JSON structure:

{
  "length": [
    {"key": "meter", "name": "Meter", "symbol": "m", "factor": 1.0},
    {"key": "kilometer", "name": "Kilometer", "symbol": "km", "factor": 1000.0}
  ],
  "temperature": [
    {"key": "celsius", "name": "Celsius", "symbol": "°C"},
    {"key": "fahrenheit", "name": "Fahrenheit", "symbol": "°F"}
  ]
}

You can use libraries like Gson or Moshi to parse this into your data models, then pair it with the strategy pattern to handle both linear and complex conversions.

Pick the approach that fits your needs best: start with data classes + maps for simplicity and flexibility, use enums if your units are fixed and you want type safety, lean on the strategy pattern for complex conversion logic, or go with resource files if you want easy configuration without code changes. All of these will save you from the headache of writing hundreds of repetitive conversion methods as your calculator grows.

内容的提问来源于stack exchange，提问作者user7359083