Penerapan design pattern Abstract Factory di Java

Abstract factory adalah pola desain perangkat lunak yang menyediakan cara untuk merangkum sekelompok individu pabrik-pabrik yang memiliki tema umum. Pada penggunaan normal, perangkat lunak klien menciptakan sebuah implementasi beton pabrik abstrak dan kemudian menggunakan antarmuka generik untuk membuat objek beton yang merupakan bagian dari tema. Klien tidak tahu (atau peduli) objek yang konkret mendapatkannya dari masing-masing pabrik-pabrik internal karena menggunakan hanya antarmuka generik produk mereka. Pola ini memisahkan rincian pelaksanaan satu set objek dari penggunaan umum mereka.

Contoh ini akan kelas abstrak pabrik DocumentCreator yang menyediakan antarmuka untuk menciptakan sejumlah produk (misalnya createLetter() dan createResume()). Sistem akan memiliki sejumlah versi beton yang berasal dari kelas DocumentCreator seperti FancyDocumentCreator atau ModernDocumentCreator, masing-masing dengan implementasi yang berbeda dari createLetter() dan createResume() yang akan menciptakan objek yang sesuai seperti FancyLetter atau ModernResume. Masing-masing produk ini berasal dari kelas abstrak sederhana seperti surat atau Resume yang klien sadar. Kode klien akan mendapatkan contoh sesuai DocumentCreator dan memanggil metode pabrik. Masing-masing objek yang dihasilkan akan dibuat dari pelaksanaan DocumentCreator sama dan akan berbagi tema umum (mereka semua akan mewah atau modern objek). Klien akan perlu tahu bagaimana menangani hanya abstrak surat atau Resume kelas, bukan versi tertentu yang mendapat dari pabrik beton.

Sebuah pabrik adalah lokasi atau kelas beton dalam kode di mana objek yang dibangun. Maksud dalam mempekerjakan pola adalah untuk melindungi penciptaan objek dari penggunaan mereka. Hal ini memungkinkan untuk jenis turunan baru yang akan diperkenalkan dengan tidak ada perubahan kode yang menggunakan kelas dasar.

Menggunakan pola ini memungkinkan untuk pertukaran implementasi beton tanpa mengubah kode yang menggunakan mereka, bahkan saat runtime. Namun, pekerjaan ini pola, dengan pola desain serupa, dapat mengakibatkan tidak perlu kompleksitas dan pekerjaan tambahan di awal penulisan kode. Digunakan dengan benar terbayar “ekstra bekerja” dalam pelaksanaan kedua pabrik.

Structure :

Class diagram

Java :

/* GUIFactory example -- */

interface GUIFactory {
    public Button createButton();
}

class WinFactory implements GUIFactory {
    public Button createButton() {
        return new WinButton();
    }
}
class OSXFactory implements GUIFactory {
    public Button createButton() {
        return new OSXButton();
    }
}

interface Button {
    public void paint();
}

class WinButton implements Button {
    public void paint() {
        System.out.println("I'm a WinButton");
    }
}
class OSXButton implements Button {
    public void paint() {
        System.out.println("I'm an OSXButton");
    }
}

class Application {
    public Application(GUIFactory factory) {
        Button button = factory.createButton();
        button.paint();
    }
}

public class ApplicationRunner {
    public static void main(String[] args) {
        new Application(createOsSpecificFactory());
    }

    public static GUIFactory createOsSpecificFactory() {
        int sys = readFromConfigFile("OS_TYPE");
        if (sys == 0) {
            return new WinFactory();
        } else {
            return new OSXFactory();
        }
    }
}

 

Penerapan design pattern Factory Method di Java

