【OC2Kotlin】第3章 Kotlin面相对象编程

「Generated by Manus, instructions issued by binbinwang」

3.1 类与对象

Kotlin和Objective-C都是面向对象的编程语言，但它们在类和对象的实现上有显著差异。对于从iOS迁移到Android的开发者来说，理解这些差异至关重要。

类的定义

Kotlin类定义：

// 基本类定义
class Person {
    var name: String = ""
    var age: Int = 0
    
    fun introduce() {
        println("Hi, I'm $name and I'm $age years old.")
    }
}

// 使用主构造函数的类定义
class Person(var name: String, var age: Int) {
    fun introduce() {
        println("Hi, I'm $name and I'm $age years old.")
    }
}

Objective-C类定义：

// 头文件 Person.h
@interface Person : NSObject

@property (nonatomic, strong) NSString *name;
@property (nonatomic, assign) NSInteger age;

- (void)introduce;

@end

// 实现文件 Person.m
@implementation Person

- (void)introduce {
    NSLog(@"Hi, I'm %@ and I'm %ld years old.", self.name, (long)self.age);
}

@end

主要区别：

文件结构：Kotlin类通常定义在单个.kt文件中，而Objective-C类通常分为头文件(.h)和实现文件(.m)。
构造函数：Kotlin可以在类声明中直接定义主构造函数，而Objective-C需要单独实现初始化方法。
属性声明：Kotlin的属性声明更简洁，并自动生成getter和setter，而Objective-C使用@property语法。

对象创建与初始化

Kotlin对象创建：

// 使用默认构造函数
val person1 = Person()
person1.name = "John"
person1.age = 30

// 使用主构造函数
val person2 = Person("Jane", 25)

// 使用命名参数（提高可读性）
val person3 = Person(name = "Bob", age = 40)

Objective-C对象创建：

// 两步初始化
Person *person1 = [[Person alloc] init];
person1.name = @"John";
person1.age = 30;

// 使用自定义初始化方法（需要先定义）
Person *person2 = [[Person alloc] initWithName:@"Jane" age:25];

主要区别：

初始化语法：Kotlin使用简洁的构造函数调用语法，而Objective-C使用alloc和init的两步过程。
命名参数：Kotlin支持命名参数，提高代码可读性，而Objective-C的方法名通常包含参数名称。
内存管理：Kotlin由JVM或ART管理内存，而Objective-C使用引用计数（ARC或手动）。

属性与字段

Kotlin属性：

class Person {
    // 基本属性
    var name: String = ""
    
    // 只读属性
    val birthYear: Int = 1990
    
    // 自定义getter和setter
    var age: Int = 0
        get() = field
        set(value) {
            if (value >= 0) {
                field = value
            }
        }
    
    // 计算属性
    val isAdult: Boolean
        get() = age >= 18
    
    // 延迟初始化属性
    lateinit var address: String
    
    // 委托属性
    val lazyValue: String by lazy {
        println("Computed!")
        "Hello"
    }
}

Objective-C属性：

@interface Person : NSObject

// 基本属性
@property (nonatomic, strong) NSString *name;

// 只读属性
@property (nonatomic, readonly) NSInteger birthYear;

// 自定义getter和setter
@property (nonatomic, assign) NSInteger age;

// 计算属性
@property (nonatomic, readonly) BOOL isAdult;

// 实例变量
NSString *_address;

@end

@implementation Person

- (instancetype)init {
    self = [super init];
    if (self) {
        _birthYear = 1990;
    }
    return self;
}

- (void)setAge:(NSInteger)age {
    if (age >= 0) {
        _age = age;
    }
}

- (BOOL)isAdult {
    return self.age >= 18;
}

@end

主要区别：

属性语法：Kotlin的属性语法更简洁，自动生成访问器，而Objective-C使用@property声明。
自定义访问器：Kotlin使用get()和set()块定义自定义访问器，而Objective-C需要实现单独的方法。
后备字段：Kotlin使用field关键字引用属性的后备字段，而Objective-C使用下划线前缀的实例变量。
延迟初始化：Kotlin提供lateinit和by lazy等机制，而Objective-C通常使用懒加载方法。

Q1: Kotlin延迟初始化lateinit和懒加载by lazy有什么区别？什么场景下会用这两种？给具体的工程用例

在Kotlin中，lateinit 和 by lazy 都用于延迟初始化变量，但它们的使用场景和机制有所不同。以下是它们的区别以及具体的工程用例。

1. `lateinit` 延迟初始化

用途：用于非空类型的变量，允许你在声明时不初始化，但在使用前必须初始化。
特点：
- 只能用于 var 变量。
- 不能用于基本类型（如 Int、Boolean 等）。
- 适用于需要在对象创建后但在使用前初始化的场景。
使用场景：通常在依赖注入或单元测试中使用，或者在对象的生命周期中明确知道初始化时机的场景。

2. `by lazy` 懒加载

用途：用于在第一次访问时初始化变量，且初始化后不可变。
特点：
- 只能用于 val 变量。
- 初始化是线程安全的（默认情况下）。
- 适用于初始化成本较高或不需要立即初始化的场景。
使用场景：通常用于单例模式、延迟加载资源或配置等场景。

具体工程用例

