Можно ли создать новое поле у класса в extension функции?

Нет, нельзя добавить хранимое поле через extension

В Kotlin (и в Java) extension-функции — это исключительно синтаксический сахар, который позволяет вызывать функции так, будто они являются членами класса, но при этом не модифицирует исходный класс. Расширения компилируются в статические методы, принимающие экземпляр класса первым параметром.

Почему нельзя добавить хранимое поле?

1. Архитектурные ограничения виртуальной машины (JVM/Dalvik/ART):

• Расширения компилируются в обычные статические методы
• Для добавления поля потребовалось бы изменить структуру класса в байт-коде, что невозможно в runtime
• Это нарушило бы принцип инкапсуляции и могло бы вызвать конфликты с существующими полями

2. Техническая реализация:

// Extension-функция компилируется в статический метод
fun String.customExtension(): String {
    return this + " extended"
}

// После компиляции становится чем-то вроде:
// public static String customExtension(String receiver) {
//     return receiver + " extended";
// }

Что МОЖНО сделать в extension-функциях?

1. Добавлять методы (функции):

fun String.addEmoji(): String = "$this 😊"

// Использование
println("Hello".addEmoji()) // Hello 😊

2. Добавлять свойства только с getter (без backing field):

val String.isCool: Boolean
    get() = this.contains("cool", ignoreCase = true)

// Использование
println("This is cool".isCool) // true

3. Использовать делегированные свойства с хранением в Map:

class Container {
    private val extensions = mutableMapOf<String, Any>()
    
    var String.customProperty: String
        get() = extensions["customProperty"] as? String ?: ""
        set(value) { extensions["customProperty"] = value }
}

// Но это хранилище отдельно от объекта, а не поле в классе

Альтернативные подходы для расширения функциональности

1. Декоратор (Decorator Pattern):

class EnhancedString(private val original: String) {
    val customField: String = "Custom Data"
    
    fun originalMethod(): String = original
    fun customMethod(): String = "$original with $customField"
}

2. Делегирование (Delegation):

interface ExtendedString {
    val value: String
    val customField: String
}

class ExtendedStringImpl(
    private val original: String,
    override val customField: String
) : ExtendedString {
    override val value: String get() = original
}

3. Хранение данных в отдельной Map (подход Kotlin для delegated properties):

private val customFields = WeakHashMap<Any, MutableMap<String, Any>>()

fun Any.setCustomField(key: String, value: Any) {
    customFields.getOrPut(this) { mutableMapOf() }[key] = value
}

fun Any.getCustomField(key: String): Any? {
    return customFields[this]?.get(key)
}

Важные ограничения extensions

• Нет доступа к private/protected членам исходного класса
• Статическое разрешение — extensions не виртуальные, разрешаются на этапе компиляции
• Приоритет — члены класса всегда имеют приоритет над extensions с тем же именем

Практический пример с ограничением

class OriginalClass(val name: String)

// НЕВОЗМОЖНО добавить так:
// var OriginalClass.newField: String = "" // Ошибка компиляции

// Но можно добавить свойство без backing field:
val OriginalClass.displayName: String
    get() = "Name: $name"

// Или создать хранилище "псевдо-полей":
private val extensionStorage = mutableMapOf<OriginalClass, String>()

var OriginalClass.pseudoField: String
    get() = extensionStorage[this] ?: ""
    set(value) { extensionStorage[this] = value }

Вывод: Вопрос демонстрирует понимание фундаментальных ограничений системы типов JVM и различий между синтаксическим сахаром (extensions) и реальной модификацией классов. Extension-функции предназначены для добавления поведения, а не состояния. Для добавления состояния необходимо использовать другие паттерны проектирования или модифицировать исходный класс.