Factory method pattern adalah pola desain berorientasi objek untuk menerapkan konsep pabrik. Seperti pola lain creational, itu berurusan dengan masalah membuat objek (produk) tanpa menentukan kelas yang tepat dari objek yang akan dibuat. Penciptaan objek sering memerlukan proses kompleks yang tidak sesuai untuk menyertakan dalam objek composing. Pembuatan obyek dapat menyebabkan signifikan duplikasi kode, mungkin memerlukan informasi yang tidak dapat diakses ke objek composing, tidak dapat memberikan abstraksi yang memadai, atau mungkin sebaliknya tidak bagian dari objek composing keprihatinan. Pola desain metode pabrik menangani masalah ini dengan mendefinisikan metode yang terpisah untuk membuat objek, gliserolipid yang kemudian dapat mengesampingkan untuk menentukan tipe turunan dari produk yang akan dibuat.

Beberapa proses yang diperlukan dalam penciptaan objek termasuk menentukan objek yang untuk membuat, mengelola seumur hidup objek, dan mengelola build-up khusus dan air mata-down keprihatinan objek. Di luar lingkup pola desain, istilah pabrik metode dapat juga merujuk metode pabrik yang tujuan utamanya adalah penciptaan objek.

Java :

Maze game dapat dimainkan dalam dua mode, satu dengan kamar biasa yang hanya berhubungan dengan kamar di sebelahnya, dan satu dengan sihir kamar yang memungkinkan pemain untuk diangkut secara acak (contoh Jawa ini sama dengan salah satu dalam buku Design Patterns). Modus permainan biasa dapat menggunakan metode template ini:

public class MazeGame {
  public MazeGame() {
     Room room1 = makeRoom();
     Room room2 = makeRoom();
     room1.connect(room2);
     this.addRoom(room1);
     this.addRoom(room2);
  }

  protected Room makeRoom() {
     return new OrdinaryRoom();
  }
}

 

Penerapan design pattern builder di Java

Builder pattern adalah sebuah objek penciptaan perangkat lunak desain pola. Tujuannya adalah untuk abstrak langkah-langkah konstruksi objek sehingga implementasi yang berbeda dari langkah-langkah berikut dapat membangun berbeda representasi objek. Sering kali, pembangun pola digunakan untuk membangun produk sesuai dengan pattern.ry komposit.

Sructure :

Java :

 /** "Product" */
 class Pizza {
    private String dough = "";
    private String sauce = "";
    private String topping = "";

    public void setDough(String dough)     { this.dough = dough; }
    public void setSauce(String sauce)     { this.sauce = sauce; }
    public void setTopping(String topping) { this.topping = topping; }
 }

 /** "Abstract Builder" */
 abstract class PizzaBuilder {
    protected Pizza pizza;

    public Pizza getPizza() { return pizza; }
    public void createNewPizzaProduct() { pizza = new Pizza(); }

    public abstract void buildDough();
    public abstract void buildSauce();
    public abstract void buildTopping();
 }

 /** "ConcreteBuilder" */
 class HawaiianPizzaBuilder extends PizzaBuilder {
    public void buildDough()   { pizza.setDough("cross"); }
    public void buildSauce()   { pizza.setSauce("mild"); }
    public void buildTopping() { pizza.setTopping("ham+pineapple"); }
 }

 /** "ConcreteBuilder" */
 class SpicyPizzaBuilder extends PizzaBuilder {
    public void buildDough()   { pizza.setDough("pan baked"); }
    public void buildSauce()   { pizza.setSauce("hot"); }
    public void buildTopping() { pizza.setTopping("pepperoni+salami"); }
 }

 /** "Director" */
 class Waiter {
    private PizzaBuilder pizzaBuilder;

    public void setPizzaBuilder(PizzaBuilder pb) { pizzaBuilder = pb; }
    public Pizza getPizza() { return pizzaBuilder.getPizza(); }

    public void constructPizza() {
       pizzaBuilder.createNewPizzaProduct();
       pizzaBuilder.buildDough();
       pizzaBuilder.buildSauce();
       pizzaBuilder.buildTopping();
    }
 }

 /** A customer ordering a pizza. */
 class BuilderExample {
    public static void main(String[] args) {
        Waiter waiter = new Waiter();
        PizzaBuilder hawaiian_pizzabuilder = new HawaiianPizzaBuilder();
        PizzaBuilder spicy_pizzabuilder = new SpicyPizzaBuilder();

        waiter.setPizzaBuilder( hawaiian_pizzabuilder );
        waiter.constructPizza();

        Pizza pizza = waiter.getPizza();
    }
 }

 

