随着软件系统变得更加复杂，编写模块化，灵活且易于理解的代码很重要。实现这一目标的一种方法是遵循可靠的原则。罗伯特·马丁（Robert C.
本文将概述每个可靠的原则，并通过Golang编写的示例来说明其在贸易生态系统中的应用。
单一责任原则（SRP）：该原则指出，班级应该只有一个理由改变。如果我们违反了这一原则，则班级将承担多个责任，从而使维护，测试和扩展更加困难。这可能会导致密切耦合，难以重复使用并容易出现错误的代码。
在贸易生态系统中，贸易类应负责存储和处理贸易数据。像TradeValidator这样的另一个班级可能负责根据业务规则验证交易。通过分开这些问题，每个类都可以更容易地测试和维护。
type Trade struct {
TradeID int
Symbol string
Quantity float64
Price float64
}
type TradeRepository struct {
db *sql.DB
}
func (tr *TradeRepository) Save(trade *Trade) error {
_, err := tr.db.Exec("INSERT INTO trades (trade_id, symbol, quantity, price) VALUES (?, ?, ?, ?)", trade.TradeID, trade.Symbol, trade.Quantity, trade.Price)
if err != nil {
return err
}
return nil
}
type TradeValidator struct {}
func (tv *TradeValidator) Validate(trade *Trade) error {
if trade.Quantity <= 0 {
return errors.New("Trade quantity must be greater than zero")
}
if trade.Price <= 0 {
return errors.New("Trade price must be greater than zero")
}
return nil
}
开放闭合原理（OCP）：该原理指出，应开放类别以进行扩展，但要修改。如果我们违反了此原则，我们可能必须修改现有代码以添加新功能，这可能会引入错误并使代码难以维护。这也可能导致难以测试和重复使用的代码。
在贸易生态系统中，应设计一个贸易流程师类以进行扩展，但要修改。这意味着，如果添加了新的贸易类型，那么TradeProcessor类应该能够处理它们，而无需修改现有代码。这可以通过定义用于处理交易的接口并为每种交易类型实施。
type TradeProcessor interface {
Process(trade *Trade) error
}
type FutureTradeProcessor struct {}
func (ftp *FutureTradeProcessor) Process(trade *Trade) error {
// process future trade
return nil
}
type OptionTradeProcessor struct {}
func (otp *OptionTradeProcessor) Process(trade *Trade) error {
// process option trade
return nil
}
liskov替代原理（LSP）：该原理指出，亚型应替代其基本类型。如果我们违反了这一原则，我们可能会引入出乎意料且不一致的行为，这可能导致难以追踪的错误。这也可能使编写与各种不同类型的代码很难。
在贸易生态系统中，未来的班级应该是贸易阶层的子类型，这意味着应该能够代替贸易阶层而不会引起任何问题。例如，如果交易流程师类期望贸易对象但收到未来的对象，那么它仍然应该能够在没有任何问题的情况下处理交易。
type Trade interface {
Process() error
}
type FutureTrade struct {
Trade
}
func (ft *FutureTrade) Process() error {
// process future trade
return nil
}
接口隔离原理（ISP）：该原理指出，不应强迫客户依靠他们不使用的接口。如果我们违反了这一原则，我们可能会有太大的接口，并且包含与某些客户无关的方法，这可能会导致难以理解和维护的代码。这也可能导致不可重复使用的代码，并且可能导致模块之间不必要的耦合。
在贸易生态系统中，贸易接口应仅包括与所有类型贸易相关的方法。可以创建其他接口，例如选项贸易或未来的接口，以包括特定于这些贸易类型的方法。这样，只需要使用特定类型的交易的代码就可以取决于适当的接口，而不是包含不必要方法的较大界面。
type Trade interface {
Process() error
}
type OptionTrade interface {
CalculateImpliedVolatility() error
}
type FutureTrade struct {
Trade
}
func (ft *FutureTrade) Process() error {
// process future trade
return nil
}
type OptionTrade struct {
Trade
}
func (ot *OptionTrade) Process() error {
// process option trade
return nil
}
func (ot *OptionTrade) CalculateImpliedVolatility() error {
// calculate implied volatility
return nil
}
依赖性反转原理（DIP）：该原理指出高级模块不应取决于低级模块。相反，两者都应取决于抽象。如果我们违反了这一原则，我们可能会有很难测试和重复使用的代码，并且紧密耦合。这也可能导致难以维护和扩展的代码。
在贸易生态系统中， tradeprocessor类应取决于界面，例如贸易服务，而不是诸如SQLServerTraderePository之类的具体实现。这样，可以将交易服务界面的不同实现交换而不影响TradeProcessor类，这可以使其更容易维护和测试。例如，可以使用MongodBtraderePository而不是SQLServerTraderePository而无需修改TradeProcessor类。
type TradeService interface {
Save(trade *Trade) error
}
type TradeProcessor struct {
tradeService TradeService
}
func (tp *TradeProcessor) Process(trade *Trade) error {
err := tp.tradeService.Save(trade)
if err != nil {
return err
}
// process trade
return nil
}
type SqlServerTradeRepository struct {
db *sql.DB
}
func (str *SqlServerTradeRepository) Save(trade *Trade) error {
_, err := str.db.Exec("INSERT INTO trades (trade_id, symbol, quantity, price) VALUES (?, ?, ?, ?)", trade.TradeID, trade.Symbol, trade.Quantity, trade.Price)
if err != nil {
return err
}
return nil
}
type MongoDbTradeRepository struct {
session *mgo.Session
}
func (mdtr *MongoDbTradeRepository) Save(trade *Trade) error {
collection := mdtr.session.DB("trades").C("trade")
err := collection.Insert(trade)
if err != nil {
return err
}
return nil
}
在摘要中，如果我们不使用坚实的原则，我们可能会得到难以维护，测试和重复使用的代码。这可能导致错误，性能差，并且无法为代码添加新功能。通过遵循这些原则，我们可以创建更模块化，灵活且易于理解的代码，从而可以使整体软件更好。
感谢您阅读本文。希望你会喜欢的！请拍手，分享并跟随我以支持。