1. `lateinit` 的使用场景

假设你有一个 UserService 类，它依赖于 UserRepository，但 UserRepository 需要在 UserService 创建后通过依赖注入进行初始化。

class UserService {
    lateinit var userRepository: UserRepository

    fun initialize(repository: UserRepository) {
        this.userRepository = repository
    }

    fun getUser(id: Int): User? {
        if (!::userRepository.isInitialized) {
            throw IllegalStateException("UserRepository not initialized")
        }
        return userRepository.getUser(id)
    }
}

fun main() {
    val userService = UserService()
    val userRepository = UserRepository()
    userService.initialize(userRepository)

    val user = userService.getUser(1)
    println(user)
}

2. `by lazy` 的使用场景

假设你有一个 Configuration 类，它需要从文件中读取配置信息，但配置信息的读取成本较高，且不需要在对象创建时立即读取。

class Configuration {
    val config: Map<String, String> by lazy {
        // 模拟从文件读取配置信息
        println("Loading configuration...")
        mapOf("host" to "localhost", "port" to "8080")
    }
}

fun main() {
    val config = Configuration()
    println("Configuration object created")
    println("Host: ${config.config["host"]}")
    println("Port: ${config.config["port"]}")
}

输出

Configuration object created
Loading configuration...
Host: localhost
Port: 8080

总结

**lateinit**：适用于需要在对象创建后但在使用前初始化的场景，通常用于 var 变量。
**by lazy**：适用于在第一次访问时初始化变量，且初始化后不可变的场景，通常用于 val 变量。

选择依据

如果你需要在对象的生命周期中明确知道初始化时机，并且变量是可变的，使用 lateinit。
如果你希望变量在第一次访问时初始化，并且初始化后不可变，使用 by lazy。

通过合理选择 lateinit 和 by lazy，可以优化代码的性能和可读性。

Q2: 接上面的问题，如果出于性能友好的角度考虑，是不是所有属性都应该用 lateinit 或者by lazy？

并不一定所有属性都应该使用 lateinit 或 by lazy。虽然这两种机制在某些场景下可以提升性能，但它们的使用需要根据具体需求和场景来决定。以下是一些考虑因素和指导原则：

1. 初始化成本

高初始化成本：如果某个属性的初始化成本较高（例如，需要读取文件、进行网络请求或执行复杂计算），使用 by lazy 可以延迟初始化，直到真正需要时才执行，从而避免不必要的性能开销。
低初始化成本：如果初始化成本较低，直接初始化可能更简单、更高效，因为 by lazy 会引入额外的开销（如线程安全检查和惰性初始化逻辑）。

2. 生命周期和依赖

明确初始化时机：如果某个属性需要在对象创建后但在使用前初始化，并且初始化时机是明确的，使用 lateinit 是合适的。
不确定初始化时机：如果初始化时机不确定，或者属性可能在整个生命周期中都不被使用，使用 by lazy 可以避免不必要的初始化。

3. 线程安全

线程安全：by lazy 默认是线程安全的，适用于多线程环境。如果需要在多线程环境中延迟初始化属性，by lazy 是一个更好的选择。
单线程环境：在单线程环境中，lateinit 可能更简单，因为它没有线程安全开销。

4. 不可变性

不可变属性：如果属性是不可变的（即初始化后不会改变），使用 by lazy 是合适的，因为它确保属性只初始化一次。
可变属性：如果属性是可变的，并且需要在对象生命周期中多次赋值，使用 lateinit 是合适的。

5. 代码可读性和维护性

代码简洁：直接初始化属性通常更简洁，代码更易读和维护。
复杂逻辑：如果初始化逻辑复杂，或者需要延迟初始化，使用 lateinit 或 by lazy 可以提高代码的可读性和维护性。

具体工程用例

1. 高初始化成本

class DatabaseService {
    val databaseConnection: Connection by lazy {
        println("Establishing database connection...")
        DriverManager.getConnection("jdbc:mysql://localhost:3306/mydb", "user", "password")
    }
}

fun main() {
    val dbService = DatabaseService()
    println("DatabaseService object created")
    val connection = dbService.databaseConnection // 第一次访问时初始化
    println("Connection established")
}

2. 明确初始化时机

class UserService {
    lateinit var userRepository: UserRepository

    fun initialize(repository: UserRepository) {
        this.userRepository = repository
    }

    fun getUser(id: Int): User? {
        if (!::userRepository.isInitialized) {
            throw IllegalStateException("UserRepository not initialized")
        }
        return userRepository.getUser(id)
    }
}

fun main() {
    val userService = UserService()
    val userRepository = UserRepository()
    userService.initialize(userRepository)

    val user = userService.getUser(1)
    println(user)
}

总结

性能友好：并不是所有属性都应该使用 lateinit 或 by lazy。只有在需要延迟初始化、避免高初始化成本或确保线程安全时，才应考虑使用这些机制。
直接初始化：对于初始化成本低、生命周期明确且不需要延迟初始化的属性，直接初始化通常更简单、更高效。
代码可读性：在决定使用 lateinit 或 by lazy 时，还应考虑代码的可读性和维护性。

通过合理选择初始化策略，可以在性能和代码简洁性之间找到平衡。

