Ich habe es in der Sprache Go geschrieben, um das SOLID-Prinzip zu verstehen

Über das SOLID-Prinzip

Was ist das SOLID-Prinzip?

--SRP (Single Responsibility Prinzip) --OCP (offenes / geschlossenes Prinzip)

• LSP (Riskovs Ersatzprinzip) --ISP (Prinzip der Schnittstellentrennung) --DIP (Prinzip der Umkehrung der Abhängigkeit)

Es ist eine Abkürzung für.

Warum SOLID Prinzip?

Der Grund für die Anwendung von SOLID ist

--Resistent gegen Veränderung --Einfach zu verstehen

• Verfügbar in vielen Softwaresystemen

Kann erwähnt werden. Im Folgenden werde ich auf die Erläuterung der einzelnen Prinzipien und des Codes eingehen.

Über jedes Prinzip von SOLID

SRP (Prinzip der Einzelhaftung)

Erläuterung

Das Prinzip, dass es beim Ändern eines Moduls, einer Klasse, einer Funktion usw. keine mehrfachen Gründe geben sollte. Der Grund besteht darin, das Auftreten der folgenden Ereignisse zu verhindern

• Zusammenführungen und Konflikte treten auf, wenn mehrere Personen eine Quelldatei ändern
• Die Änderungen werden durch unerwartete Dinge beeinflusst

Code

schlechtes Beispiel

Eine Schnittstelle hat mehrere Verantwortlichkeiten für die Verwaltung von Mitarbeitern und die Speicherung von Mitarbeiterdaten.

type EmployeeWorkManage interface {
	calculatePay()
	reportHours()
	saveEmployee()
}

Nach der Verbesserung

Erstellen Sie separate Schnittstellen für die Verwaltung von Mitarbeitern und die Speicherung von Mitarbeiterdaten, sodass jeder eine Verantwortung trägt.

type EmployeeWorkManage interface {
	calculatePay()
	reportHours()
}

type EmployeeDataManage interface {
	saveEmployee()
}

OCP (offenes / geschlossenes Prinzip)

Erläuterung

Das Prinzip, dass es für Software-Erweiterungen geöffnet und für Änderungen geschlossen sein muss Auf diese Weise können Sie Ihr System skalieren, ohne von Änderungen betroffen zu sein.

Code

Durch Erstellen einer Schnittstelle mit dem Namen Tier und Erstellen einer Hundetyp- oder Katzentypmethode kann die Rindenmethode ausgeführt werden, ohne sich im Hauptprozess um den Hundetyp oder den Katzentyp zu kümmern. Wenn Sie einen neuen Vogel erstellen möchten, müssen Sie ihn nur hinzufügen, indem Sie ihn von der Tieroberfläche abhängig machen.

package main
import(
	"fmt"
)

type Animal interface {
	bark()
	eat()
}

type Dog struct {}

type Cat struct {}

func (d Dog) bark(){
	fmt.Println("Bow-wow")
}

func (d Dog) eat(){
	fmt.Println("Bakubaku")
}

func (c Cat) bark(){
	fmt.Println("Miau")
}

func (c Cat) eat(){
	fmt.Println("Mushamsha")
}

func main(){
	dog := Dog{}
	cat := Cat{}

	animals := []Animal{dog, cat}
	
	for _, animal := range animals {
		animal.bark()
	}

}

LSP (Riskovs Ersatzprinzip)

Erläuterung

Objekt vom Typ S: o1 T-Objekt: o2 Das Prinzip, dass S eine Ableitung von T ist, wenn sich irgendwann das Verhalten von P nicht ändert, wenn o1 anstelle von o2 für das mit T definierte Programm P verwendet wird.

Code

Da Go keine Vererbung hat, verstößt es nicht gegen das Ersatzprinzip von Riskoff und ist nicht bewusst (?)

ISP (Prinzip der Schnittstellentrennung)

Erläuterung

Das Prinzip, Sie nicht zu zwingen, sich auf unnötige Schnittstellen zu verlassen Gruppieren Sie nur relevante Schnittstellen und verlieren Sie die Abhängigkeit nicht verwendeter Methoden.

Code

schlechtes Beispiel

Wenn Sie versuchen, einen Humanoiden aus der Tierschnittstelle zu erstellen, wie unten gezeigt, müssen Sie die Flugmethode beschreiben, die Sie nicht verwenden.

type AnimalInterface interface {
	fly()
	run()
	swim()
}

Nach der Verbesserung

Trennen Sie die Schnittstelle von Bird Interface für Vögel und Human Interface für Menschen. Auf diese Weise müssen Sie keine unnötigen Methoden schreiben.

type BirdInterface interface {
	fly()
}

type HumanInterface interface {
	run()
	swim()
}

type Bird struct {}
type Human struct{}

func (b Bird) fly(){
	fmt.Println("Fliege! !!")
}

func (h Human) run(){
	fmt.Println("Ich werde laufen ~")
}

func (h Human) swim(){
	fmt.Println("Schwimmen ~")
}

func main(){
	bird := Bird{}
	human := Human{}

	bird.fly()
	human.run()
}

DIP (Dependency Reversal Principle)

Erläuterung

Das Prinzip, sich nicht auf konkrete Module zu verlassen, die häufig geändert werden (Module, in denen Funktionsimplementierungen geschrieben sind) Vermeiden Sie es, sich auf veränderbare Konkretheit zu verlassen, und verlassen Sie sich auf eine stabile abstrakte Schnittstelle. Verwenden Sie das Abstract Factory-Muster, um auf die abstrakte Schnittstelle zu verweisen.

Code

Wenn Sie sich auf Abstract Factory verlassen, ist die Abhängigkeit wie in der Abbildung gezeigt, und die Benutzerdaten können erfasst werden, ohne sich um DB oder Text kümmern zu müssen.

package main
import(
	"fmt"
)

type User struct {
	id int
	name string
}

type AbstractFactory interface {
	getData() User
}

type DbManage struct {}

func (db DbManage) getData() User {
	return User{1, "DB TARO"}
}

type TextManage struct {}

func (text TextManage) getData() User {
	return User{2, "TEXT JIRO"}
}

func getUserData(manageType string) User {
	var manageFactry AbstractFactory
	switch manageType {
	case "DB":
		manageFactry = DbManage{}
		return manageFactry.getData()
	case "TEXT":
		manageFactry = TextManage{}
		return manageFactry.getData()
	default:
		return User{3, "Anonym"}
	}
}

func main(){
	user := getUserData("DB")
	fmt.Println(user.id, user.name)
}

Referenz

https://labs.septeni.co.jp/entry/2017/02/21/164127 https://maroyaka.hateblo.jp/entry/2017/05/22/165355 https://qiita.com/shunp/items/646c86bb3cc149f7cff9 https://golangvedu.wordpress.com/2017/01/31/golang-design-pattern-abstract-factory-and-factory-method/

Schließlich

Irgendwie habe ich das Gefühl, das SOLID-Prinzip zu verstehen. Wenn Sie Fragen oder Anregungen haben, würden wir uns freuen, wenn Sie diese in die Kommentare schreiben könnten.