Normalerweise schreibe ich Java, also schreibe ich unter der Annahme von Java. Unter Vermeidung des DDD-ähnlichen Geschmacks ... (Wunsch)
In Bezug auf das Beispiel mag es ein wenig übertrieben sein, weil ich "bezeichner" sogar für "id" schreibe, aber ich denke, dass ein Name, der lang ist und Bedeutung vermittelt, besser ist als ein Name, der keine kurze Bedeutung vermittelt. Das Ideal ist kurz (wenn möglich ein Wort), daher sollten Sie sich der Benennung bewusst sein, die dem Ideal näher kommt. (Mit Ausnahme von De-facto-Standardnamen wie "i" und "id")
class Identifier {
String value;
Identifier(String value) {
this.value = value;
}
String value() {
return value;
}
}
Ich bin der Meinung, dass bereits in der Sprache vorhandene Typen wie "String" und "int" nicht geeignet sind, das Konzept einer proprietären Anwendung auszudrücken. Ich sehe oft den Code, den ich auszudrücken versuche, indem ich ihn mit Variablen usw. benenne. ** Wenn eine Änderung auftritt, ist selbst die Änderung mit Hilfe der IDE eine mühsame Aufgabe wie "vergessen, zu ändern" "Tippfehler". Es kann sein. Der Vorteil, der durch das unabhängige Definieren des Typs erzielt wird, besteht auch darin, dass ** ein Kompilierungsfehler auftritt, wenn ein Argument übergeben wird **, ** Objekte desselben Konzepts nicht separat im Produktcode definiert werden (Wiederverwendung) * Ich denke, es ist am besten, so viele Typen wie möglich zu verwenden, wie z. B. *.
class Name {
String value;
Name(String value) {
this.value = value;
}
String value() {
return value;
}
}
Die Leute fragen mich oft: "Warum macht PR so einen Klassennamen?", Aber wenn Sie so denken, ist es fast wie erwartet. Was wir anstreben, ist ein Gefühl des Unbehagens, in das sich alle hineinversetzen. Indem Sie die Absicht, es später zu ändern, in den Namen aufnehmen, können Sie eine aktive Rolle wie ein Gebot ** mit einem seltsamen Namen ** spielen. Ich wiederhole die Erfahrung, dass, wenn Sie ihm einen solchen Namen geben, er verrotten wird, ohne angeschaut zu werden. Ich schrieb wie folgt. Es braucht Mut, sich in die Produktion zu integrieren, aber überlegen Sie es sich zweimal. Kannst du sagen, dass ** diese Art von Namen ** und ** diese Art von Verarbeitung ** absolut nichts anderes sind als dieser ** seltsame Name **? Gibt es eine Möglichkeit, es klar zu finden? Wenn Sie darüber nachdenken, wird es weniger Widerstand geben. Das Wichtigste ist, ihm am Ende einen richtigen Namen zu geben, was in der Verantwortung liegt, ihm einen ** seltsamen Namen ** zu geben.
//Korrigieren Sie das TODO-Wort, wenn es gefunden wird
class XxxCharacter {
String value;
XxxCharacter(String value) {
this.value = value;
}
String value() {
return value;
}
}
** Hobby **. Was geteilt werden kann, während gesagt wird, dass das Denken bis zu einem gewissen Grad aufgehört hat, ist wahrscheinlich ein Zweig der Geschäftsverarbeitung, und es ist leicht, den Unterschied in der Verarbeitung in Abhängigkeit von der Teilung zu verschieben. Definieren wir also vorerst **. Wenn sie nicht übereinstimmen, war es vielleicht nicht genug, sie zu teilen und als ihre eigenen Klassen zu deklarieren oder an etwas anderes zu denken.
enum Gender {
NONE, MALE, FEMALE
}
Geschäftslogik findet sich oft in der "Serviceschicht" usw. in der Schicht. Ich denke, die "Service-Schicht" ist die Schicht, die ** Geschäft ** schreibt, nicht die Schicht, die ** Logik ** definiert. Wenn Sie in die Ebene schreiben möchten, die sein soll, schreiben Sie in die "Domänenebene". Der Grund ist sehr einfach, da es sich um eine Schicht voller Geschäftsinteressen handelt. Ich betrachte jedes Geschäftsinteresse als Geschäftslogik (vielleicht ein Missverständnis). Übrigens ist es auch gut, DRY zu schützen! Ich bin auch aus dieser Perspektive glücklich.
class Age {
int value;
Age(int value) {
this.value = value;
}
int value() {
return value;
}
boolean isMinor() {
return value < 20
}
}
Mir ist ** unveränderlich ** bekannt. Dies liegt daran, dass wir die Verantwortlichkeiten des Objekts beim Erstellen einschränken und sicherstellen möchten, dass sich der interne Status nicht ändert **. Das Nichtschreiben von "Setter" ist ebenfalls relevant. Wenn Sie Code schreiben, der eine Variable ** leicht toleriert, wurde er geändert, ohne dass es jemand weiß! Dies ergibt eine Situation von ** und erhöht die Menge an Code, die beim Ausführen von Aufgaben wie "Lesen, Testen und Debuggen von Code" angezeigt werden muss. Es ist besser, eine Mindestanzahl von Orten zu sehen und einen Ort, um den Zustand zu definieren, oder? Die gleiche Situation wird immer wieder zurückgegeben, daher denke ich, dass die Tatsache, dass dies nicht der Fall ist, Sie sehr glücklich macht, wenn das Produkt wächst. Wenn Sie beiläufig versuchen, den Status einer Klasse mit "Setter" zu definieren, ist es möglicherweise eine gute Idee, aufzuhören. Genau genommen sagen einige Leute, dass es besser ist, den Modifikator "final" hinzuzufügen, um ihn noch stärker zu machen, aber er wird entsprechend der Ebene des an dem Produkt beteiligten Teams angepasst. Ich glaube bis zu einem gewissen Grad, dass ** niemand es so verwenden würde **, und schreibe selten den Modifikator "final", weil das Schreiben mühsam ist. Wenn Sie mehr wissen möchten, lesen Sie ** Vollständiges Konstruktormuster **.
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;
}
}
Definieren Sie die Verantwortlichkeiten einer sehr abstrakten Klasse, indem Sie die Instanziierung benennen. Es wird verwendet, wenn Sie eine andere Klasse mit einem geringen Abstraktionsgrad, einem Index von ** oder einer Instanzgenerierung durch einen bestimmten ** Kategoriedifferenz ** erstellen möchten. Vergessen Sie in der Regel nicht, den Konstruktor "privat" zu machen. Andernfalls erhöht sich der Freiheitsgrad und eine Klasse mit einem unerwarteten Zustand wird geboren. Übrigens, wenn Sie ohne Grund etwas "Statisches" machen, werden Sie möglicherweise als "statischer Onkel" verspottet. Seien Sie also bitte vorsichtig.
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;
}
}
Beim Looping in Java verwende ich hauptsächlich "stream" oder "for".
Als sonstiger Index, den ich richtig verwende, ** wenn ich keine Ausnahme auslöse, wenn ich ein Objekt aus einem bestimmten Objekt erstelle, stream **, ** wenn ich eine Ausnahme auslöse, wenn ich nur die void-Methode nacheinander aufrufe usw. Verwendet für **. Ich persönlich mag stream, weil es in einer Methodenkette geschrieben werden kann und Sie einfach komplizierte Prozesse wie Zwischenoperationen an Objekten sehen können. Andererseits wird "for" verwendet, wenn Code in einen Block geschrieben wird, der die vorherige Verarbeitung nicht so stark beeinflusst. Ausnahmen sind auch einfacher zu handhaben als "Stream".
Es ist ein Modul wie "util", "manager", "helper", das eine zu große Rolle spielt, um ein Gott zu werden. Es wird häufig gemacht, wenn "Ich frage mich, ob es ein praktisches Werkzeug gibt" oder "Es ist schwer zu ändern und Doppelarbeit vorerst zu vermeiden". Insbesondere hat letzteres viele Muster, die nur das betreffen, das Sie verwenden, wenn eine Änderung auftritt. Es war oft ein Problem, sich als DRY täuschen zu lassen. Überlegen Sie zweimal, buchstäblich ** Gott **, also ist es nicht etwas, mit dem dumme Menschen umgehen können. Vielmehr ist der von Menschen geschaffene Gott nichts anderes als ein ** synthetisches Dämonentier **. Du solltest sprinten und sprinten.
Es sollte nicht beleidigend sein ... es ist das eine. Es ist sehr nah am Code und gibt nicht mehr Informationen als der Code. Es ist das Mystery-Format nach Mystery-Regeln nicht wert, vielleicht viel, aber es ist möglicherweise nicht sehr gut. Kommentare werden nicht kompiliert, und wenn Sie einen Fehler machen, werden Sie vom Compiler nicht informiert, sodass es leicht ist, Schulden zu machen. Der Code funktioniert. Wenn er falsch ist, wird darauf hingewiesen, und mit Hilfe der IDE ist es meiner Meinung nach einfach, ihn umzugestalten. Beim Schreiben eines Kommentars denke ich an zwei Dinge: ** Kann dieser Kommentar gut oder schlecht sein **, ** Kann ich ihn vor dem Schreiben im Code ausdrücken **? Ich denke nicht, dass die Kommentare schlecht sind, aber die Tools können den Weg (danach) bestimmen, je nachdem, was Sie verwenden. Ich habe oft das Gefühl, dass es besser ist, sich ernsthaft damit auseinanderzusetzen.
Ich habe es direkt oben geschrieben, aber schreibst du einen Kommentar? Das könnte man denken. Im Gegensatz zum Produktcode hat der Testcode jedoch selten einen festen Ablauf und wird häufig dem Implementierer überlassen. Daher handelt es sich um ein Buch, das persönliche Gefühle und Logik miteinander verbindet. Wenn ja, werde ich motivierter sein, die Verantwortung für die Erklärung zu übernehmen. Oh, das spielt keine Rolle ** Der Test ist eine Spezifikation! Ich höre oft **, aber ist das so? Jeden Tag werde ich misstrauisch.
Wir planen, in Zukunft weitere hinzuzufügen. Ich habe Angst vor Masakari, deshalb betone ich ** I ** nachdrücklich. Ich würde mich jedoch über Ihr Feedback freuen, unabhängig davon, ob es gut oder schlecht ist.
Recommended Posts