Q2: 接上面的问题，那有什么场景下，是明确不建议使用lateinit或者by lazy的？

确实，在某些场景下，使用 lateinit 或 by lazy 不仅不会带来性能优势，反而可能引入不必要的复杂性和潜在问题。以下是一些明确不建议使用 lateinit 或 by lazy 的场景：

1. 属性初始化成本低

如果属性的初始化成本非常低（例如，简单的赋值或构造一个轻量级对象），直接初始化通常更简单、更高效。使用 lateinit 或 by lazy 会引入额外的开销（如 by lazy 的线程安全检查和惰性初始化逻辑），反而得不偿失。

示例：

// 不推荐：初始化成本低，直接初始化即可
class User {
    val name: String = "John"
}

// 推荐：直接初始化
class User {
    val name: String = "John"
}

2. 属性必须在对象创建时初始化

如果属性必须在对象创建时初始化（例如，构造函数的参数或依赖），使用 lateinit 或 by lazy 会导致代码逻辑不清晰，甚至可能引发运行时错误。

示例：

// 不推荐：属性必须在构造函数中初始化
class User(val id: Int) {
    lateinit var name: String // 容易忘记初始化，导致运行时错误
}

// 推荐：直接在构造函数中初始化
class User(val id: Int, val name: String)

3. 属性是不可变的且初始化逻辑简单

如果属性是不可变的（val），且初始化逻辑非常简单，使用 by lazy 会引入不必要的复杂性。直接初始化更清晰。

示例：

// 不推荐：初始化逻辑简单，直接初始化即可
class Configuration {
    val host: String by lazy { "localhost" }
}

// 推荐：直接初始化
class Configuration {
    val host: String = "localhost"
}

4. 属性可能在整个生命周期中不被使用

如果属性可能在整个生命周期中不被使用，且初始化成本较高，使用 by lazy 是合适的。但如果属性一定会被使用，且初始化成本不高，直接初始化更高效。

示例：

// 不推荐：属性一定会被使用，直接初始化即可
class UserService {
    val userRepository: UserRepository by lazy { UserRepository() } // 不必要
}

// 推荐：直接初始化
class UserService {
    val userRepository: UserRepository = UserRepository()
}

5. 多线程环境下需要严格的初始化顺序

在多线程环境下，如果属性的初始化顺序非常重要，使用 lateinit 可能会导致竞态条件（race condition），因为 lateinit 不提供线程安全保证。在这种情况下，直接初始化或使用 by lazy（默认线程安全）更合适。

示例：

// 不推荐：多线程环境下，lateinit 可能导致竞态条件
class SharedResource {
    lateinit var resource: Resource

    fun initialize() {
        resource = Resource()
    }
}

// 推荐：使用 by lazy（线程安全）
class SharedResource {
    val resource: Resource by lazy { Resource() }
}

6. 属性是基本类型（如 Int、Boolean 等）

lateinit 不能用于基本类型（如 Int、Boolean 等），因为这些类型在 Kotlin 中是不可为空的。如果需要延迟初始化基本类型，可以使用 by lazy 或直接初始化。

示例：

// 不推荐：lateinit 不能用于基本类型
class Counter {
    lateinit var count: Int // 编译错误
}

// 推荐：使用 by lazy 或直接初始化
class Counter {
    val count: Int by lazy { 0 }
}

7. 代码可读性和维护性

如果使用 lateinit 或 by lazy 会导致代码难以理解或维护，直接初始化通常是更好的选择。代码的可读性和简洁性比微小的性能优化更重要。

示例：

// 不推荐：过度使用 by lazy 导致代码难以理解
class ComplexClass {
    val a: String by lazy { "A" }
    val b: String by lazy { "B" }
    val c: String by lazy { "C" }
}

// 推荐：直接初始化，代码更清晰
class ComplexClass {
    val a: String = "A"
    val b: String = "B"
    val c: String = "C"
}

总结

以下场景明确不建议使用 lateinit 或 by lazy：

属性初始化成本低。
属性必须在对象创建时初始化。
属性是不可变的且初始化逻辑简单。
属性一定会被使用，且初始化成本不高。
多线程环境下需要严格的初始化顺序。
属性是基本类型。
使用 lateinit 或 by lazy 会降低代码的可读性和维护性。

在这些场景下，直接初始化通常是更简单、更高效的选择。合理选择初始化策略，可以在性能、代码简洁性和可维护性之间找到平衡。

Q3: 使用 lateinit 可能导致竞态条件具体是什么场景，举例说明

使用 lateinit 可能导致竞态条件（race condition）的场景通常发生在多线程环境下，当多个线程同时尝试初始化或访问一个 lateinit 属性时。由于 lateinit 不提供线程安全保证，可能会导致以下问题：

重复初始化：多个线程同时尝试初始化 lateinit 属性，可能导致初始化逻辑被执行多次。
未初始化访问：一个线程在初始化 lateinit 属性之前，另一个线程尝试访问该属性，导致 UninitializedPropertyAccessException。

具体场景举例

假设你有一个 SharedResource 类，它包含一个 lateinit 属性 resource，并且多个线程可能会同时初始化或访问该属性。

1. 重复初始化

class SharedResource {
    lateinit var resource: String

