menu

Monday, January 13, 2014

Reflective Ziyaretçi (Visitor) Tasarım Örüntüsü

Reflective Ziyaretçi (Visitor) Tasarım ÖrüntüsüGiriş:

     Bugün davranış temelli tasarım örüntülerinden (behavioral design patterns) Ziyaretçi (Visitor) tasarım örüntünün hangi temel soruna çözüm olduğunu ve esnek yapıda bir Ziyaretçi tasarımının reflection ile nasıl gerçekleştirilebileceğini göreceğiz.
Ziyaretçi tasarım örüntüsü farklı veri tipindeki nesnelerin bir collection içerisinde kullanılması ve nesneler üzerinde benzer işlemlerin yapılması gerektiğinde kullanılır. Ziyaretçi tasarım örüntüsünün UML çizimi Şekil 1 de gösterilmiştir.

Reflective Ziyaretçi (Visitor) Tasarım Örüntüsü

                                                                    Şekil 1

Ziyaretçi Tasarım Örüntüsü Gerçekleştirimi:

Öncelikle ziyaretçi kullanmadan farklı nesneler içeren bir collection üzerinde çalışalım.

        List heterogenList = new ArrayList();
      
        heterogenList.add("A");
        heterogenList.add(1);
        heterogenList.add(Calendar.getInstance());
      
        for (Iterator iterator = heterogenList.iterator(); iterator.hasNext();) {
            Object heterogenElement = (Object) iterator.next();
            if (heterogenElement instanceof String) {
                String myString = (String) heterogenElement;   
                System.out.println("myString:" + myString);
                //do sth with the value
            }
            else if (heterogenElement instanceof Integer) {
                Integer myInteger = (Integer) heterogenElement;   
                System.out.println("myInteger:" + myInteger);
                //do sth with the value
            }
            else if (heterogenElement instanceof Calendar) {
                Calendar myCalendar = (Calendar) heterogenElement;   
                System.out.println("myCalendar:" + myCalendar);
                //do sth with the value
            }          
        }

Görüldüğü gibi farklı nesneleri collection içerisinden okumak için döngümüz içerisinde instanceof keyword'ünü kullanmamız gerekiyor. Bu da demek oluyor ki listemize farklı tipte bir liste eklendiğinde hali hazırda çalışan kodumuzu değiştirmek ve yeni bir if eklemek zorunda kalacağız.
Eğer kodumuzda sürekli if kullanıyorsak bir yerlerde yanlış yapıyoruz demektir ve tasarımı gözden geçirmek gerekmektedir. If kullanımı yerine soyutlama (abstraction) yaparak daha esnek, daha izlenebilir ve devam ettirilebilir bir yazılım elde edebiliriz. Ayrıca hali hazırda test edilmiş bir kodu her yeni veri tipinde değiştirmek zorunda kalmamız Open Closed Tasarım Örüntüsüne aykırı olup kaçınılması gereken bir durumdur. Bu durumda yardımımıza Ziyaretçi tasarım örüntüsü gelmektedir.
Öncelikle ihtiyacımız olan arayüz ve sınıfları tanımlayalım.
//Ziyaretçi arayüzü
public interface Visitor {
   void visit(WrappedString wString);
   void visit(WrappedCalendar wCalendar);
   void visit(WrappedInteger wInteger);
}
//Ziyaret edilecek nesne arayüzü
public interface Element {
    void accept(Visitor visitor);
}
//Listemizde kullanacağımız ziyaret edilecek nesneler
public class WrappedString implements Element {
    private String name;
    private String wString;
    public WrappedString(String name, String wString) {
        this.name = name;
        this.wString = wString;
    }
    public String getName() {
        return name;
    }
    public String getwString() {
        return wString;
    }
    @Override
    public void accept(Visitor visitor) {
        visitor.visit(this);
    }
}

public class WrappedInteger implements Element {
    private String name;
    private int wInt;
    public WrappedInteger(String name, int wInt) {
        this.name = name;
        this.wInt = wInt;
    }
    public String getName() {
        return name;
    }
    public int getwInt() {
        return wInt;
    }
    @Override
    public void accept(Visitor visitor) {
        visitor.visit(this);    
    } 
}

import java.util.Calendar;

public class WrappedCalendar implements Element{
    private Calendar wCalendar;
    private String name;
    public WrappedCalendar(String name, Calendar wCalendar) {
        this.name = name;
        this.wCalendar = wCalendar;
    }

    public Calendar getWCalendar() {
        return wCalendar;
    }

    public String getName() {
        return name;
    }
    @Override
    public void accept(Visitor visitor) {
        visitor.visit(this);    
    }
}

