API semplificata una case case vs case study ADT robusta e multipla? [duplicare]

Question

API semplificata una case case vs case study ADT robusta e multipla? [duplicare]

#1 da (0 voti)

1

Qui di seguito sono esempi semplificati, ma mi chiedo quale strada intraprendere quale è la migliore pratica quando si progetta l'API, il semplice o il più complesso e robusto che è meglio?

Questo sembra buono e va di pari passo con i concetti di scala ADT, ma temo che diventerebbe eccessivamente complesso e i client che usano la mia API mi odieranno un po 'per complicarli con troppi oggetti per pensare a cosa passare alla mia interfaccia. / p>

trait ProcessUpdate {
  def name: String
  def id: String
  def message: String
}

case class SuccessProcessUpdate(name: String, id: String, message: String) extends ProcessUpdate
case class FailureProcessUpdate(name: String, id: String, message: String, e: Exception) ProcessUpdate

def success(successUpdate: SuccessProcessUpdate)
def fail(failUpdate: FailureProcessUpdate)

Questo è semplice, penso che quelli che usano questa API mi apprezzeranno meglio, ma non sono sicuro che sia abbastanza robusto.

trait ProcessUpdate {
  def name: String
  def id: String
  def message: String
  def e: Option[Exception]
} 

case class ProcessUpdateInfo(name: String, id: String, message: String, e: Option[Exception])

def update(processUpdate: ProcessUpdate)

Che ne pensi? c'è una risposta giusta? questo esempio è stato semplicistico, più la cosa è complessa più difficile è la domanda.

design architecture functional-programming scala

posta Jas 20.07.2017 - 09:19

fonte

1 risposta

Leggi altre domande sui tag design architecture functional-programming scala

Quale linguaggio di programmazione ha utilizzato per la prima volta l'operatore di navigazione sicura (?.)? Qual è l'approccio migliore a un tema personalizzabile in SPA Architecture

score 0 · Accepted Answer

Senza saperne di più sullo scopo del tuo programma o sui casi d'uso, di solito seguo un modello di implementazione per ADT in questo modo:

sealed trait ProcessUpdate

final case class SuccessProcessUpdate(
  name: String, 
  id: String, 
  message: String
) extends ProcessUpdate

final case class FailureProcessUpdate(
  name: String, 
  id: String, 
  message: String, 
  exception: Exception
b) extends ProcessUpdate

def update(processUpdate: ProcessUpdate) = processUpdate match {
  case SuccessProcessUpdate(name, id, message) => // do something
  case FailureProcessUpdate(name, id, message, exception) => // do something else
}

Potresti specificare i campi in ProcessUpdate , ma usando tratti sigillati, non è necessario specificarlo nella caratteristica, e ogni classe di case che estende ProcessUpdate può sembrare completamente diversa. Puoi gestire ogni specifica implementazione utilizzando la corrispondenza del modello come mostrato sopra. Se non hai bisogno di tanta complessità, allora rinuncerei completamente alla caratteristica e la implementerò in questo modo:

final case class ProcessUpdate(
  name: String, 
  id: String, 
  message: String, 
  exception: Option[Exception] = None // use default to allow shorter syntax
)

def update(processUpdate: ProcessUpdate) = processUpdate.exception.fold {
  // success case
} { exception =>
  // failure case
}