Nutzungsszenarien
Zustandsmuster: Wenn sich das Verhalten eines Objekts mit der Änderung des Objektzustands ändert, können wir eine abstrakte Zustandsklasse definieren, um ein Objektverhalten bereitzustellen, um mehrere Beurteilungsbedingungen zu entkoppeln und Verhaltensänderungen zu kapseln Schnittstelle. Spezifische zustandsbezogene Verhaltensweisen werden von seinen Unterklassen implementiert.
Strategiemuster: Das Wort „Strategie“ entspricht Algorithmus. Wenn Algorithmen im realen System dynamisch spezifiziert werden müssen und untereinander ersetzt werden können, kann die aufrufende Schnittstelle des Algorithmus abstrahiert werden Nach dem Liskov-Substitutionsprinzip kann überall dort, wo eine übergeordnete Klasse auftritt, ihre Unterklasse verwendet werden, um sie zu ersetzen, was unseren Geschäftsanforderungen entspricht.
Vergleich
Obwohl beide Muster die Standardaufrufschnittstelle der übergeordneten Klasse abstrahieren, das spezifische Verhalten von der Unterklasse implementiert wird und das Umgebungsobjekt auch Verweise auf die übergeordnete Klasse enthält, sind die Anwendungsszenarien der beiden Muster völlig unterschiedlich . Beispiel: Wenn Sie an einem Geldautomaten Geld abheben und Ihr Konto gesperrt ist, können Sie kein Geld mehr normal abheben. Dabei hat Ihr Bankkonto mindestens zwei Status: gesperrt und nicht gesperrt. Sie würden nicht auf die Idee kommen, das Strategiemuster zur Lösung einer solchen Geschäftslösung zu verwenden. Ein weiteres Beispiel sind Rabatte in Einkaufszentren. Auf Kinderprodukte gibt es 50 % Rabatt. Man kann nicht sagen, dass die Produkte hier einen Rabatt haben Staat und ein untergeordneter Staat!
Analyse von Geldautomaten-Abhebungsfällen
Entworfene Rollen: Kassierer, Konto, Geldautomat.
Anwendungsfalldiagramm
Der Einfachheit halber analysieren wir den Anwendungsfall für die Auszahlung.
Grundlegender Ereignispfad
(1) Der Abhebende führt die Bankkarte ein und gibt das Passwort ein;
(2) Wählt den Abhebungsvorgang aus und gibt den Abhebungsbetrag ein;
(3) Wartet auf den Bargeldeingang ausgegeben und hebt Geld ab.
Wenn in diesem Anwendungsfall das Konto des Abhebenden eingefroren wurde, tritt ein optionaler Ereignispfad auf und der Anwendungsfall Abhebung wird beendet.
Die wichtigste Geschäftsanforderung ist die Tatsache, dass der Benutzer Geld abhebt. Daher kann die Domänenmodellierung mit den beiden Klassen beginnen, die die Abhebung und die Abhebungsperson identifizieren. Unter Berücksichtigung der Tatsache, dass der Abhebende nicht nur den Anwendungsfall des Abhebens von Geld hat, verallgemeinern wir die Abhebung in eine Transaktion.
Modellierung
Use-Case-Realisierung
Entzug: Realisierung des grundlegenden Ereignispfades.
Verfeinertes Domänenmodell
Das Grenzobjekt ATMSystem wird hier als Controller eingeführt, der für die Interaktion mit Benutzern verantwortlich ist (die ATM-Betriebsschnittstelle, die mit Benutzern interagiert), und Trade ist die Klasse, die für die Verarbeitung von Benutzertransaktionen verantwortlich ist.
Der Abhebende führt die Bankkarte ein und gibt das Passwort ein. ATMSystem ist dafür verantwortlich, die Nachricht zur Überprüfung der Kontoinformationen an die Transaktionsklasse Trade weiterzuleiten, um anhand des übergebenen Kontopassworts zu überprüfen, ob der Benutzer existiert, und übergibt dann den Verarbeitungsabschluss Nachricht an das ATMSystem-Grenzobjekt, um den Benutzer widerzuspiegeln.
Einige Klassen im Analysemodell
Auszahlungsdesign – Antragsstatusmodus
Der Status des Kontos ist in einen eingefrorenen Status und einen aktivierten Status unterteilt. Das Konto kann Transaktionen durchführen, wenn es aktiviert ist, aber keine Transaktionen durchführen, wenn es gesperrt ist. Bei der Kontoverifizierung sollte der Status des aktuellen Kontos zurückgegeben werden. Wenn das Konto gesperrt ist, wird direkt eine Fehlermeldung zurückgegeben, wenn der Auszahlungsvorgang durchgeführt wird. Das Statusdiagramm wird wie folgt dargestellt:
Strukturdiagramm des Statusmodus des Auszahlungsantrags:
Wenn das Konto während der Kontoüberprüfungsphase eingefroren ist, kehrt es direkt zu DeadAccount zurück, um alle Transaktionen abzulehnen, andernfalls kehrt zu ActiveAccount zurück, um nachfolgende Transaktionen zu verarbeiten.
Schematischer Code:
Zur einfachen Implementierung wird hier das Grenzobjekt ATMSystem weggelassen.
Abstrakte Klasse für Benutzerkontoinformationen
/// <summary> /// 用户账号信息 /// </summary> public abstract class Account { /// <summary> /// 账号 /// </summary> private string account; /// <summary> /// 密码 /// </summary> private string pwd; public abstract decimal getBalance(decimal d); }
Klasse für eingefrorene Konten
/// <summary> /// 冻结账户类 /// </summary> public class DeadAccount:Account { public override decimal getBalance(decimal d) { return 0; } }
激活账户类
/// <summary> /// 激活账户类 /// </summary> public class ActiveAccount:Account { public override decimal getBalance(decimal d) { return d; } }
交易类
/// <summary> /// 交易类 负责用户交易处理的类 /// </summary> public class Trade { /// <summary> /// 保存用户账号信息 /// </summary> private Account account; public Account VolidateLogin(Account a) { //query the database to validate the user exists //For Example this.account = new DeadAccount(); return this.account; } /// <summary> /// 商业逻辑 取款 /// </summary> /// <param name="d"></param> /// <returns></returns> public decimal GetBalance(decimal d) { return this.account.getBalance(d); } }
用户类
/// <summary> /// 取款人 /// </summary> public class User { /// <summary> /// 用户账号信息 /// </summary> private Account account; /// <summary> /// 交易处理类 /// </summary> private Trade trade; public User(Account a, Trade t) { this.account = a; tthis.trade = t; } /// <summary> /// 用户登录类 /// </summary> public void Login() { trade.VolidateLogin(account); } /// <summary> /// 取款 /// </summary> /// <param name="d"></param> /// <returns></returns> public decimal GetBalance(decimal d) { return trade.GetBalance(d); } }
客户端代码
class Client { static void Main(string[] args) { //开始用户取款,默认是激活账户 ActiveAccount aa = new ActiveAccount(); Trade t = new Trade(); User u = new User(aa,t); //先登录,后取款 u.Login(); Console.WriteLine(u.GetBalance(100)); Console.ReadLine(); } }
用户必须先登录(插入银行卡,输入密码,点确定),才能选择取款业务(选择取款)。登录之后,返回的账号对象作为trade类成员,当进行取款业务的时候直接引用该账号成员获得取款信息。如果该账号属于冻结账号,则直接返回0。否则返回取款的值。
商品折扣案例
案例描述:某家超市国庆节为了促销,某些类商品打折,比如运动鞋打8折、秋装打9折等,张三去购物为了一双运动鞋、一件秋装、一瓶洗发水。。。,张三买完东西回家,心想今天自己总共“赚”了多少钱?
案例分析:商家对于商品打折可能有很多策略,这里使用策略模式,封装商品打折策略,这样以便以后扩展了打折策略,不用去修改原来的代码,具有很好的灵活性。
模式涉及的角色:
抽象策略角色:通常由一个接口或者抽象实现;
具体策略角色:包装了相关的算法和行为;
环境角色:包含抽象策略角色的引用,最终供用户使用。
商品折扣案例设计图
顾客购物涉及到的角色有:购物车、商品、收银台、抽象策略角色和具体策略角色。
购物车:是摆放商品的容器,提供添加和删除操作;
商品:商品实体,有类型,商品名、价格等属性;
收银台:负责收钱,主要是计算顾客购买所有商品的价格和折扣总额;
抽象策略角色:提供折扣策略接口。
具体策略角色:实现具体折扣算法。
商品折扣示意代码:
/// <summary> /// 具体商品类 /// </summary> public class goods { /// <summary> /// 商品类型 /// </summary> public string Type { set; get; } /// <summary> /// 商品名称 /// </summary> public string Name { get; set; } /// <summary> /// 商品价格 /// </summary> public decimal Price { get; set; } }
抽象策略角色
/// <summary> /// 抽象策略接口 /// </summary> public interface IDiscountStrategy { decimal GetDiscount(goods g); }
具体策略角色
/// <summary> /// 秋装打折策略 /// </summary> public class AutumnDressDiscountStrategy:IDiscountStrategy { #region IDiscountStrategy Members public decimal GetDiscount(goods g) { return (decimal)0.9 * g.Price; } #endregion } /// <summary> /// 运动鞋打折策略 /// </summary> public class SportShoesDiscountStrategy:IDiscountStrategy { #region IDiscountStrategy Members public decimal GetDiscount(goods g) { return g.Price * (decimal)0.8; } #endregion }
购物车
/// <summary> /// 购物车类 负责商品的维护 /// </summary> public class ShoppingCar { private List<goods> goodsList=new List<goods>(); /// <summary> /// 将商品加入到购物车 /// </summary> /// <param name="g"></param> public void AddGoods(goods g) { goodsList.Add(g); } /// <summary> /// 将商品从购物车当中移除 /// </summary> /// <param name="g"></param> public void RemoveGoods(goods g) { goodsList.Remove(g); } public List<goods> GoodsList { get { return goodsList; } } } Nach dem Login kopieren |
收银台角色
/// <summary> /// 收银台 /// </summary> public class CashierDesk { /// <summary> /// 购物车 /// </summary> private ShoppingCar shoppingCar; /// <summary> /// 策略字典 /// </summary> private Dictionary<string, IDiscountStrategy> strategies; public CashierDesk(ShoppingCar sc, Dictionary<string, IDiscountStrategy> s) { this.shoppingCar = sc; this.strategies = s; } /// <summary> /// 获得所有商品的价格 /// </summary> /// <returns></returns> public decimal GetTotalPrice() { return shoppingCar.GoodsList.Sum(p => p.Price); } /// <summary> /// 获得所有商品的总的折扣 /// </summary> /// <returns></returns> public decimal GetTotalDiscount() { decimal sum = 0; IDiscountStrategy idiscountStrategy; foreach (goods g in shoppingCar.GoodsList) { idiscountStrategy=strategies.SingleOrDefault(p => p.Key == g.Type).Value; if (idiscountStrategy != null) { sum += idiscountStrategy.GetDiscount(g); } } return sum; } }
客户端代码
class Client { static void Main(string[] args) { ShoppingCar sc = new ShoppingCar(); Dictionary<string, IDiscountStrategy> discountD = new Dictionary<string, IDiscountStrategy>(); //向购物车中加入商品 sc.AddGoods(new goods {Name="NIKE鞋 ",Price=100,Type="运动鞋" }); sc.AddGoods(new goods { Name = "秋装", Price = 200, Type = "秋装" }); sc.AddGoods(new goods { Name = "苹果", Price = 300, Type = "水果" }); //配置折扣策略 discountD.Add("运动鞋", new SportShoesDiscountStrategy()); discountD.Add("秋装", new AutumnDressDiscountStrategy()); CashierDesk cd = new CashierDesk(sc, discountD); //得到所有商品总价 Console.WriteLine(cd.GetTotalPrice()); //得到所有商品折扣价 Console.WriteLine(cd.GetTotalDiscount()); Console.ReadLine(); } }
策略模式优点与缺点:
优点
封装了算法不稳定性,易于以后业务策略的扩展。
缺点
每种策略对应于一个具体策略角色类,会增加系统需要维护的类的数量。
Das obige ist der detaillierte Inhalt vonBeispielanalyse von Strategiemustern und Zustandsmustern in Java-Entwurfsmustern. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!