    fun initialize() {
        resource = "Initialized"
    }
}

fun main() {
    val sharedResource = SharedResource()

    val thread1 = Thread {
        sharedResource.initialize()
        println("Thread 1: ${sharedResource.resource}")
    }

    val thread2 = Thread {
        sharedResource.initialize()
        println("Thread 2: ${sharedResource.resource}")
    }

    thread1.start()
    thread2.start()

    thread1.join()
    thread2.join()
}

在这个例子中，thread1 和 thread2 同时调用 initialize 方法，可能会导致 resource 被多次初始化。虽然在这个简单的例子中不会导致严重问题，但如果初始化逻辑涉及资源分配或其他副作用，可能会导致资源浪费或逻辑错误。

2. 未初始化访问

class SharedResource {
    lateinit var resource: String

    fun initialize() {
        Thread.sleep(1000) // 模拟初始化耗时
        resource = "Initialized"
    }

    fun accessResource() {
        println("Resource: $resource")
    }
}

fun main() {
    val sharedResource = SharedResource()

    val thread1 = Thread {
        sharedResource.initialize()
    }

    val thread2 = Thread {
        sharedResource.accessResource()
    }

    thread1.start()
    thread2.start()

    thread1.join()
    thread2.join()
}

在这个例子中，thread1 负责初始化 resource，而 thread2 尝试访问 resource。由于 thread1 的初始化操作需要 1 秒钟，thread2 可能会在 resource 初始化之前访问它，导致 UninitializedPropertyAccessException。

解决方案

为了避免竞态条件，可以使用以下方法：

**使用 by lazy**：by lazy 是线程安全的，确保属性只初始化一次。
使用同步机制：例如 synchronized 或 @Volatile 注解，确保初始化和访问操作的线程安全。

使用 `by lazy`

class SharedResource {
    val resource: String by lazy {
        println("Initializing resource...")
        "Initialized"
    }
}

fun main() {
    val sharedResource = SharedResource()

    val thread1 = Thread {
        println("Thread 1: ${sharedResource.resource}")
    }

    val thread2 = Thread {
        println("Thread 2: ${sharedResource.resource}")
    }

    thread1.start()
    thread2.start()

    thread1.join()
    thread2.join()
}

使用 `synchronized`

class SharedResource {
    @Volatile
    private var initialized = false
    private var _resource: String? = null
    val resource: String
        get() {
            if (!initialized) {
                synchronized(this) {
                    if (!initialized) {
                        _resource = "Initialized"
                        initialized = true
                    }
                }
            }
            return _resource!!
        }
}

fun main() {
    val sharedResource = SharedResource()

    val thread1 = Thread {
        println("Thread 1: ${sharedResource.resource}")
    }

    val thread2 = Thread {
        println("Thread 2: ${sharedResource.resource}")
    }

    thread1.start()
    thread2.start()

    thread1.join()
    thread2.join()
}

总结

在多线程环境下，使用 lateinit 可能导致竞态条件，包括重复初始化和未初始化访问。为了避免这些问题，可以使用 by lazy 或同步机制来确保初始化和访问操作的线程安全。

Q4: by lazy的线程安全是怎么做的？和 lateinit 使用 synchronized 的实现有什么区别？

by lazy 的线程安全机制和 lateinit 使用 synchronized 的实现有一些关键区别。以下是它们的实现原理和区别的详细说明：

1. `by lazy` 的线程安全机制

by lazy 是 Kotlin 标准库提供的一种惰性初始化机制，它默认是线程安全的。其线程安全性是通过双重检查锁定（Double-Checked Locking）实现的。

实现原理

双重检查锁定：by lazy 在初始化时会使用双重检查锁定来确保线程安全。
- 第一次检查：检查属性是否已经初始化，如果已经初始化，直接返回。
- 第二次检查：如果未初始化，进入同步块，再次检查是否已经初始化，如果仍未初始化，执行初始化逻辑。
初始化逻辑：初始化逻辑只会执行一次，即使多个线程同时访问。

默认线程安全模式

by lazy 提供了三种线程安全模式：

**LazyThreadSafetyMode.SYNCHRONIZED**（默认）：使用双重检查锁定，确保线程安全。
**LazyThreadSafetyMode.PUBLICATION**：允许多个线程同时初始化，但最终只有一个结果会被使用。
**LazyThreadSafetyMode.NONE**：不保证线程安全，适用于单线程环境。

示例

val resource: String by lazy(LazyThreadSafetyMode.SYNCHRONIZED) {
    println("Initializing resource...")
    "Initialized"
}

2. `lateinit` 使用 `synchronized` 的实现

lateinit 本身不提供线程安全机制，如果需要确保线程安全，可以手动使用 synchronized 或 @Volatile 注解来实现。

实现原理

**synchronized**：使用同步块确保同一时间只有一个线程可以执行初始化逻辑。
**@Volatile**：确保变量的可见性，即一个线程对变量的修改对其他线程立即可见。

示例

class SharedResource {
    @Volatile
    private var initialized = false
    private var _resource: String? = null
    val resource: String
        get() {
            if (!initialized) {
                synchronized(this) {
                    if (!initialized) {
                        _resource = "Initialized"
                        initialized = true
                    }
                }
            }
            return _resource!!
        }
}