Penerapan design pattern Observer pattern di Java

Observer pattern adalah adalah pola desain perangkat lunak di mana suatu objek, yang disebut subjek, akan menyimpan daftar dari tanggungan, yang disebut pengamat, dan memberitahukan mereka secara otomatis dari setiap perubahan negara, biasanya dengan menelepon salah satu metode mereka. Hal ini terutama digunakan untuk mengimplementasikan sistem penanganan peristiwa terdistribusi. Pengamat juga merupakan bagian penting dalam pola arsitektur MVC akrab. Pada kenyataannya pola observer pertama kali diimplementasikan dalam Smalltalk’s MVC antarmuka pengguna berbasis kerangka.

Structure :

Java :

/* File Name : EventSource.java */
package obs;

import java.util.Observable;          //Observable is here
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;

public class EventSource extends Observable implements Runnable {
    public void run() {
        try {
            final InputStreamReader isr = new InputStreamReader( System.in );
            final BufferedReader br = new BufferedReader( isr );
            while( true ) {
                String response = br.readLine();
                setChanged();
                notifyObservers( response );
            }
        }
        catch (IOException e) {
            e.printStackTrace();
        }
    }
}

 

Penerapan design pattern Visitor pattern di Java

 Visitor pattern adalah cara yang memisahkan algoritma dari struktur objek yang beroperasi. Hasil praktis dari pemisahan ini adalah kemampuan untuk menambahkan baru operasi untuk struktur objek yang ada tanpa memodifikasi struktur mereka. Ini adalah salah satu cara untuk dengan mudah mengikuti prinsip terbuka/tertutup.

Pada dasarnya, pengunjung memungkinkan seseorang untuk menambahkan fungsi virtual baru dari kelas keluarga tanpa memodifikasi kelas sendiri; Sebaliknya, salah satu menciptakan kelas pengunjung yang menerapkan semua spesialisasi sesuai fungsi virtual. Pengunjung membutuhkan referensi contoh sebagai masukan, dan menerapkan tujuan melalui pengiriman ganda.

Diagram :

Java :

interface CarElementVisitor {
    void visit(Wheel wheel);
    void visit(Engine engine);
    void visit(Body body);
    void visit(Car car);
}

interface CarElement {
    void accept(CarElementVisitor visitor); // CarElements have to provide accept().
}

class Wheel implements CarElement {
    private String name;

    public Wheel(String name) {
        this.name = name;
    }

    public String getName() {
        return this.name;
    }

    public void accept(CarElementVisitor visitor) {
   /*
    * Wheel.accept(CarElementVisitor) overrides CarElement.accept(CarElementVisitor), so the call 
    * to accept is bound at run time. This can be considered the the first dispatch.
    * The decision to call CarElementVisitor.visit(Wheel) however, rather than the other 'visit'
    * methods in CarElementVisitor, can be made during compile time since 'this' is known at compile 
    * time to be a Wheel. Moreover, each subclass of CarElementVisitor overrides the visit(Wheel),
    * which is another decision that is made at run time. This can be considered the second dispatch.
    */ 
    visitor.visit(this);
    }
}

class Engine implements CarElement {
    public void accept(CarElementVisitor visitor) {
        visitor.visit(this);
    }
}

class Body implements CarElement {
    public void accept(CarElementVisitor visitor) {
        visitor.visit(this);
    }
}

class Car implements CarElement {
    CarElement[] elements;

    public Car() {
        //create new Array of elements
        this.elements = new CarElement[] { new Wheel("front left"), 
            new Wheel("front right"), new Wheel("back left") , 
            new Wheel("back right"), new Body(), new Engine() };
    }

    public void accept(CarElementVisitor visitor) {     
        for(CarElement elem : elements) {
            elem.accept(visitor);
        }
        visitor.visit(this);    
    }
}

