Рефакторинг помогают уменьшить дублирование

Question

У меня есть несколько ViewControllers все с несколькими методами, как ниже (и это практически единственные методы в классах.)

@IBAction func witnessNameAction(sender: RoundCornerButton) { 
    presentTextEntryFromViewController(self, initialText: incidentReport.witnessName, completion: { [unowned self] text in 
     self.incidentReport.witnessName = text 
    }) 

    sender.setTapped() 
} 

@IBAction func witnessDescriptionAction(sender: RoundCornerButton) { 
    presentTextEntryFromViewController(self, initialText: incidentReport.witnessDescription, completion: { [unowned self] text in 
     self.incidentReport.witnessDescription = text 
    }) 

    sender.setTapped() 
} 

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

Answer 1

Исходя из Java и прочитав некоторые из оправданий Microsoft в отношении предложенных ими подходов к MSDN для C#, есть несколько способов увидеть, как это подходило.

Если метод будет только когда есть два параметра, создать метод, который позволил бы как:

function witness(paramA, paramB) { 
    if (paramA != null) { 
     // Target A 
    } 
    if (paramB != null) { 
     // Target B 
    } 
} 

Это заставляет меня думать, что «у меня есть объект A и нужно создать единую концепцию объекта B»

в противном случае, перечисление или статические числа будет работать тоже:

function witness(target, param) { 
    switch (target) { 
     case TARGET_A: 
      // Target A 
      break; 
     case TARGET_B 
      // Target B 
      break; 
    } 
} 

что заставляет меня думать, «у меня есть объект, который имеет поля, которые я хотел бы внешний доступ изменить»

Вы можете даже использовать, если заявления, которые позволили бы определить несколько целей:

function witness(targets, param) { 
    if (targets.contains(TARGET_A) { 
     // Target A 
    } 
    if (targets.contains(TARGET_B) { 
     // Target B 
    } 
} 

Что же, как и выше в его собственном пути.

И последнее, но не в последнюю очередь, можно разделить понятие и просто дать self.incidentReport.whatYouNeed в качестве мишени:

function witness(target, param) { 
    target = param; 
} 

Но для меня это больше, так что «у меня есть неопределенное понятие объект, который должен быть задан с помощью проверки или предварительной операции ", который может представлять собой запах кода по-своему. Я не вижу проблемы с функцией setIfValid() или prepareForSet() в мире Java, но это совершенно другая возможность червей из моего опыта. Чем больше я смотрю на это, тем больше я чувствую, что все зависит от множества других факторов, которые вы должны знать как разработчика: «Я когда-нибудь добавлю больше параметров?» «Какие объекты знают, какие другие объекты?» «Должен ли я вообще ограничивать доступ?»