3. `by lazy` 和 `lateinit` 使用 `synchronized` 的区别

特性	`by lazy`	`lateinit` 使用 `synchronized`
线程安全	默认线程安全（双重检查锁定），无需手动实现	需要手动实现线程安全（如 `synchronized` 或 `@Volatile`）
初始化时机	第一次访问时初始化	需要显式调用初始化方法
属性类型	只能用于 `val`（不可变属性）	只能用于 `var`（可变属性）
适用场景	适用于惰性初始化，且初始化逻辑只执行一次的场景	适用于需要在对象生命周期中明确初始化时机的场景
代码简洁性	代码更简洁，无需手动实现线程安全	需要手动实现线程安全，代码较复杂
性能开销	双重检查锁定引入一定的性能开销，但通常可以接受	手动实现 `synchronized` 或 `@Volatile` 也会引入性能开销
初始化成本	适用于初始化成本较高的场景	适用于初始化成本较低或初始化时机明确的场景

4. 具体场景对比

使用 `by lazy`

val expensiveResource: Resource by lazy {
    println("Initializing expensive resource...")
    Resource() // 假设 Resource 初始化成本较高
}

fun main() {
    println("Before access")
    val resource = expensiveResource // 第一次访问时初始化
    println("After access")
}

使用 `lateinit` 和 `synchronized`

class SharedResource {
    @Volatile
    private var initialized = false
    private var _resource: Resource? = null
    val resource: Resource
        get() {
            if (!initialized) {
                synchronized(this) {
                    if (!initialized) {
                        _resource = Resource()
                        initialized = true
                    }
                }
            }
            return _resource!!
        }
}

fun main() {
    val sharedResource = SharedResource()
    println("Before access")
    val resource = sharedResource.resource // 第一次访问时初始化
    println("After access")
}

5. 总结

**by lazy**：默认线程安全，适用于惰性初始化且初始化逻辑只执行一次的场景。代码简洁，但会引入一定的性能开销。
**lateinit 使用 synchronized**：需要手动实现线程安全，适用于需要在对象生命周期中明确初始化时机的场景。代码较复杂，但灵活性更高。

选择使用哪种机制取决于具体需求：

如果需要简单、线程安全的惰性初始化，优先选择 by lazy。
如果需要更灵活的控制（如初始化时机或可变属性），可以使用 lateinit 并手动实现线程安全。

3.2 继承与接口

继承

Kotlin继承：

// 基类（默认是final的，需要open才能被继承）
open class Animal(val name: String) {
    open fun makeSound() {
        println("Some generic sound")
    }
}

// 子类
class Dog(name: String, val breed: String) : Animal(name) {
    override fun makeSound() {
        println("Woof!")
    }
}

// 使用
val dog = Dog("Rex", "German Shepherd")
dog.makeSound() // 输出: Woof!
println("${dog.name} is a ${dog.breed}") // 输出: Rex is a German Shepherd

Objective-C继承：

// 基类
@interface Animal : NSObject

@property (nonatomic, strong) NSString *name;

- (instancetype)initWithName:(NSString *)name;
- (void)makeSound;

@end

@implementation Animal

- (instancetype)initWithName:(NSString *)name {
    self = [super init];
    if (self) {
        _name = name;
    }
    return self;
}

- (void)makeSound {
    NSLog(@"Some generic sound");
}

@end

// 子类
@interface Dog : Animal

@property (nonatomic, strong) NSString *breed;

- (instancetype)initWithName:(NSString *)name breed:(NSString *)breed;

@end

@implementation Dog

- (instancetype)initWithName:(NSString *)name breed:(NSString *)breed {
    self = [super initWithName:name];
    if (self) {
        _breed = breed;
    }
    return self;
}

- (void)makeSound {
    NSLog(@"Woof!");
}

@end

// 使用
Dog *dog = [[Dog alloc] initWithName:@"Rex" breed:@"German Shepherd"];
[dog makeSound]; // 输出: Woof!
NSLog(@"%@ is a %@", dog.name, dog.breed); // 输出: Rex is a German Shepherd

主要区别：

默认行为：Kotlin类默认是final的（不可继承），需要使用open关键字允许继承，而Objective-C类默认可以被继承。
方法覆盖：Kotlin需要使用override关键字明确标记覆盖方法，而Objective-C不需要特殊标记。
构造函数链：Kotlin子类必须调用父类构造函数，而Objective-C通过[super init...]调用。
多重继承：Kotlin和Objective-C都不支持类的多重继承，但Kotlin支持接口的多重实现。

接口

Kotlin接口：

// 定义接口
interface Swimmable {
    fun swim() // 抽象方法
    val maxSpeed: Float // 抽象属性
    
    // 带默认实现的方法
    fun dive() {
        println("Diving...")
    }
}

// 实现接口
class Fish(override val maxSpeed: Float) : Swimmable {
    override fun swim() {
        println("Swimming at speed up to $maxSpeed")
    }
    
    // 可以选择覆盖默认实现
    override fun dive() {
        println("Fish diving deep")
    }
}

// 实现多个接口
interface Flyable {
    fun fly()
}

