Переопределение методов в расширениях Swift

одной из целей Swift является статическая диспетчеризация, а точнее сокращение динамической диспетчеризации. Obj-C, однако, очень динамичный язык. Ситуация, которую вы видите, вытекает из связи между двумя языками и тем, как они работают вместе. Это не должно компилироваться.

одним из основных моментов расширения является то, что они предназначены для расширения, а не для замены / переопределения. Из названия и документации ясно, что это намерение. Действительно, если вы берете ссылку на Obj-C из вашего кода (remove NSObject Как суперкласс) он не будет компилироваться.

Итак, компилятор пытается решить, что он может статически отправлять и что он должен динамически отправлять, и он падает через пробел из-за ссылки Obj-C в вашем коде. Причина dynamic "работает", потому что он заставляет Obj-C связываться со всем, поэтому все это всегда динамично.

Итак, это не неправильно использовать расширения для группировки, это здорово, но это так неправильно переопределять в расширениях. Любые переопределения должны быть в самом главном классе и вызывать точки расширения.

существует способ достижения чистого разделения сигнатуры класса и реализации (в расширениях) при сохранении возможности иметь переопределения в подклассах. Хитрость заключается в использовании переменных вместо функций

если вы убедитесь, что определяете каждый подкласс в отдельном исходном файле swift, вы можете использовать вычисляемые переменные для переопределений, сохраняя соответствующую реализацию чисто организованной в расширениях. Это позволит обойти "правила" Swift и будет сделайте API/подпись вашего класса аккуратно организованной в одном месте:

 // ---------- BaseClass.swift -------------

 public class BaseClass
 {
     public var method1:(Int) -> String { return doMethod1 }

     public init() {}
 }

 // the extension could also be in a separate file  
 extension BaseClass
 {    
     private func doMethod1(param:Int) -> String { return "BaseClass \(param)" }
 }

...

 // ---------- ClassA.swift ----------

 public class A:BaseClass
 {
    override public var method1:(Int) -> String { return doMethod1 }
 }

 // this extension can be in a separate file but not in the same
 // file as the BaseClass extension that defines its doMethod1 implementation
 extension A
 {
    private func doMethod1(param:Int) -> String 
    { 
       return "A \(param) added to \(super.method1(param))" 
    }
 }

...

 // ---------- ClassB.swift ----------
 public class B:A
 {
    override public var method1:(Int) -> String { return doMethod1 }
 }

 extension B
 {
    private func doMethod1(param:Int) -> String 
    { 
       return "B \(param) added to \(super.method1(param))" 
    }
 }

расширения каждого класса могут использовать одни и те же имена методов для реализации, потому что они являются частными и не видны друг другу (пока они находятся в отдельных файлах).

как вы можете видеть наследование (используя имя переменной) работает правильно с помощью super.переменное имя

 BaseClass().method1(123)         --> "BaseClass 123"
 A().method1(123)                 --> "A 123 added to BaseClass 123"
 B().method1(123)                 --> "B 123 added to A 123 added to BaseClass 123"
 (B() as A).method1(123)          --> "B 123 added to A 123 added to BaseClass 123"
 (B() as BaseClass).method1(123)  --> "B 123 added to A 123 added to BaseClass 123"

этот ответ он не нацелен на OP, кроме того, что я чувствовал вдохновение ответить на его заявление: "я склонен только помещать потребности (сохраненные свойства, инициализаторы) в мои определения классов и перемещать все остальное в свое собственное расширение ...". Я в первую очередь программист C#, и в C# можно использовать частичные классы для этой цели. Например, Visual Studio помещает материалы, связанные с пользовательским интерфейсом, в отдельный исходный файл с помощью частичного класса и оставляет основной исходный файл незагроможденный, чтобы у вас не было этого отвлечения.

если вы ищете "swift partial class", вы найдете различные ссылки, где сторонники Swift говорят, что Swift не нуждается в частичных классах, потому что вы можете использовать расширения. Интересно, что если вы введете "swift extension" в поле поиска Google, его первое предложение поиска - "SWIFT extension override", и на данный момент этот вопрос переполнения стека является первым хитом. Я полагаю, что это означает, что проблемы с (отсутствием) переопределения возможностей являются наиболее искомой темой, связанной с расширениями Swift, и подчеркивает тот факт, что расширения Swift не могут заменить частичные классы, по крайней мере, если вы используете производные классы в своем программировании.