class CarElementPrintVisitor implements CarElementVisitor {
    public void visit(Wheel wheel) {      
        System.out.println("Visiting " + wheel.getName() + " wheel");
    }

    public void visit(Engine engine) {
        System.out.println("Visiting engine");
    }

    public void visit(Body body) {
        System.out.println("Visiting body");
    }

    public void visit(Car car) {      
        System.out.println("Visiting car");
    }
}

class CarElementDoVisitor implements CarElementVisitor {
    public void visit(Wheel wheel) {
        System.out.println("Kicking my " + wheel.getName() + " wheel");
    }

    public void visit(Engine engine) {
        System.out.println("Starting my engine");
    }

    public void visit(Body body) {
        System.out.println("Moving my body");
    }

    public void visit(Car car) {
        System.out.println("Starting my car");
    }
}

public class VisitorDemo {
    static public void main(String[] args) {
        Car car = new Car();
        car.accept(new CarElementPrintVisitor());
        car.accept(new CarElementDoVisitor());
    }
}

 

Template method pattern

Dalam rekayasa perangkat lunak, pola metode template adalah pola desain. Ini adalah suatu pola perilaku, dan tidak terkait dengan C++ template.

Metode template mendefinisikan kerangka program algoritma. Satu atau lebih langkah algoritma dapat dikalahkan oleh gliserolipid agar berbeda perilaku sambil memastikan bahwa algoritma menyeluruh masih diikuti.

Dalam pemrograman berorientasi obyek, pertama kelas dibuat yang menyediakan langkah-langkah dasar desain algoritma. Langkah-langkah ini diimplementasikan menggunakan metode abstrak. Kemudian gliserolipid mengubah metode abstrak untuk melaksanakan tindakan nyata. Dengan demikian algoritma umum disimpan di satu tempat tetapi langkah konkret mungkin berubah oleh gliserolipid.

Metode template dengan demikian mengelola gambaran besar tentang tugas semantik, dan lebih halus rincian pelaksanaan seleksi dan urutan metode. Ini gambar yang lebih besar panggilan metode abstrak dan non-abstrak untuk tugas yang dihadapi. Metode non-abstrak yang benar-benar dikontrol oleh metode template tapi metode abstrak, dilaksanakan di gliserolipid, memberikan pola kekuatan ekspresif dan derajat kebebasan. Beberapa atau semua metode abstrak dapat khusus dalam sebuah subclass, memungkinkan penulis Subkelas untuk menyediakan perilaku tertentu dengan sedikit modifikasi semantik yang lebih besar. Metode template (yang non-abstrak) tetap tidak berubah dalam pola ini, memastikan bahwa bawahan metode non-abstrak dan metode abstrak disebut dalam urutan awalnya dimaksudkan.

Metode template sering terjadi setidaknya dalam kasus paling sederhana, di mana metode panggilan hanya satu metode abstrak, dengan objek berorientasi bahasa. Jika seorang penulis perangkat lunak menggunakan metode polimorfik sama sekali, pola desain ini mungkin agak wajar konsekuensi. Hal ini karena metode yang memanggil fungsi abstrak atau polimorfik adalah cukup alasan untuk menjadi metode abstrak atau polimorfik. Metode template dapat digunakan untuk menambah nilai kini yang segera perangkat lunak atau dengan visi ke perangkat tambahan di masa depan.

Pola metode Template sangat terkait erat dengan pola Non-Virtual antarmuka (NVI). Pola NVI mengakui manfaat dari metode non-abstrak yang menerapkan metode abstrak bawahan. Tingkat ini tipuan memungkinkan untuk pra dan pasca operasi relatif terhadap operasi abstrak kedua segera dan dengan masa depan perubahan yang tak terduga. Pola NVI dapat digunakan dengan sangat sedikit perangkat lunak produksi dan runtime biaya. Banyak perangkat lunak komersial kerangka mempekerjakan NVI pola.

Metode template menerapkan prinsip memahami variasi Protected, seperti pola adaptor. Perbedaannya adalah bahwa Adapter memberikan antarmuka yang sama untuk beberapa operasi sementara metode Template tidak hanya untuk satu.

