GOF で文書化されているように、Decorator Patternを研究していました。
装飾パターンの理解を助けてください。誰かがこれが実際の世界で役立つ場所のユースケースの例を挙げることができますか?
装飾パターンは、オブジェクトに責任を動的に追加するという単一の目的を達成します。
ピザ屋の場合を考えてみましょう。ピザショップでは、数種類のピザを販売し、メニューにトッピングも提供します。ここで、ピザ店がピザとトッピングの各組み合わせの価格を提供する必要がある場合を想像してください。 4つの基本的なピザと8つの異なるトッピングがある場合でも、アプリケーションはピザとトッピングのこれらの具体的な組み合わせすべてを維持するのに夢中になります。
ここにデコレータパターンがあります。
デコレータパターンに従って、デコレータとしてトッピングを実装し、ピザはそれらのトッピングのデコレータによって装飾されます。実際には、各顧客は自分の欲望のトッピングを望み、最終的な請求額はベースのピザと追加注文のトッピングで構成されます。各トッピングデコレータは、飾っているピザとその価格について知っています。 ToppingオブジェクトのGetPrice()メソッドは、ピザとトッピングの両方の累積価格を返します。
上記の説明のコード例を次に示します。
public abstract class BasePizza
{
protected double myPrice;
public virtual double GetPrice()
{
return this.myPrice;
}
}
public abstract class ToppingsDecorator : BasePizza
{
protected BasePizza pizza;
public ToppingsDecorator(BasePizza pizzaToDecorate)
{
this.pizza = pizzaToDecorate;
}
public override double GetPrice()
{
return (this.pizza.GetPrice() + this.myPrice);
}
}
class Program
{
[STAThread]
static void Main()
{
//Client-code
Margherita pizza = new Margherita();
Console.WriteLine("Plain Margherita: " + pizza.GetPrice().ToString());
ExtraCheeseTopping moreCheese = new ExtraCheeseTopping(pizza);
ExtraCheeseTopping someMoreCheese = new ExtraCheeseTopping(moreCheese);
Console.WriteLine("Plain Margherita with double extra cheese: " + someMoreCheese.GetPrice().ToString());
MushroomTopping moreMushroom = new MushroomTopping(someMoreCheese);
Console.WriteLine("Plain Margherita with double extra cheese with mushroom: " + moreMushroom.GetPrice().ToString());
JalapenoTopping moreJalapeno = new JalapenoTopping(moreMushroom);
Console.WriteLine("Plain Margherita with double extra cheese with mushroom with Jalapeno: " + moreJalapeno.GetPrice().ToString());
Console.ReadLine();
}
}
public class Margherita : BasePizza
{
public Margherita()
{
this.myPrice = 6.99;
}
}
public class Gourmet : BasePizza
{
public Gourmet()
{
this.myPrice = 7.49;
}
}
public class ExtraCheeseTopping : ToppingsDecorator
{
public ExtraCheeseTopping(BasePizza pizzaToDecorate)
: base(pizzaToDecorate)
{
this.myPrice = 0.99;
}
}
public class MushroomTopping : ToppingsDecorator
{
public MushroomTopping(BasePizza pizzaToDecorate)
: base(pizzaToDecorate)
{
this.myPrice = 1.49;
}
}
public class JalapenoTopping : ToppingsDecorator
{
public JalapenoTopping(BasePizza pizzaToDecorate)
: base(pizzaToDecorate)
{
this.myPrice = 1.49;
}
}
これは、新しい動作を既存のオブジェクトに動的に追加する簡単な例、またはDecoratorパターンです。 Javascriptなどの動的言語の性質により、このパターンは言語自体の一部になります。
// Person object that we will be decorating with logging capability
var person = {
name: "Foo",
city: "Bar"
};
// Function that serves as a decorator and dynamically adds the log method to a given object
function MakeLoggable(object) {
object.log = function(property) {
console.log(this[property]);
}
}
// Person is given the dynamic responsibility here
MakeLoggable(person);
// Using the newly added functionality
person.log('name');
Java i/oモデルはデコレーターパターンに基づいていることに注意してください。このリーダーの上にこのリーダーを重ねることは、デコレーターの実世界の例です。
例-シナリオ-暗号化モジュールを書いているとしましょう。この暗号化は、DES-データ暗号化標準を使用してクリアファイルを暗号化できます。同様に、システムでは、暗号化をAES-Advance暗号化標準として使用できます。また、暗号化の組み合わせ(最初のDES、次にAES)を使用できます。または、最初にAES、次にDESを使用できます。
ディスカッション-この状況にどのように対応しますか?このような組み合わせのオブジェクトを作成し続けることはできません-たとえば-AESとDES-合計4つの組み合わせ。したがって、4つの個別のオブジェクトが必要になります。これは、暗号化の種類が増えるにつれて複雑になります。
解決策-実行時に、必要に応じて組み合わせてスタックを構築し続けます。このスタックアプローチのもう1つの利点は、簡単に解くことができることです。
ここに解決策があります-C++。
まず、基本クラス、つまりスタックの基本単位が必要です。スタックのベースと考えることができます。この例では、クリアファイルです。常にポリモーフィズムを追いましょう。まず、この基本ユニットのインターフェイスクラスを作成します。このように、あなたは望むようにそれを実装することができます。また、この基本単位を含める際に依存関係について考える必要はありません。
これがインターフェースクラスです-
class IclearData
{
public:
virtual std::string getData() = 0;
virtual ~IclearData() = 0;
};
IclearData::~IclearData()
{
std::cout<<"Destructor called of IclearData"<<std::endl;
}
次に、このインターフェイスクラスを実装します-
class clearData:public IclearData
{
private:
std::string m_data;
clearData();
void setData(std::string data)
{
m_data = data;
}
public:
std::string getData()
{
return m_data;
}
clearData(std::string data)
{
setData(data);
}
~clearData()
{
std::cout<<"Destructor of clear Data Invoked"<<std::endl;
}
};
ここで、デコレータ抽象クラスを作成してみましょう-これを拡張して、あらゆる種類のフレーバーを作成できます-ここで、フレーバーは暗号化タイプです。このデコレータ抽象クラスは、基本クラスに関連しています。したがって、デコレータはインターフェイスクラスの一種です。したがって、継承を使用する必要があります。
class encryptionDecorator: public IclearData
{
protected:
IclearData *p_mclearData;
encryptionDecorator()
{
std::cout<<"Encryption Decorator Abstract class called"<<std::endl;
}
public:
std::string getData()
{
return p_mclearData->getData();
}
encryptionDecorator(IclearData *clearData)
{
p_mclearData = clearData;
}
virtual std::string showDecryptedData() = 0;
virtual ~encryptionDecorator() = 0;
};
encryptionDecorator::~encryptionDecorator()
{
std::cout<<"Encryption Decorator Destructor called"<<std::endl;
}
それでは、具体的なデコレータクラスを作成しましょう-暗号化タイプ-AES-
const std::string aesEncrypt = "AES Encrypted ";
class aes: public encryptionDecorator
{
private:
std::string m_aesData;
aes();
public:
aes(IclearData *pClearData): m_aesData(aesEncrypt)
{
p_mclearData = pClearData;
m_aesData.append(p_mclearData->getData());
}
std::string getData()
{
return m_aesData;
}
std::string showDecryptedData(void)
{
m_aesData.erase(0,m_aesData.length());
return m_aesData;
}
};
ここで、デコレータのタイプがDESであるとしましょう-
const std :: string desEncrypt = "DES Encrypted";
class des: public encryptionDecorator
{
private:
std::string m_desData;
des();
public:
des(IclearData *pClearData): m_desData(desEncrypt)
{
p_mclearData = pClearData;
m_desData.append(p_mclearData->getData());
}
std::string getData(void)
{
return m_desData;
}
std::string showDecryptedData(void)
{
m_desData.erase(0,desEncrypt.length());
return m_desData;
}
};
このデコレータクラスを使用するクライアントコードを作成しましょう-
int main()
{
IclearData *pData = new clearData("HELLO_CLEAR_DATA");
std::cout<<pData->getData()<<std::endl;
encryptionDecorator *pAesData = new aes(pData);
std::cout<<pAesData->getData()<<std::endl;
encryptionDecorator *pDesData = new des(pAesData);
std::cout<<pDesData->getData()<<std::endl;
/** unwind the decorator stack ***/
std::cout<<pDesData->showDecryptedData()<<std::endl;
delete pDesData;
delete pAesData;
delete pData;
return 0;
}
次の結果が表示されます-
HELLO_CLEAR_DATA
Encryption Decorator Abstract class called
AES Encrypted HELLO_CLEAR_DATA
Encryption Decorator Abstract class called
DES Encrypted AES Encrypted HELLO_CLEAR_DATA
AES Encrypted HELLO_CLEAR_DATA
Encryption Decorator Destructor called
Destructor called of IclearData
Encryption Decorator Destructor called
Destructor called of IclearData
Destructor of clear Data Invoked
Destructor called of IclearData
UML図は次のとおりです-クラス表現。場合によっては、コードをスキップして、デザインの側面に焦点を合わせたいと思います。
デコレータパターンは、このオブジェクトの他の同様のサブクラスとチェーンすることにより、オブジェクトの機能を変更または構成するのに役立ちます。
最良の例は、Java.ioパッケージのInputStreamおよびOutputStreamクラスです
File file=new File("target","test.txt");
FileOutputStream fos=new FileOutputStream(file);
BufferedOutputStream bos=new BufferedOutputStream(fos);
ObjectOutputStream oos=new ObjectOutputStream(bos);
oos.write(5);
oos.writeBoolean(true);
oos.writeBytes("decorator pattern was here.");
//... then close the streams of course.
私は仕事でデコレータパターンを広範囲に使用しました。 私のブログに投稿 ロギングでの使用方法について作成しました。
Javaのデコレータデザインパターンとは何ですか。
GoFブックのデコレーターパターンの正式な定義(デザインパターン:再利用可能なオブジェクト指向ソフトウェアの要素、1995、Pearson Education、Inc. Publishing as Pearson Addison Wesley)は、次のことができると述べています。
「オブジェクトに追加の責任を動的に付加します。デコレータは、機能を拡張するためのサブクラス化の柔軟な代替手段を提供します。」
ピザがあり、チキンマサラ、オニオン、モッツァレラチーズなどのトッピングで飾りたいとしましょう。 Javaで実装する方法を見てみましょう...
Javaでデコレータデザインパターンを実装する方法を示すプログラム。
Pizza.Java:
<!-- language-all: lang-html -->
package com.hubberspot.designpattern.structural.decorator;
public class Pizza {
public Pizza() {
}
public String description(){
return "Pizza";
}
}
package com.hubberspot.designpattern.structural.decorator;
public abstract class PizzaToppings extends Pizza {
public abstract String description();
}
package com.hubberspot.designpattern.structural.decorator;
public class ChickenMasala extends PizzaToppings {
private Pizza pizza;
public ChickenMasala(Pizza pizza) {
this.pizza = pizza;
}
@Override
public String description() {
return pizza.description() + " with chicken masala, ";
}
}
package com.hubberspot.designpattern.structural.decorator;
public class MozzarellaCheese extends PizzaToppings {
private Pizza pizza;
public MozzarellaCheese(Pizza pizza) {
this.pizza = pizza;
}
@Override
public String description() {
return pizza.description() + "and mozzarella cheese.";
}
}
package com.hubberspot.designpattern.structural.decorator;
public class Onion extends PizzaToppings {
private Pizza pizza;
public Onion(Pizza pizza) {
this.pizza = pizza;
}
@Override
public String description() {
return pizza.description() + "onions, ";
}
}
package com.hubberspot.designpattern.structural.decorator;
public class TestDecorator {
public static void main(String[] args) {
Pizza pizza = new Pizza();
pizza = new ChickenMasala(pizza);
pizza = new Onion(pizza);
pizza = new MozzarellaCheese(pizza);
System.out.println("You're getting " + pizza.description());
}
}
デコレーター:
詳細については、 sourcemaking の記事を参照してください。
Decorator(Abstract):コンポーネントインターフェイスを実装する抽象クラス/インターフェイスです。コンポーネントインターフェイスが含まれています。このクラスが存在しない場合、さまざまな組み合わせに対してConcreteDecoratorsの多くのサブクラスが必要です。コンポーネントの構成により、不必要なサブクラスが削減されます。
JDKの例:
BufferedInputStream bis = new BufferedInputStream(new FileInputStream(new File("a.txt")));
while(bis.available()>0)
{
char c = (char)bis.read();
System.out.println("Char: "+c);;
}
UMLの図とコード例については、以下のSEの質問をご覧ください。
有用な記事:
デコレーターパターンの実際の単語の例:VendingMachineDecoratorは説明されています@
Beverage beverage = new SugarDecorator(new LemonDecorator(new Tea("Assam Tea")));
beverage.decorateBeverage();
beverage = new SugarDecorator(new LemonDecorator(new Coffee("Cappuccino")));
beverage.decorateBeverage();
上記の例では、紅茶またはコーヒー(飲料)は砂糖とレモンで装飾されています。
デコレータパターンを使用すると、オブジェクトに動作を動的に追加できます。
さまざまな種類のハンバーガーの価格を計算するアプリを作成する必要がある例を見てみましょう。 「ラージ」や「チーズ入り」など、さまざまな種類のハンバーガーを処理する必要があります。それぞれが基本的なハンバーガーに比べて価格があります。例えば。チーズ入りのハンバーガーに10ドルを追加し、ラージバーガーに15ドルを追加します。
この場合、これらを処理するサブクラスを作成したくなるかもしれません。これはRubyで次のように表現できます。
class Burger
def price
50
end
end
class BurgerWithCheese < Burger
def price
super + 15
end
end
上記の例では、BurgerWithCheeseクラスはBurgerを継承し、priceメソッドをオーバーライドして、スーパークラスで定義された価格に$ 15を追加します。また、LargeBurgerクラスを作成し、Burgerに対する価格を定義します。ただし、「大」と「チーズ入り」の組み合わせに対して新しいクラスを定義する必要もあります。
「ハンバーガーとフライドポテト」を提供する必要がある場合、どうなりますか?これらの組み合わせを処理するための4つのクラスが既にあり、3つのプロパティ(「大」、「チーズ付き」、「フライドポテト」)のすべての組み合わせを処理するには、さらに4つ追加する必要があります。今8つのクラスが必要です。別のプロパティを追加すると、16が必要になります。これは2 ^ nになります。
代わりに、Burgerオブジェクトを取り込むBurgerDecoratorを定義してみましょう。
class BurgerDecorator
def initialize(burger)
self.burger = burger
end
end
class BurgerWithCheese < BurgerDecorator
def price
self.burger.price + 15
end
end
burger = Burger.new
cheese_burger = BurgerWithCheese.new(burger)
cheese_burger.price # => 65
上記の例では、BurgerWithCheeseクラスが継承するBurgerDecoratorクラスを作成しました。 LargeBurgerクラスを作成することで、「大きな」バリエーションを表すこともできます。これで、実行時にチーズを含む大きなハンバーガーを次のように定義できます。
b = LargeBurger.new(cheese_burger)
b.price # => 50 + 15 + 20 = 85
継承を使用して「with fries」バリエーションを追加すると、さらに4つのサブクラスが追加されることを覚えていますか?デコレーターを使用して、新しいバリエーションを処理し、実行時にこれを処理するために、BurgerWithFriesという新しいクラスを1つ作成します。新しいプロパティごとに、すべての順列をカバーするためのデコレータが必要になります。
PS。これは、私が RubyでDecoratorパターンを使用して について書いた記事の短いバージョンです。これは、より詳細な例を見つけたい場合に読むことができます。
ウィキペディアには、スクロールバーでウィンドウを装飾する例があります。
http://en.wikipedia.org/wiki/Decorator_pattern
「チームメンバー、チームリード、およびマネージャー」のもう1つの非常に「現実的な」例は、単純な継承ではデコレーターパターンがかけがえのないものであることを示しています。
https://zishanbilal.wordpress.com/2011/04/28/design-patterns-by-examples-decorator-pattern/
Decorator Design Pattern :このパターンは、実行時にオブジェクトの特性を変更するのに役立ちます。オブジェクトにさまざまなフレーバーを提供し、フレーバーで使用する成分を柔軟に選択できます。
実際の例:飛行中にメインキャビンシートがあるとします。これで、座席で複数のアメニティを選択できます。各アメニティには、独自のコストが関連付けられています。ユーザーがWifiとプレミアムフードを選択した場合、ユーザーは座席+ wifi +プレミアムフードの料金を請求されます。
この場合、デコレータのデザインパターンが非常に役立ちます。上記のリンクにアクセスして、デコレーターパターンと1つの実際の例の実装について詳しく理解してください。
PubGの例を見てみましょう。アサルトライフルは4倍ズームで最適に機能し、その上で、コンペンセーターとサプレッサーも必要です。反動を減らし、発砲音とエコーを減らします。この機能を実装して、プレイヤーがお気に入りの銃とアクセサリーを購入できるようにする必要があります。プレイヤーは銃または付属品の一部またはすべてを購入でき、それに応じて充電されます。
ここでデコレータパターンがどのように適用されるかを見てみましょう。
上記の3つのアクセサリすべてを備えたSCAR-Lを購入したいとします。
これにより、次のようなクラス図が作成されます。
これで、次のようなクラスを作成できます。
public abstract class Gun {
private Double cost;
public Double getCost() {
return cost;
}
}
public abstract class GunAccessories extends Gun { }
public class Scarl extends Gun {
public Scarl() {
cost = 100;
}
}
public class Suppressor extends GunAccessories {
Gun gun;
public Suppressor(Gun gun) {
cost = 5;
this.gun = gun;
}
public double getCost(){
return cost + gun.getCost();
}
}
public class GunShop{
public static void main(String args[]){
Gun scarl = new Scarl();
scarl = new Supressor(scarl);
System.out.println("Price is "+scarl.getCost());
}
}
同様に他のアクセサリーを追加して、銃を飾ることができます。
参照:
https://nulpointerexception.com/2019/05/05/a-beginner-guide-to-decorator-pattern/
しばらく前に、デコレータパターンを使用するようにコードベースをリファクタリングしていたので、ユースケースについて説明しようとします。
一連のサービスがあり、ユーザーが特定のサービスのライセンスを取得したかどうかに基づいて、サービスを開始する必要があるとします。
すべてのサービスには共通のインターフェースがあります
interface Service {
String serviceId();
void init() throws Exception;
void start() throws Exception;
void stop() throws Exception;
}
abstract class ServiceSupport implements Service {
public ServiceSupport(String serviceId, LicenseManager licenseManager) {
// assign instance variables
}
@Override
public void init() throws Exception {
if (!licenseManager.isLicenseValid(serviceId)) {
throw new Exception("License not valid for service");
}
// Service initialization logic
}
}
注意深く観察すると、ServiceSupport
はLicenseManager
に依存しています。しかし、なぜLicenseManager
に依存する必要があるのでしょうか?ライセンス情報を確認する必要のないバックグラウンドサービスが必要な場合はどうなりますか。現在の状況では、バックグラウンドサービスに対してLicenseManager
を返すように、何らかの形でtrue
をトレーニングする必要があります。このアプローチは私にはよく見えませんでした。私によると、ライセンスチェックと他のロジックは互いに直交していました。
Decorator Patternが助けになり、ここでTDDによるリファクタリングを開始します。
class LicensedService implements Service {
private Service service;
public LicensedService(LicenseManager licenseManager, Service service) {
this.service = service;
}
@Override
public void init() {
if (!licenseManager.isLicenseValid(service.serviceId())) {
throw new Exception("License is invalid for service " + service.serviceId());
}
// Delegate init to decorated service
service.init();
}
// override other methods according to requirement
}
// Not concerned with licensing any more :)
abstract class ServiceSupport implements Service {
public ServiceSupport(String serviceId) {
// assign variables
}
@Override
public void init() {
// Service initialization logic
}
}
// The services which need license protection can be decorated with a Licensed service
Service aLicensedService = new LicensedService(new Service1("Service1"), licenseManager);
// Services which don't need license can be created without one and there is no need to pass license related information
Service aBackgroundService = new BackgroundService1("BG-1");