class FlyingFish(override val maxSpeed: Float) : Swimmable, Flyable {
    override fun swim() {
        println("Swimming at speed up to $maxSpeed")
    }
    
    override fun fly() {
        println("Flying fish can glide through the air")
    }
}

Objective-C协议：

// 定义协议
@protocol Swimmable <NSObject>

@required
- (void)swim;
@property (nonatomic, readonly) float maxSpeed;

@optional
- (void)dive;

@end

// 实现协议
@interface Fish : NSObject <Swimmable>

@property (nonatomic, readonly) float maxSpeed;

- (instancetype)initWithMaxSpeed:(float)maxSpeed;

@end

@implementation Fish

- (instancetype)initWithMaxSpeed:(float)maxSpeed {
    self = [super init];
    if (self) {
        _maxSpeed = maxSpeed;
    }
    return self;
}

- (void)swim {
    NSLog(@"Swimming at speed up to %f", self.maxSpeed);
}

- (void)dive {
    NSLog(@"Fish diving deep");
}

@end

// 实现多个协议
@protocol Flyable <NSObject>

- (void)fly;

@end

@interface FlyingFish : NSObject <Swimmable, Flyable>

@property (nonatomic, readonly) float maxSpeed;

@end

@implementation FlyingFish

- (void)swim {
    NSLog(@"Swimming at speed up to %f", self.maxSpeed);
}

- (void)fly {
    NSLog(@"Flying fish can glide through the air");
}

@end

主要区别：

默认实现：Kotlin接口可以包含方法的默认实现，而Objective-C协议传统上只能声明方法（虽然现代Objective-C也支持协议扩展）。
属性：Kotlin接口可以包含抽象属性，而Objective-C协议可以声明属性但不能提供实现。
可选性：Kotlin接口的所有方法默认都是必须实现的，而Objective-C协议可以使用@required和@optional标记。
多重实现：两种语言都支持实现多个接口/协议。

3.3 属性与字段

属性类型

Kotlin属性类型：

class PropertyDemo {
    // 1. 可变属性
    var mutableProperty: String = "Initial value"
    
    // 2. 只读属性
    val readOnlyProperty: Int = 42
    
    // 3. 延迟初始化属性
    lateinit var lateInitProperty: String
    
    // 4. 懒加载属性
    val lazyProperty: String by lazy {
        println("Computing lazy property...")
        "Lazy value"
    }
    
    // 5. 自定义访问器
    var counter: Int = 0
        get() = field
        set(value) {
            if (value >= 0) {
                field = value
                println("Counter set to $value")
            }
        }
    
    // 6. 计算属性（没有后备字段）
    val isPositive: Boolean
        get() = counter > 0
    
    // 7. 委托属性
    var observed: Int by observable(0) { _, old, new ->
        println("Value changed from $old to $new")
    }
}

Objective-C属性类型：

@interface PropertyDemo : NSObject

// 1. 可变属性
@property (nonatomic, strong) NSString *mutableProperty;

// 2. 只读属性
@property (nonatomic, readonly) NSInteger readOnlyProperty;

// 3. 实例变量（没有属性包装）
NSString *_lateInitProperty;

// 4. 懒加载属性（通过getter实现）
@property (nonatomic, strong, readonly) NSString *lazyProperty;

// 5. 自定义访问器属性
@property (nonatomic, assign) NSInteger counter;

// 6. 计算属性
@property (nonatomic, readonly) BOOL isPositive;

@end

@implementation PropertyDemo

- (instancetype)init {
    self = [super init];
    if (self) {
        _mutableProperty = @"Initial value";
        _readOnlyProperty = 42;
    }
    return self;
}

// 4. 懒加载实现
- (NSString *)lazyProperty {
    if (!_lazyProperty) {
        NSLog(@"Computing lazy property...");
        _lazyProperty = @"Lazy value";
    }
    return _lazyProperty;
}

// 5. 自定义setter
- (void)setCounter:(NSInteger)counter {
    if (counter >= 0) {
        _counter = counter;
        NSLog(@"Counter set to %ld", (long)counter);
    }
}

// 6. 计算属性实现
- (BOOL)isPositive {
    return self.counter > 0;
}

@end

主要区别：

属性声明：Kotlin的属性声明更简洁，而Objective-C使用@property语法。
访问器定义：Kotlin在属性声明中直接定义访问器，而Objective-C需要单独实现方法。
延迟初始化：Kotlin提供lateinit和by lazy等专用机制，而Objective-C通常使用getter方法实现懒加载。
属性委托：Kotlin支持属性委托模式，而Objective-C没有直接等价物。
可见性控制：Kotlin使用修饰符控制属性可见性，而Objective-C使用readonly和访问器实现控制。

字段可见性

Kotlin字段可见性：

class VisibilityDemo {
    // 公开属性（默认）
    var publicProperty: String = "Public"
    
    // 私有属性（仅在类内可见）
    private var privateProperty: String = "Private"
    
    // 受保护属性（在类及其子类中可见）
    protected var protectedProperty: String = "Protected"
    
    // 内部属性（在模块内可见）
    internal var internalProperty: String = "Internal"
    
    fun accessProperties() {
        println(publicProperty)
        println(privateProperty)
        println(protectedProperty)
        println(internalProperty)
    }
}