Structure :

Contoh :

/**
 * An abstract class that is 
 * common to several games in
 * which players play against 
 * the others, but only one is
 * playing at a given time.
 */

abstract class Game {

    protected int playersCount;
    abstract void initializeGame();
    abstract void makePlay(int player);
    abstract boolean endOfGame();
    abstract void printWinner();

    /* A template method : */
    public final void playOneGame(int playersCount) {
        this.playersCount = playersCount;
        initializeGame();
        int j = 0;
        while (!endOfGame()) {
            makePlay(j);
            j = (j + 1) % playersCount;
        }
        printWinner();
    }
}

//Now we can extend this class in order 
//to implement actual games:

class Monopoly extends Game {

    /* Implementation of necessary concrete methods */
    void initializeGame() {
        // Initialize players
        // Initialize money
    }
    void makePlay(int player) {
        // Process one turn of player
    }
    boolean endOfGame() {
        // Return true if game is over 
        // according to Monopoly rules
    }
    void printWinner() {
        // Display who won
    }
    /* Specific declarations for the Monopoly game. */

    // ...
}

class Chess extends Game {

    /* Implementation of necessary concrete methods */
    void initializeGame() {
        // Initialize players
        // Put the pieces on the board
    }
    void makePlay(int player) {
        // Process a turn for the player
    }
    boolean endOfGame() {
        // Return true if in Checkmate or 
        // Stalemate has been reached
    }
    void printWinner() {
        // Display the winning player
    }
    /* Specific declarations for the chess game. */

    // ...
}

 

Penerapan design pattern Strategy di Java

Strategy pattern (juga dikenal sebagai kebijakan pola) adalah pola desain perangkat lunak tertentu, dimana algoritma dapat dipilih saat runtime. Secara resmi berbicara, strategi pola mendefinisikan sebuah keluarga algoritma, merangkum masing-masing, dan membuat mereka saling dipertukarkan. Strategi ini memungkinkan algoritma yang bervariasi secara independen dari klien yang menggunakannya.[1]

Sebagai contoh, sebuah kelas yang melakukan validasi pada data yang masuk dapat menggunakan pola strategi untuk memilih algoritma validasi yang didasarkan pada jenis data, sumber data, pilihan pengguna, dan faktor-faktor lain yang membedakan, atau. Faktor-faktor ini tidak diketahui untuk setiap kasus sampai run-time, dan mungkin memerlukan validasi yang berbeda untuk dilakukan. Strategi validasi, dikemas secara terpisah dari objek memvalidasi, dapat digunakan oleh benda-benda lain memvalidasi dalam berbagai bidang sistem (atau bahkan berbagai sistem) tanpa duplikasi kode.

Persyaratan penting dalam bahasa pemrograman adalah kemampuan untuk menyimpan referensi untuk beberapa kode dalam struktur data dan mengambilnya. Ini dapat dicapai dengan mekanisme seperti pointer asli fungsi, fungsi kelas, kelas atau kelas contoh dalam berorientasi objek bahasa pemrograman, atau mengakses penyimpanan internal implementasi bahasa kode melalui refleksi.

Structure :

Contoh di Java

// The classes that implement a concrete strategy should implement this.
// The context class uses this to call the concrete strategy.
interface Strategy {
    int execute(int a, int b); 
}

// Implements the algorithm using the strategy interface
class ConcreteStrategyAdd implements Strategy {

    public int execute(int a, int b) {
        System.out.println("Called ConcreteStrategyAdd's execute()");
        return a + b;  // Do an addition with a and b
    }
}

class ConcreteStrategySubtract implements Strategy {

    public int execute(int a, int b) {
        System.out.println("Called ConcreteStrategySubtract's execute()");
        return a - b;  // Do a subtraction with a and b
    }
}

class ConcreteStrategyMultiply implements Strategy {

    public int execute(int a, int b) {
        System.out.println("Called ConcreteStrategyMultiply's execute()");
        return a * b;   // Do a multiplication with a and b
    }    
}

