2010-08-01 22 views
4

Les APIs courants sont très courants ces jours-ci. Dernièrement, je les trouve dans presque tous les systèmes avec lesquels je travaille. La plupart du temps, ils améliorent la lisibilité, mais parfois ils m'enferment dans des spécifications inflexibles, rendant la compréhension du comportement d'exécution de la spécification qu'ils construisent presque impossible. Y a-t-il un consensus sur la façon de créer une bonne API fluide? Quelles sont les meilleures façons de représenter une structure ou une spécification en utilisant une API fluide?Nouveaux styles en C#

J'ai récemment remarqué cette nouvelle variante de l'API couramment dans la classe de configuration NServiceBus:

class EndpointConfig : IConfigureThisEndpoint, AsA_Server { } 

Il utilise plusieurs interfaces comme une sorte de linéaire interface fluide. Je l'aime parce qu'il ne me place pas un lourd fardeau de code et de contexte supplémentaire quand j'essaie seulement de représenter des exigences simples. Dans des cas simples, c'est adéquat. Cependant, je n'imagine pas qu'il s'agirait de mettre à l'échelle des spécifications complexes. Que pensez-vous de cette utilisation des interfaces?

Quels autres nouveaux idiomes utilisez-vous en C#? Où les utilisez-vous? Quelles sont leurs forces? Où ne les utiliseriez-vous pas? Aussi, comment évalueriez-vous les forces d'un idiome que vous pensiez utiliser?

+6

À tout le moins, créez ce Wiki communautaire. – Joey

+1

Pourquoi? Cela ne va pas générer de réponses qui seront vraies pour tous les temps - les idiomes changent, d'où la raison pour laquelle je demande une mise à jour! –

Répondre

1

J'avais l'habitude d'éviter des paramètres booléens sur des méthodes qui ont indiqué un comportement différent, par ex. Je prendrais

int ExpensiveComputation(bool useDiskCache)

et préfèrent transformer en

int ExpensiveComputation(CacheType.DiskCache)

j'ai surtout préféré parce que lorsque vous appelez ExpensiveComputation(true), on ne sait pas ce que le true signifie sans tout savoir ExpensiveComputation, tandis que ExpensiveComputation(CacheType.DiskCache) vous donne une bonne idée.

Cependant, avec des paramètres nommés, je trouve souvent acceptable d'utiliser le premier, et l'appeler comme ceci: ExpensiveComputation(useDiskCache: true) Donc c'est un idiome récent que j'ai inventé pour moi-même.

+0

Nice. Je suppose que l'approche fluide (que je m'empresse d'ajouter est pire que ce que vous proposez) pour que cela utilise votre ancienne façon de faire mais en nommant les paramètres pour fournir la fluidité: ExpensiveCalculation (using: DiskCache); Je me demande si cela est utilisé n'importe où? –