в любом случае, чтобы сократить длинное введение, я столкнулся с этой проблемой в ситуации, когда я хотел переместить некоторые шаблонные / багажные методы из основных исходных файлов для классов Swift, которые создавала моя программа C#-to-Swift. После запуска в проблему нет переопределение, разрешенное для этих методов после перемещения их в расширения, я закончил реализацию следующего простого обходного пути. Основные исходные файлы Swift по-прежнему содержат некоторые крошечные методы заглушки, которые вызывают реальные методы в файлах расширений, и эти методы расширения получают уникальные имена, чтобы избежать проблемы переопределения.

public protocol PCopierSerializable {

   static func getFieldTable(mCopier : MCopier) -> FieldTable
   static func createObject(initTable : [Int : Any?]) -> Any
   func doSerialization(mCopier : MCopier)
}

.

public class SimpleClass : PCopierSerializable {

   public var aMember : Int32

   public init(
               aMember : Int32
              ) {
      self.aMember = aMember
   }

   public class func getFieldTable(mCopier : MCopier) -> FieldTable {
      return getFieldTable_SimpleClass(mCopier: mCopier)
   }

   public class func createObject(initTable : [Int : Any?]) -> Any {
      return createObject_SimpleClass(initTable: initTable)
   }

   public func doSerialization(mCopier : MCopier) {
      doSerialization_SimpleClass(mCopier: mCopier)
   }
}

.

extension SimpleClass {

   class func getFieldTable_SimpleClass(mCopier : MCopier) -> FieldTable {
      var fieldTable : FieldTable = [ : ]
      fieldTable[376442881] = { () in try mCopier.getInt32A() }  // aMember
      return fieldTable
   }

   class func createObject_SimpleClass(initTable : [Int : Any?]) -> Any {
      return SimpleClass(
                aMember: initTable[376442881] as! Int32
               )
   }

   func doSerialization_SimpleClass(mCopier : MCopier) {
      mCopier.writeBinaryObjectHeader(367620, 1)
      mCopier.serializeProperty(376442881, .eInt32, { () in mCopier.putInt32(aMember) } )
   }
}

.

public class DerivedClass : SimpleClass {

   public var aNewMember : Int32

   public init(
               aNewMember : Int32,
               aMember : Int32
              ) {
      self.aNewMember = aNewMember
      super.init(
                 aMember: aMember
                )
   }

   public class override func getFieldTable(mCopier : MCopier) -> FieldTable {
      return getFieldTable_DerivedClass(mCopier: mCopier)
   }

   public class override func createObject(initTable : [Int : Any?]) -> Any {
      return createObject_DerivedClass(initTable: initTable)
   }

   public override func doSerialization(mCopier : MCopier) {
      doSerialization_DerivedClass(mCopier: mCopier)
   }
}

.

extension DerivedClass {

   class func getFieldTable_DerivedClass(mCopier : MCopier) -> FieldTable {
      var fieldTable : FieldTable = [ : ]
      fieldTable[376443905] = { () in try mCopier.getInt32A() }  // aNewMember
      fieldTable[376442881] = { () in try mCopier.getInt32A() }  // aMember
      return fieldTable
   }

   class func createObject_DerivedClass(initTable : [Int : Any?]) -> Any {
      return DerivedClass(
                aNewMember: initTable[376443905] as! Int32,
                aMember: initTable[376442881] as! Int32
               )
   }

   func doSerialization_DerivedClass(mCopier : MCopier) {
      mCopier.writeBinaryObjectHeader(367621, 2)
      mCopier.serializeProperty(376443905, .eInt32, { () in mCopier.putInt32(aNewMember) } )
      mCopier.serializeProperty(376442881, .eInt32, { () in mCopier.putInt32(aMember) } )
   }
}

как я уже сказал в моем введение, это на самом деле не отвечает на вопрос OP, но я надеюсь, что этот простой обходной путь может быть полезен другим, которые хотят переместить методы из основных исходных файлов в файлы расширений и запустить проблему без переопределения.

используйте POP(Protocol-Oriented Programming) для переопределения функций в расширениях.

protocol AProtocol {
    func aFunction()
}

extension AProtocol {
    func aFunction() {
        print("empty")
    }
}

class AClass: AProtocol {

}

extension AClass {
    func aFunction() {
        print("not empty")
    }
}

let cls = AClass()
cls.aFunction()