// Configured with a ConcreteStrategy object and maintains a reference to a Strategy object
class Context {

    private Strategy strategy;

    // Constructor
    public Context(Strategy strategy) {
        this.strategy = strategy;
    }

    public int executeStrategy(int a, int b) {
        return strategy.execute(a, b);
    }
}

// Test application
class StrategyExample {

    public static void main(String[] args) {

        Context context;

        // Three contexts following different strategies
        context = new Context(new ConcreteStrategyAdd());
        int resultA = context.executeStrategy(3,4);

        context = new Context(new ConcreteStrategySubtract());
        int resultB = context.executeStrategy(3,4);

        context = new Context(new ConcreteStrategyMultiply());
        int resultC = context.executeStrategy(3,4);
    }
}

 

Design pattern State

State pattern, yang sangat menyerupai pola strategi, adalah pola desain perangkat lunak perilaku, juga dikenal sebagai objek untuk Serikat pola. Pola ini digunakan dalam pemrograman komputer untuk mewakili negara objek. Ini adalah cara yang bersih untuk suatu objek untuk mengubah sebagian jenis saat runtime.

Structure :

Pseudocode :

Ambil, misalnya, program gambar. Program ini memiliki kursor mouse, yang pada setiap titik waktu dapat bertindak sebagai salah satu dari beberapa alat. Alih-alih beralih di antara beberapa objek kursor, kursor mempertahankan keadaan internal yang mewakili alat yang digunakan. Ketika metode bergantung pada alat yang disebut (mengatakan, sebagai akibat dari klik mouse), panggilan metode diteruskan kepada negara kursor.

Masing-masing alat sesuai dengan keadaan. Kelas bersama negara abstrak adalah AbstractTool:

class AbstractTool is
     function moveTo(point) is
         input:  the location point the mouse moved to
         (
this function must be implemented by subclasses)
function mouseDown(point) is
         input:  the location point the mouse is at
         (this function must be implemented by subclasses)
 function mouseUp(point) is
         input:  the location point the mouse is at
         (this function must be implemented by subclasses)

Menurut definisi ini, masing-masing alat harus menangani gerakan kursor mouse juga awal dan akhir setiap klik atau tarik.

Menggunakan kelas dasar, sederhana pena dan pilihan alat-alat bisa terlihat seperti ini:

subclass PenTool of AbstractTool is
     last_mouse_position := invalid
     mouse_button := up
function moveTo(point) is
         input:  the location point the mouse moved to
         if mouse_button = down
             (draw a line from the last_mouse_position to point)
             last_mouse_position := point
function mouseDown(point) is
         input:  the location point the mouse is at
         mouse_button := down
         last_mouse_position := point
function mouseUp(point) is
         input:  the location point the mouse is at
         mouse_button := up
subclass SelectionTool of AbstractTool is
     selection_start := invalid
     mouse_button := up
function moveTo(point) is
         input:  the location point the mouse moved to
         if mouse_button = down
             (select the rectangle between selection_start and point)
function mouseDown(point) is
         input:  the location point the mouse is at
         mouse_button := down
         selection_start := point
function mouseUp(point) is
         input:  the location point the mouse is at
         mouse_button := up
Untuk contoh ini, kelas untuk konteks disebut kursor. Metode yang bernama di kelas abstrak negara (AbstractTool dalam kasus ini) juga diterapkan dalam konteks. Dalam konteks kelas, metode ini memohon metode sesuai keadaan saat ini, diwakili oleh current_tool.
class Cursor is
     current_tool := new PenTool
function moveTo(point) is
         input:  the location point the mouse moved to
         current_tool.moveTo(point)
function mouseDown(point) is
         input:  the location point the mouse is at
         current_tool.mouseDown(point)
function mouseUp(point) is
         input:  the location point the mouse is at
         current_tool.mouseUp(point)
function usePenTool() is
         current_tool := new PenTool
function useSelectionTool() is
         current_tool := new SelectionTool

