J'écris habituellement Java, donc j'écrirai en supposant Java. Tout en évitant le goût de DDD ... (envie)
Quant à l'exemple, même «id» est l'auteur qui écrit «identifiant», donc c'est peut-être un peu exagéré, mais je pense qu'un nom long et qui transmet un sens vaut mieux qu'un nom qui ne transmet pas de signification courte. L'idéal est court (un mot si possible), donc je pense que vous devriez être conscient de la dénomination qui est plus proche de l'idéal. (Sauf pour les noms standards de facto tels que ʻi et ʻid)
class Identifier {
String value;
Identifier(String value) {
this.value = value;
}
String value() {
return value;
}
}
Je pense que les types déjà dans le langage, tels que «String» et «int », ne conviennent pas pour exprimer le concept d'une application propriétaire. Je vois souvent le code que j'essaie d'exprimer en le nommant avec des variables, etc. ** Lorsqu'un changement se produit, même le changement avec l'aide de l'EDI est une tâche gênante telle que "oublié de changer" "Typo" Ça peut être. Aussi, le mérite obtenu en définissant le type indépendamment est que ** une erreur de compilation se produit lors du passage d'un argument **, ** les objets du même concept ne sont pas définis séparément dans le code produit (réutilisation) * Je pense qu'il est préférable d'utiliser autant que possible des types, tels que *.
class Name {
String value;
Name(String value) {
this.value = value;
}
String value() {
return value;
}
}
Les gens me demandent souvent: "Pourquoi les relations publiques avec un tel nom de classe?", Mais si vous pensez que oui, c'est presque comme prévu. Ce que nous visons, c'est un sentiment d'inconfort dans lequel tout le monde est pris. En incluant l'intention de le changer plus tard dans le nom, vous pouvez jouer un rôle actif comme un commandement ** avec un nom étrange **. Je répète l'expérience que si vous lui donnez un nom comme ça, il pourrira sans être regardé, j'écris comme suit. Il faut du courage pour fusionner dans la production, mais réfléchissez à deux fois. Pouvez-vous dire que ** ce genre de nom ** et ** ce genre de traitement ** ne sont absolument rien d'autre que ce ** nom étrange **? Y a-t-il un moyen de le trouver clairement? Si vous y réfléchissez, il y aura moins de résistance. Le plus important est de lui donner un nom propre à la fin, qui est de la responsabilité de lui donner un ** nom étrange **.
//Corrigez le mot TODO lorsqu'il est trouvé
class XxxCharacter {
String value;
XxxCharacter(String value) {
this.value = value;
}
String value() {
return value;
}
}
** Loisir **. Ce qui peut être divisé en disant que la réflexion s'est arrêtée dans une certaine mesure est susceptible d'être une branche du traitement commercial, et il est facile de pousser la différence de traitement en fonction de la division, alors définissons ** pour le moment. S'ils ne correspondent pas, peut-être qu'il ne suffisait pas de les diviser et de les déclarer comme leurs propres classes, ou de penser à autre chose.
enum Gender {
NONE, MALE, FEMALE
}
La logique métier se trouve souvent dans la «couche de service», etc. dans la couche. Je pense que la «couche de service» est la couche qui écrit ** business **, pas la couche qui définit la ** logique **. Si vous voulez écrire dans la couche qui devrait être, écrivez dans la couche de domaine. La raison est très simple, car il s'agit d'une couche riche en intérêts commerciaux. Je considère chaque intérêt commercial comme une logique commerciale (peut-être un malentendu). Au fait, il est bon de protéger aussi DRY! Je suis également heureux de ce point de vue.
class Age {
int value;
Age(int value) {
this.value = value;
}
int value() {
return value;
}
boolean isMinor() {
return value < 20
}
}
Je connais ** immuable **. En effet, nous voulons limiter les responsabilités de l'objet lors de sa création et nous assurer que l'état interne ne change pas **. Ne pas écrire «Setter» est également pertinent. Si vous écrivez du code qui est facile à tolérer variable **, il a été modifié sans que personne ne le sache! Il donne une situation de ** et augmente la quantité de code qui doit être vue lors de l'exécution de tâches telles que «lire, tester et déboguer du code». Il vaut mieux avoir un nombre minimum d'endroits à voir et un endroit pour définir l'état, non? La même situation est toujours retournée, donc je pense que le fait que ce qui précède ne se produise pas vous rendra très heureux à mesure que le produit grandit. Si vous essayez par hasard de définir l'état d'une classe avec Setter, cela peut être une bonne idée d'arrêter. À proprement parler, certaines personnes disent qu'il vaut mieux ajouter le modificateur «final» pour le rendre encore plus fort, mais il est ajusté en fonction du niveau de l'équipe impliquée dans le produit. Croyant dans une certaine mesure que ** personne ne l'utiliserait de cette façon **, j'écris rarement le modificateur final, car c'est un problème à écrire. Si vous voulez en savoir plus, consultez ** Complete Constructor Pattern **.
class User {
Identifier identifier;
Name name;
Age age;
XxxCharacter xxxCharacter
Gender gender;
User(Identifier identifier, Name name, Age age, XxxCharacter xxxCharacter, Gender gender) {
this.identifier = identifier;
this.name = name;
this.age = age;
this.xxxCharacter = xxxCharacter;
this.gender = gender;
}
}
Définissez les responsabilités d'une classe très abstraite en nommant l'instanciation. Il est utilisé lorsque vous souhaitez créer une autre classe avec un faible degré d'abstraction, un index de ** ou une génération d'instance par une certaine ** différence de catégorie **. En règle générale, n'oubliez pas de rendre le constructeur privé. Sinon, le degré de liberté augmentera et une classe avec un état inattendu verra le jour. Au fait, si vous faites quelque chose de «statique» sans raison, vous pourriez être ridiculisé en tant que ** oncle statique **, alors soyez prudent.
class User {
Identifier identifier;
Name name;
Age age;
XxxCharacter xxxCharacter
Gender gender;
static User ofMale(Identifier identifier, Name name, Age age, XxxCharacter xxxCharacter,) {
return new User(identifier, name, age, xxxCharacter, Gender.MALE);
}
static User ofFemale(Identifier identifier, Name name, Age age, XxxCharacter xxxCharacter,) {
return new User(identifier, name, age, xxxCharacter, Gender.FEMAL);
}
private User(Identifier identifier, Name name, Age age, XxxCharacter xxxCharacter, Gender gender) {
this.identifier = identifier;
this.name = name;
this.age = age;
this.xxxCharacter = xxxCharacter;
this.gender = gender;
}
}
En boucle en Java, j'utilise principalement stream ou for.
En tant qu'index divers que j'utilise correctement, ** lorsque je ne lance pas d'exception, lors de la création d'un objet à partir d'un certain objet, stream **, ** en lançant une exception, en appelant simplement la méthode void séquentiellement, etc. Utilise pour **. Personnellement, j'aime stream car il peut être écrit dans une chaîne de méthodes et vous pouvez simplement voir des processus compliqués tels que des opérations intermédiaires sur des objets. D'autre part, «for» est utilisé lors de l'écriture de code dans un bloc qui n'affecte pas autant le traitement précédent. De plus, les exceptions sont plus faciles à gérer que «stream».
C'est un module tel que ʻutil, manager, helper` qui a un rôle trop large pour devenir un dieu. Il a tendance à être souvent fait quand "N'y a-t-il pas un outil pratique?" En particulier, ce dernier a de nombreux modèles qui n'affectent que celui que vous utilisez lorsqu'un changement se produit. C'était souvent un problème d'être dupé par cela comme DRY. Réfléchissez à deux fois, littéralement ** Dieu **, donc ce n'est pas quelque chose que les humains stupides peuvent gérer. Au contraire, le dieu créé par les humains n'est rien de plus qu'une ** bête démon synthétique **. Vous devriez sprinter et sprinter.
Cela ne devrait pas être offensant ... c'est celui-là. C'est très proche du code et ne donne pas plus d'informations que le code, cela ne vaut pas le format mystère par des règles mystères, peut-être beaucoup, mais ce n'est peut-être pas très bon. Les commentaires ne se compilent pas, et si vous faites une erreur, le compilateur ne vous le dira pas, il est donc facile de devenir une dette. Le code fonctionne, donc s'il est faux, il est signalé, et avec l'aide de l'EDI, je pense que c'est facile à refactoriser. Il y a deux choses auxquelles je pense lorsque je rédige un commentaire: ** Ce commentaire peut-il être bon ou mauvais **, ** Puis-je l'exprimer en code avant d'écrire ceci **? Je ne pense pas que les commentaires soient mauvais, mais les outils peuvent déterminer le chemin (par la suite) en fonction de ce que vous utilisez. J'ai souvent l'impression qu'il vaut mieux y faire face sérieusement.
Je l'ai écrit juste au-dessus, mais écrivez-vous un commentaire? Vous pourriez penser cela. Cependant, contrairement au code produit, le code de test a rarement un flux fixe et est souvent laissé à l'implémenteur, c'est donc un livre qui mêle sentiments personnels et logique. Si c'est le cas, je serai plus motivé à assumer la responsabilité de l'explication. Oh, peu importe ** Le test est une spécification! J'entends souvent **, mais est-ce vrai? Chaque jour, je deviens méfiant.
Nous prévoyons d'en ajouter d'autres à l'avenir. J'ai peur de Masakari, alors j'insiste fortement sur ** I **. Cependant, j'apprécierais vos commentaires, qu'ils soient bons ou mauvais.