class Subclass : VisibilityDemo() {
    fun accessInherited() {
        println(publicProperty)
        // println(privateProperty) // 错误：不可访问
        println(protectedProperty)
        println(internalProperty)
    }
}

Objective-C字段可见性：

// 头文件
@interface VisibilityDemo : NSObject

// 公开属性
@property (nonatomic, strong) NSString *publicProperty;

// 私有属性（在现代Objective-C中可以在类扩展中声明）
- (void)accessProperties;

@end

// 实现文件
@interface VisibilityDemo ()

// 私有属性（仅在实现文件中可见）
@property (nonatomic, strong) NSString *privateProperty;

// 受保护属性（Objective-C没有直接的protected关键字）
@property (nonatomic, strong) NSString *protectedProperty;

@end

@implementation VisibilityDemo

- (instancetype)init {
    self = [super init];
    if (self) {
        _publicProperty = @"Public";
        _privateProperty = @"Private";
        _protectedProperty = @"Protected";
    }
    return self;
}

- (void)accessProperties {
    NSLog(@"%@", self.publicProperty);
    NSLog(@"%@", self.privateProperty);
    NSLog(@"%@", self.protectedProperty);
}

@end

@interface Subclass : VisibilityDemo
@end

@implementation Subclass

- (void)accessInherited {
    NSLog(@"%@", self.publicProperty);
    // NSLog(@"%@", self.privateProperty); // 错误：不可访问
    // 在Objective-C中，子类可以访问父类的实例变量，但不能访问类扩展中声明的属性
    // 可以通过KVC访问，但不推荐：NSLog(@"%@", [self valueForKey:@"privateProperty"]);
}

@end

主要区别：

可见性修饰符：Kotlin提供了四种可见性修饰符（public、private、protected、internal），而Objective-C主要通过类扩展和实现文件控制可见性。
默认可见性：Kotlin的默认可见性是public，而Objective-C的属性默认也是公开的。
模块级可见性：Kotlin提供了internal修饰符，而Objective-C没有直接等价物。
继承可见性：Kotlin的protected确保只有子类可以访问，而Objective-C的可见性控制相对较弱。

3.4 构造函数与初始化

构造函数

Kotlin构造函数：

// 1. 主构造函数
class Person(val name: String, var age: Int) {
    // 初始化块
    init {
        println("Person created with name: $name and age: $age")
        require(age >= 0) { "Age cannot be negative" }
    }
    
    // 2. 次构造函数
    constructor(name: String) : this(name, 0) {
        println("Secondary constructor called")
    }
    
    // 3. 另一个次构造函数
    constructor() : this("Unknown") {
        println("Default constructor called")
    }
}

// 使用
val person1 = Person("John", 30)
val person2 = Person("Jane")
val person3 = Person()

Objective-C初始化方法：

@interface Person : NSObject

@property (nonatomic, strong, readonly) NSString *name;
@property (nonatomic, assign) NSInteger age;

// 1. 指定初始化方法
- (instancetype)initWithName:(NSString *)name age:(NSInteger)age;

// 2. 便利初始化方法
- (instancetype)initWithName:(NSString *)name;

// 3. 默认初始化方法
- (instancetype)init;

@end

@implementation Person

// 1. 指定初始化方法
- (instancetype)initWithName:(NSString *)name age:(NSInteger)age {
    self = [super init];
    if (self) {
        _name = name;
        _age = age;
        NSLog(@"Person created with name: %@ and age: %ld", name, (long)age);
        if (age < 0) {
            @throw [NSException exceptionWithName:NSInvalidArgumentException
                                           reason:@"Age cannot be negative"
                                         userInfo:nil];
        }
    }
    return self;
}

// 2. 便利初始化方法
- (instancetype)initWithName:(NSString *)name {
    NSLog(@"Secondary initializer called");
    return [self initWithName:name age:0];
}

// 3. 默认初始化方法
- (instancetype)init {
    NSLog(@"Default initializer called");
    return [self initWithName:@"Unknown"];
}

@end

// 使用
Person *person1 = [[Person alloc] initWithName:@"John" age:30];
Person *person2 = [[Person alloc] initWithName:@"Jane"];
Person *person3 = [[Person alloc] init];

主要区别：

构造函数语法：Kotlin使用主构造函数和次构造函数的概念，而Objective-C使用指定初始化方法和便利初始化方法。
初始化块：Kotlin使用init块执行初始化逻辑，而Objective-C在初始化方法内执行。
构造函数链：Kotlin使用this关键字调用其他构造函数，而Objective-C使用self调用其他初始化方法。
参数属性：Kotlin可以在主构造函数中直接声明属性，而Objective-C需要单独声明属性并在初始化方法中赋值。

初始化顺序

Kotlin初始化顺序：

主构造函数的参数
类级别的属性初始化和初始化块，按照它们在类中出现的顺序
次构造函数的代码

open class Base {
    init {
        println("Base init block")
    }
    
    constructor() {
        println("Base constructor")
    }
}

class Derived : Base {
    val prop1 = "Property 1".also { println("Initializing $it") }
    
    init {
        println("Derived init block 1")
    }
    
    val prop2 = "Property 2".also { println("Initializing $it") }
    