//Concrete Ziyaretçi
public class ConcreteVisitor implements Visitor {
    @Override
    public void visit(WrappedString wString) {
        System.out.println(wString.getName());
        // do sth
    }
    @Override
    public void visit(WrappedCalendar wCalendar) {
        System.out.println(wCalendar.getName() + "-" + wCalendar.getWCalendar().getTimeInMillis());
        // do sth
    }
    @Override
    public void visit(WrappedInteger wInteger) {
        System.out.println(wInteger.getName() + "-" + wInteger.getwInt());
        // do sth
    }
}

Şimdi daha önceki liste örneğimizin kodunu Ziyaretçi tasarım örüntüsü ile tekrar yazalım
       List heterogenList = new ArrayList();
       
        heterogenList.add(new WrappedString("wString","A"));
        heterogenList.add(new WrappedInteger("wInteger", 1));
        heterogenList.add(new WrappedCalendar("wCalendar", Calendar.getInstance()));
       
         Visitor visitor = new ConcreteVisitor();
         //Visitor visitor = new AnotherConcreteVisitor();
         for (Iterator iterator = heterogenList.iterator(); iterator.hasNext();) {
            Element element = (Element) iterator.next();
            element.accept(visitor);
        }

Görüldüğü üzere instanceof keyword'ünden kurtulduk.Listedeki her bir sınıfın nesnesi Element arayüzünü gerçekleştirdiğinden tek yapmamız gereken listeden Element arayüzünü okumak ve accept metodunu bir ziyaretçi ile çağırmak.Her bir nesne kendi accept metodunda ziyaretçinin visit metoduna kendisini parametre olarak geçecek ve ziyaretçi sınıfında nesne ile ilgili yapılmak istenen iş mantığı gerçekleştirilecek.Burada önemli nokta client kodunu hiç değiştirmeden nesneler üzerinde yeni iş mantıkları geliştirecek yeni ziyaretçilerin sisteme entegre edilebiliyor oluşu.

Reflective Ziyaretçi Tasarım Örüntüsü Gerçekleştirimi:

Ziyaretçi tasarım örüntüsü yeni ziyaretçi eklemede oldukça esnek davranırken, listemize yeni bir sınıf eklemek gerektiğinde Visitor arayüzünün değiştirilmesini gerektiriyor.Java'da bir arayüzü yayınladıktan sonra değiştirmek en can sıkıcı işlerden birisidir, çünkü arayüz değiştiğinde arayüzü gerçekleştiren tüm concrete ziyaretçilerin de değiştirilmesi gerekmektedir. Bu soruna çözüm üretebilmek için Visitor arayüzünü reflection ile oluşturabiliriz. Bu durumda arayüzün yeni hali;
//Reflective Ziyaretçi arayüzü
public interface ReflectiveVisitor {
   void visit(Object o);
}
//Reflective Element
public interface ReflectiveElement {
    void accept(ReflectiveVisitor visitor);
}
//Yeni ziyaret edilecek nesne (WrappedString sınıfını da implement ReflectiveElement olarak değiştirelim)
public class WrappedDouble implements ReflectiveElement {
    private String name;
    private double wDouble;
    public WrappedDouble(String name, double wDouble) {
        this.name = name;
        this.wDouble = wDouble;
    }
    public String getName() {
        return name;
    }
    public double getWDouble() {
        return wDouble;
    }
    @Override
    public void accept(ReflectiveVisitor visitor) {
        visitor.visit(this);
    } 
}
public class WrappedString implements ReflectiveElement {
    private String name;
    private String wString;
    public WrappedString(String name, String wString) {
        this.name = name;
        this.wString = wString;
    }
    public String getName() {
        return name;
    }
    public String getwString() {
        return wString;
    }
    @Override
    public void accept(ReflectiveVisitor visitor) {
       visitor.visit(this);
    }
    @Override
    public String toString() {
        return name + "-" + wString;
    }
}
//Reflective Concrete Ziyaretçi
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

public class AnotherConcreteVisitor implements ReflectiveVisitor {
    @Override
    public void visit(Object o) {
        try {
            Method visitMethod = this.getClass().getMethod("visit", new Class[] { o.getClass() });
            if (visitMethod == null) {
                defaultVisit(o);
            } else {
                visitMethod.invoke(this, new Object[] { o });
            }
        } catch (NoSuchMethodException e) {
            this.defaultVisit(o);
        } catch (InvocationTargetException e) {
            this.defaultVisit(o);
        } catch (IllegalAccessException e) {
            this.defaultVisit(o);
        }
    }
    public void defaultVisit(Object o) {
        System.out.println(o.toString());
    }
    public void visit(WrappedDouble wDouble){
        System.out.println(wDouble.getName() + "-" + wDouble.getWDouble());
        // do sth
    } 
}

