Flyweight Pattern ( Structural )

Flyweight Pattern ( Structural Design Pattern )

1) Iskambil Oyunu yapacagiz. 52 Tane kagit var. Bu 52 kagitta 4 tip olur. 
   Kupa Karo Maca Sinek
   Her birinden 13 tane var. 
   Eger iskambil kagidi bir obje ise, o objenin hem tip hem de numara variable'i olacak.
   Basite indirgeyelim. Her variable 1 byte olsun.
   52 kagit icin, toplam 52x2 = 104 byte yer gerecek.
   Fakat Her tipi obje yapip, variable'lara o objenin referansini versek,
   52 kagit var, numaralar icin 52, tip icin 4 olacak, boylece 56 byte yer ayiracagiz.
   Her tipi de ihtiyac oldugumuz zaman yaratsak, performans da cok hizli olacaktir. 
   Bunu map ile yapiyoruz.
2) Bu durumda, FlyweightFactory class'i, bize istenen tipi dondurecek. Icinde bir map olacak.
O map te tip varsa dondurecek, yoksa yaratacak, yarattigini map'e atacak ve dondurecek.
Burada da flyweight tip oluyor.

RMI in 2011

RMI in 2011

1) Java to Java ya limited.
2) Bir tarafta yapilan degisikligi diger tarafa da deploy etmek
lazim. serilizationVersionUID den dolayi. Load balancer'larda
daha da sorun cikartabiir.
3) RMI son donemlerde pek dikkat cekmiyor.
4) Performansı iyi.
5) Web service daha low coupling.
    

Serialization Rules

Serialization Rules 

1) Objenin full serializable olmasi icin Obje ve Super obje Serializable 
implemente edecek 
2) Superclass serializable degilse de serialize olur. 
Fakat superClass'in no-arg constructor'u olacak. 
YOksa readObject() de java.io.InvalidClassException alir. 
Bir objenin default olarak no-arg constructor'u vardir, 
fakat o objeye herhangi bir argumanli constructor yazarsaniz, 
no-arg constructor'u ayrica implemente etmeniz gerektigini hatirlatalim. 
3) Serializable olmayan superclass in 
constructor'u deserialization sirasinda calisir. 
4) Butun primitive type ler serializable 
5) transient serialize olmaz. 
6) Static field lar serialize olmaz. 
7) Serializable object'in non serializable objesi varsa compile eder 
ama runtime de hata alir.

Facade Pattern ( Structural )

Facade Pattern ( One Of Structural Patterns ) 1) Simple interface to a larger body of code. Class Library. 2) Wrap a poorly designed collection of APIs with a single well-designed API. 3) Utility Class is a facade. 4) Calling a one function for a set of functions 5) JOptionPane.showMessageDialog() ornek bir facade. AWT ile bir suru sey yazacagina kolay bi sekilde hallediyorsun. Sık kullanılan, ve terzi usulu olmayan bir isi, yani almost her zaman aynı şekilde yapılan bir işi tek fonksiyona indirmek. 6) Facade aslinda bir obje, onu yaratip onun uzerinden is yapiyorsun. Yani bir singleton gibi, yok constructor private olacak, yok getInstance static olacak gibi kurallari yok. Bir mucize aramamak lazim. Zaten herkesin dogal olarak yaptigi utility fonksiyonlarini bir class ta toplarsan, ona facade deniyor. 7) Also Facade is not the only entry point to the sub-system but is a convenient point of communication to the subsystem and client can always have the direct access to the subsystem. 8) Facade ayni zamanda singleton olabilir, birden fazla yaratilmasina gerek yoksa, ama boyle bir sart yok.

High Cohesion And Low Coupling

High Cohesion : bir objenin alakasız isleri mümkün oldugu kadar az yapmasi Low Coupling : Objelerin birbirine mümkün olduğu kadar az depend olmasi, birbirini daha az referans almasi.

Cross Cutting Concern

Aspect yapilmasini gerektiren durumlardir. Mesela programın core tarafi, core concern dir. Logging, transaction , security gibi kodlamalar bütün sistemi ilgilendirdigi ve her yerde yazilmasi gerektigi icin bunlara cross cutting concern deniyor.

Overriding Static Methods

Taken from http://geekexplains.blogspot.com/2008/06/can-you-override-static-methods-in-java.html

Can you override Static Methods in Java?

Question: Can you override Static Methods in Java?

Answer: Well... the answer is NO if you think from the perspective of how an overriden method should behave in Java. But, you don't get any compiler error if you try to override a static method. That means, if you try to override, Java doesn't stop you doing that; but you certainly don't get the same effect as you get for non-static methods. Overriding in Java simply means that the particular method would be called based on the run time type of the object and not on the compile time type of it (which is the case with overriden static methods). Okay... any guesses for the reason why do they behave strangely? Because they are class methods and hence access to them is always resolved during compile time only using the compile time type information. Accessing them using object references is just an extra liberty given by the designers of Java and we should certainly not think of stopping that practice only when they restrict it :-)

Example: let's try to see what happens if we try overriding a static method:-

class SuperClass{
......
public static void staticMethod(){
System.out.println("SuperClass: inside staticMethod");
}
......
}

public class SubClass extends SuperClass{
......
//overriding the static method
public static void staticMethod(){
System.out.println("SubClass: inside staticMethod");
}

......
public static void main(String []args){
......
SuperClass superClassWithSuperCons = new SuperClass();
SuperClass superClassWithSubCons = new SubClass();
SubClass subClassWithSubCons = new SubClass();

superClassWithSuperCons.staticMethod();
superClassWithSubCons.staticMethod();
subClassWithSubCons.staticMethod();
...
}

}

Output:-

SuperClass: inside staticMethod
SuperClass: inside staticMethod
SubClass: inside staticMethod

Notice the second line of the output. Had the staticMethod been overriden this line should have been identical to the third line as we're invoking the 'staticMethod()' on an object of Runtime Type as 'SubClass' and not as 'SuperClass'. This confirms that the static methods are always resolved using their compile time type information only.