Perhatikan bagaimana satu kursor objek dapat bertindak sebagai PenTool dan SelectionTool pada titik yang berbeda, dengan melewati metode yang sesuai panggilan ke mana alat ini aktif. Itu adalah inti dari pola negara. Dalam kasus ini, kita bisa memiliki gabungan negara dan objek dengan menciptakan kelas PenCursor dan SelectCursor, sehingga mengurangi solusi sederhana warisan, tetapi dalam prakteknya, kursor mungkin membawa data yang mahal atau janggal untuk menyalin ke objek baru setiap kali sebuah tool baru yang dipilih.
 

 

Design pattern Observer

Pengamat pola (alias. Tanggungan, yang mempublikasikan/berlangganan) adalah pola desain perangkat lunak di mana suatu objek, yang disebut subjek, akan menyimpan daftar dari tanggungan, yang disebut pengamat, dan memberitahukan mereka secara otomatis dari setiap perubahan negara, biasanya dengan menelepon salah satu metode mereka. Hal ini terutama digunakan untuk mengimplementasikan sistem penanganan peristiwa terdistribusi. Pengamat juga merupakan bagian penting dalam pola arsitektur MVC akrab. Pada kenyataannya pola observer pertama kali diimplementasikan dalam Smalltalk’s MVC antarmuka pengguna berbasis kerangka.[1]

Terkait pola: mediator, tunggal.

Structure :

 

Penerapan design pattern Memento di Java

Memento pattern adalah pola desain perangkat lunak yang menyediakan kemampuan untuk mengembalikan objek ke keadaan sebelumnya (Batalkan melalui rollback).

Pola kenang-kenangan dilaksanakan dengan dua objek: originator dan pengurus. Originator adalah beberapa objek yang memiliki keadaan internal. The caretaker akan melakukan sesuatu untuk originator, tapi ingin dapat membatalkan perubahan. The caretaker pertama meminta originator objek kenang-kenangan. Maka tidak apa pun operasi (atau serangkaian operasi) itu akan dilakukan. Untuk memutar kembali ke negara sebelum operasi, itu kembali kenang-kenangan objek ke originator. Kenang-kenangan objek itu sendiri adalah objek buram (salah satu yang sang penunggu tidak, atau tidak, mengubah). Bila menggunakan pola ini, harus berhati jika originator dapat mengubah objek atau sumber lainnya – pola kenang-kenangan yang beroperasi pada satu objek.

Klasik pola kenang-kenangan contohnya benih pseudorandom mengembalikan nomor generator (itu akan selalu menghasilkan urutan yang sama kemudian ketika dijalankan dengan benih negara) dan negara di pensiunnya.

Contoh:

import java.util.List;
import java.util.ArrayList;
class Originator {
    private String state;
    // The class could also contain additional data that is not part of the
    // state saved in the memento.

    public void set(String state) {
        System.out.println("Originator: Setting state to " + state);
        this.state = state;
    }

    public Memento saveToMemento() {
        System.out.println("Originator: Saving to Memento.");
        return new Memento(state);
    }

    public void restoreFromMemento(Memento memento) {
        state = memento.getSavedState();
        System.out.println("Originator: State after restoring from Memento: " + state);
    }

    public static class Memento {
        private final String state;

        public Memento(String stateToSave) {
            state = stateToSave;
        }

        public String getSavedState() {
            return state;
        }
    }
}

class Caretaker {
    public static void main(String[] args) {
        List<Originator.Memento> savedStates = new ArrayList<Originator.Memento>();

        Originator originator = new Originator();
        originator.set("State1");
        originator.set("State2");
        savedStates.add(originator.saveToMemento());
        originator.set("State3");
        // We can request multiple mementos, and choose which one to roll back to.
        savedStates.add(originator.saveToMemento());
        originator.set("State4");

        originator.restoreFromMemento(savedStates.get(1));   
    }
}

Output :
Originator: Setting state to State1
Originator: Setting state to State2
Originator: Saving to Memento.
Originator: Setting state to State3
Originator: Saving to Memento.
Originator: Setting state to State4
Originator: State after restoring from Memento: State3