Daha önceki liste örneğimizin kodunu Reflective Ziyaretçi tasarım örüntüsü ile tekrar yazalım
        List heterogenList = new ArrayList();
       
        heterogenList.add(new WrappedString("wString","A"));//default visit method
        heterogenList.add(new WrappedDouble("wDouble", 1.0));
       
         ReflectiveVisitor visitor = new AnotherConcreteVisitor();
         for (Iterator iterator = heterogenList.iterator(); iterator.hasNext();) {
            ReflectiveElement reflectiveElement = 
(ReflectiveElement) iterator.next();
            reflectiveElement.accept(visitor);
        } 

Bu yaklaşımda listemizdeki tüm nesneler ziyaretçi sınıfının generic visit metodunu çağırmaktadır.Parametre olarak Object alan bu generic visit metodu, gelen parametrenin tipine göre gerçekleştirilmiş olan ilgili visit metodunu çağırmaktadır. Burada önemli olan ziyaretçi sınıfının hangi veri tipleri için işlem yapmak istiyorsa o tipler için visit(veri:VeriTipi) metodunu tanımlamasıdır.Eğer ilgili visit metodu ziyaretçi sınıfında bulunamazsa defaultVisit metodu nesnenin String gösterimini ekrana yazma ya da default olarak belirleyeceğimiz başka bir işi gerçekleştirmeyi yapacaktır.

Sonuç:

     Bu tasarımda ziyaretçi eklemedeki esneklik, üzerinde çalıştığımız listeye yeni sınıf eklendiğinde de sağlanmış oluyor.Hali hazırda kullanılan bir ziyaretçiye yeni bir sınıf eklemek istediğimizde, yeni sınıf için bir visit metodunu ziyaretçi sınıfına eklememiz ve implementasyonunu yapmamız yeterli, ReflectiveInterface arayüzünü ve diğer ziyaretçileri değiştirmemize gerek kalmamış oldu.
Ancak bu esneklik bir performans kaybı ile beraber gelmektedir.Reflection ile çağırılacak metot dinamik olarak runtime'da belirlendiğinden bazı JVM optimizasyonları yapılamamaktadır ve reflection sık çalışan kod bölümleri için çok kötü performans verebilmektedir.Reflection kullanarak ve kullanmayarak 1000000 nesne için yukarıdaki kodu çalıştırdığımızda reflection ile 50 kat yavaş sonuç aldığımızı görmekteyiz.Ayrıca 10000000 nesne için aynı kodu çalıştırdığımızda reflection temelli yaklaşım Out of Memory hatası almaktadır.
Bunun sebebi java heap space in dolmasından olabileceği gibi JVM'in reflected metodun daha performanslı çalışması için kullandığı "inflation" mekanizmasından kaynaklı olarak perm gen space den kaynaklı da olabilir. Normalde belirli bir çağırım sayısına kadar java'nın Method classının içerisindeki MethodAccessor sınıfının bir nesnesi oluşturulup her invoke çağırımı MethodAccessor sınıfının aynı isimli invoke metoduna JNI(Java Native Interface) yöntemi ile yönlendirilmektedir. JNI metot çağırımı çok yavaş olduğundan belirli miktarda metot çağırımı yapıldığında, JVM runtime'da bir sınıf oluşturur.Bu sınıfta invoke metodu içermekte olup, bu sınıftan oluşturulan instance ile artık invoke metot çağırımları JNI yerine bu sınıfın nesneninin invoke metoduna yönlendirilir. Inflation olarak adlandırılan bu mekanizma ile reflected metot çağırımında performans problemi en aza indirilmiş olur. Ancak bu durumda dahi reflected metot çağırımı ile 50 kat yavaş sonuç aldığımızı söylemiştik.
Runtime'da oluşturulan sınıflar ve her sınıf için oluşturulan bir nesnenin referansı permanent generation dediğimiz heap space'de tutulur.(Permanent generation sınıf, metot tanımlarını, constant pool bilgisini (constant pool verisi class file'dan alınır),  class ile ilişkili object dizilerinin ya da type dizilerinin referanslarını, JVM tarafından runtime'da oluşturulan inflation dan kaynaklı sınıfları, static değişkenlerin referanslarını ve optimizasyon için JIT tarafından kullanılan bilgileri tutmaktadır.) Çok fazla farklı nesne üzerinden reflected metot çağırımı yapıldığında runtime'da inflation için oluşturulan sınıflardan kaynaklı olarak permanent generation dolup Out of Memory hatasına sebep olabilmektedir. Çok fazla reflected metot çağırımı yapılacağı durumlarda permanent generation için yeterli miktarda hafıza ayrılmalıdır.

Referanslar ve Kaynaklar:

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Desing Patterns -  Elements of Reusable Object-Oriented Software
http://anshuiitk.blogspot.com/2010/11/excessive-full-garbage-collection.html

Kaynak kodu buradan indirebilirsiniz.

No comments:

Post a Comment