    init {
        println("Derived init block 2")
    }
    
    constructor() : super() {
        println("Derived constructor")
    }
}

// 输出:
// Base init block
// Base constructor
// Initializing Property 1
// Derived init block 1
// Initializing Property 2
// Derived init block 2
// Derived constructor

Objective-C初始化顺序：

分配内存（alloc）
调用父类的初始化方法（[super init]）
初始化实例变量
执行其他初始化代码

@interface Base : NSObject
@end

@implementation Base
- (instancetype)init {
    self = [super init];
    if (self) {
        NSLog(@"Base initializer");
    }
    return self;
}
@end

@interface Derived : Base
@property (nonatomic, strong) NSString *prop1;
@property (nonatomic, strong) NSString *prop2;
@end

@implementation Derived
- (instancetype)init {
    self = [super init];
    if (self) {
        NSLog(@"Initializing prop1");
        _prop1 = @"Property 1";
        
        NSLog(@"Derived initializer part 1");
        
        NSLog(@"Initializing prop2");
        _prop2 = @"Property 2";
        
        NSLog(@"Derived initializer part 2");
    }
    return self;
}
@end

// 输出:
// Base initializer
// Initializing prop1
// Derived initializer part 1
// Initializing prop2
// Derived initializer part 2

主要区别：

初始化顺序：Kotlin有更明确的初始化顺序规则，而Objective-C的初始化顺序相对简单。
初始化块：Kotlin支持多个初始化块，而Objective-C将所有初始化逻辑放在初始化方法中。
属性初始化：Kotlin允许在声明时初始化属性，而Objective-C通常在初始化方法中初始化实例变量。
继承初始化：两种语言都要求先调用父类的初始化方法，但语法不同。

3.5 与Objective-C对比：类与对象模型

类型系统对比

特性	Kotlin	Objective-C	优势
类定义	单文件，简洁	头文件和实现文件分离	Kotlin减少样板代码
构造函数	主构造函数和次构造函数	指定初始化方法和便利初始化方法	两者各有优势
属性	内置支持，自动生成访问器	需要使用@property声明	Kotlin更简洁
继承	默认final，需要open	默认可继承	Kotlin更安全
接口	支持默认实现	协议，现代版支持扩展	Kotlin更灵活
可见性控制	四种级别，编译时强制	有限，主要通过文件组织	Kotlin更严格
扩展	扩展函数和属性	类别（Category）和扩展	两者各有优势

内存管理对比

Kotlin内存管理：

由JVM或Android运行时（ART）自动管理
To save on context only part of this file has been shown to you. You should retry this tool after you have searched inside the file with grep -n in order to find the line numbers of what you are looking for.

【OC2Kotlin】第3章 Kotlin面相对象编程

3.1 类与对象

类的定义

对象创建与初始化

属性与字段

Q1: Kotlin延迟初始化lateinit和懒加载by lazy有什么区别？什么场景下会用这两种？给具体的工程用例

1. lateinit 延迟初始化

2. by lazy 懒加载

具体工程用例

1. lateinit 的使用场景

2. by lazy 的使用场景

输出

总结

选择依据

Q2: 接上面的问题，如果出于性能友好的角度考虑，是不是所有属性都应该用 lateinit 或者by lazy？

1. 初始化成本

2. 生命周期和依赖

3. 线程安全

4. 不可变性

5. 代码可读性和维护性

具体工程用例

1. 高初始化成本

2. 明确初始化时机

总结

Q2: 接上面的问题，那有什么场景下，是明确不建议使用lateinit或者by lazy的？

1. 属性初始化成本低

2. 属性必须在对象创建时初始化

3. 属性是不可变的且初始化逻辑简单

4. 属性可能在整个生命周期中不被使用

5. 多线程环境下需要严格的初始化顺序

6. 属性是基本类型（如 Int、Boolean 等）

7. 代码可读性和维护性

总结

Q3: 使用 lateinit 可能导致竞态条件具体是什么场景，举例说明

具体场景举例

1. 重复初始化

2. 未初始化访问

解决方案

使用 by lazy

使用 synchronized

总结

Q4: by lazy的线程安全是怎么做的？和 lateinit 使用 synchronized 的实现有什么区别？

1. by lazy 的线程安全机制

实现原理

默认线程安全模式

示例

2. lateinit 使用 synchronized 的实现

实现原理

示例

3. by lazy 和 lateinit 使用 synchronized 的区别

4. 具体场景对比

使用 by lazy

使用 lateinit 和 synchronized

5. 总结

3.2 继承与接口

继承

接口

3.3 属性与字段

属性类型

字段可见性

3.4 构造函数与初始化

构造函数

初始化顺序

3.5 与Objective-C对比：类与对象模型

类型系统对比

内存管理对比

1. `lateinit` 延迟初始化

2. `by lazy` 懒加载

1. `lateinit` 的使用场景

2. `by lazy` 的使用场景

使用 `by lazy`

使用 `synchronized`

1. `by lazy` 的线程安全机制

2. `lateinit` 使用 `synchronized` 的实现

3. `by lazy` 和 `lateinit` 使用 `synchronized` 的区别

使用 `by lazy`

使用 `lateinit` 和 `synchronized`