Swift Interview Questions Programming

There will be a compilation error. The derived class Car calls the init method of superclass before its stored property, model gets initialised. Swift does 2 phase initialization, in first phase memory is allocated and all stored properties get initialized starting from the derived classes and then its superclass. Then in the second phase, all customizations of the properties are done, in the init method.

The correct code will be :

class Car:Transport {
    var model:String
    init(model:String){
        self.model = model
        super.init(type: "Car")
         self.model = "\(self.model) - type \(self.type)"
        print("\(self.model)")
    }
}
The result will be
  Transport - Car
   Maruti  - type Car

 Dump function is used to print the content of the object 

For eg: 

class Person {
    let name: String
    let cars: [String]?
    init(name:String, cars: [String]?) {
        self.name = name
        self.cars = cars
    }
}

let allPerson = [Person(name: "P1", cars: ["P1_C1", "P1_C2"]), Person(name: "P2", cars: ["P2_C1", "P2_C2"])]
dump(allPerson)

Output:

▿ 2 elements
  ▿ App.Person #0
    - name: "P1"
    ▿ cars: Optional(["P1_C1", "P1_C2"])
      ▿ some: 2 elements
        - "P1_C1"
        - "P1_C2"
  ▿ App.Person #1
    - name: "P2"
    ▿ cars: Optional(["P2_C1", "P2_C2"])
      ▿ some: 2 elements
        - "P2_C1"
        - "P2_C2"
//As seen, dump() outputs the whole class hierarchy, while print() simply outputs the class name.

• name Sam Smith
• name John

Explanation: employee3 is a struct, and we assign  employees2 = employees separate array in memory is created in the memory.  And when we add emp3 in employees it is not reflected in employees2. But emp1 and emp2 are reference types. So if we change employees[0].name = "Sam Smith"   employees2[0] is also changed as they refer to the same object. 

Key is to use associated types, which is a powerful way of making protocols generic.

protocol Store {
    associatedtype DataType
    var ids: [DataType] { get set}
    mutating func add(id: DataType)
}
extension Store {
    mutating func add(id: DataType) {
        ids.append(id)
    }
}
struct SystemOne: Store {
    var ids = [String]()
}
struct SystemTwo: Store {
    var ids = [Int]()
}
var sysOne = SystemOne()
sysOne.add(id: "One")
sysOne.add(id: "Two")
var sysTwo = SystemTwo()
sysTwo.add(id: 1)
sysTwo.add(id: 2)
print(sysOne.ids)
print(sysTwo.ids)

In MVC, controller is coordinated that reads / saves data into the data model and displays data / handles actions in the view.

In MVVM, the view model is a close representation of a view. The view model is bound to the view. Any change in data in the view model, leads to notifiications and view pulls data from the view model and it displays it.

Test covering controllers can be a bit difficult as view is tightly attached to a view i.e View controller will have an instance of a view within it. So it will be difficult to mock the view methods called from the controller.

Test covering in  ViewModel is rather easy as it does not contain any reference to a view. Rather it only prepares data for the view only. It is the view that pulls the data from the view model.  Also, the view delegates the action to the View model. 

The derived class convenience initializers only and call convenience initializer or designated initializer of own class. Ultimately the call chain should have designated initializer at last of the same class.

So the correct code is :

class A {
    var name:String
    init(name:String) {
        self.name = name
    }
}
class B:A {
    var id : String
    init(name:String, id : String){
        self.id = id
        super.init(name: name)
    }
 convenience init (id:String) {
self.init(name: "unknown", id: id)
    }
}