Search Blog

Search duranek.blogspot.com

Monday, January 16, 2012

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.

Sunday, January 15, 2012

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.

For Singleton Pattern

Java Singleton Pattern ( One Of Creational Patterns ) icin: 1) Bir class'in icinde Private Static Object 2) Private Constructor 3) Static get Instance Method of the object 4) Change getInstance Method to synchronized for threadsafe 5) Override clone method of Object, and do throw new CloneNotSupportedException() 6) Optional, making the class final to not override

Tuesday, January 10, 2012

Google Searchbox

Search calismadigi icin, google search koydum. design - add new gadget html/javascript
<form method="get" action="http://www.google.com/search">

<div style="border:1px solid black;padding:4px;width:20em;">
<table border="0" cellpadding="0">
<tr><td>
<input type="text" name="q" size="30" 
 maxlength="270" value="" />
<input type="submit" value="Google Search" /></td></tr>
<tr><td align="center" style="font-size:75%">
<input type="checkbox" name="sitesearch" 
 value="pclives.blogspot.com" checked /> Search Pclives.blogspot.com<br />
</td></tr></table>
</div>

</form>

AOP 2

AOP in Spring

Advice: Method Names
Pointcut: Advice path lere shortcut
JoinPoint: Aspect de called method un ismini verir. Aspect metoduna parametre 
olarak yazilir.

<aop:aspectj-autoproxy /> bunu spring.xml e yazmak lazim.

Spring de member variable update icin advice yazilmaz.
sadece method icin yaziliyor. member variable icin sadece aspectj kullanmak lazim

@Before("execution(public void String getName())")
Bu anotation sadece bu metodlarda calisir.

joinPoint.getTarget() dersen cagiran object i gosterir
joinPoint.toString() dersen cagiran metodu yazar.
joinPoint.getTarget() ile , objeyi cekip islem yapabilirsin

@Before("args(String)")
argument i String olan metodlardan once calistir.

@Before("args(name)")
public void xxAdvice(String name) {

}
Burada name olarak value yu kullanabiliriz. Bunun da String olmasi lazim.

@Before annotation'i, biz explicit olarak metodu cagirdigimiz zaman
calisir. Spring initialize olurken bu metodu cagirdigi zaman calismaz.
( Spring initialize olurken, default value leri set ediyordu ya )

@After
Bu annotation i metoddan sonra calismasi icin yapabilirsin.

@AfterReturning
Bu annotation ile advice sadece return olunca yani exception olmazsa
cagirilir.

@AfterThrowing
Sadece throw olduktan sonra cagirilir.

Aspect class larinin annotation'i @Aspect

@AfterReturning(pointcut="args(name)",returning="returnString")
public void xxadvice(String name,String returnString){

}
return String i almak icin bu annotation i kullanabiliriz.

Advice metodlarina parametre olarak Object verirsek, cast ederek
istedigimiz objeye cevirebiliriz.

@AfterThrowing(pointcut="args(name)",throwing="ex")
public void xxxAdvice(String name, RuntimeException ex)
Bu sekilde ise exception i alabiliriz.

Ayni parametre olarak Object verdiğimiz gibi, throwing olarak Exception
class ini veririsek cast ederek istedigimizi alabiliriz. 

@Around annotation i ile hem before hem after'da calistirabilirsin
advice'i.

@Around("test()")
public void xxAdvice(ProceedingJoinPoint proceedingJoinPoint) {
//before da cagirilacak yer
proceedingJoinPoint.proceed();  //metodun gercekten cagirilmasi
//after da cagirilacak yer.
}
Fakat around yaptigimiz zaman ProceedingJoinPoint kullanmak lazim. Ve bu sart !
Ikisini tek yerde yapabiliriz.

Neden hep @Around hep kullanmiyoruz, hep en kolay olani kullanmak lazim.
Always the least powerful

Eger eger advice olan metod obje donuyorsa, @Around metod da obje donmeli

Tipik conventionlar
pakeler asagidaki gibi:
com.xx  : main
com.xx.aspect : aspectler icin . Class isimleri XXXAspect
com.xx.model : bean ler icin
com.xx.service : servisler icin ( servislerden bean leri cagirma ) . XXXService
Conventionlarimiz olursa gerek class ismi, gerek servis ismi, aspect lerde
pointcut expression yazarken cok kolay olur. Cunku pointcut expression lar
da regular expression gibi. 

expression lari && ile baglayabilirsin
@Before("a" && "b")

Yeni bir annotation yaratirsin. xxxAnnotation
@Around("@annotation(com.xx.xxxAnnotation)")
dersin. Sonra advice istedigin metodun ustune gelip @xxxAnnotation dersin.
Sadece o annotation in bulundugu metodlari cagirir.

Annotation yerine, spring xml in icine de aspect leri tanimlayabiliriz.
<aop:config>
    <aop:aspect id="xx" ref="beanIsmi">
        <aop:pointcut id="allGetters" expression="execution("* get())"/>
        <aop:around method="xxx" pointcut-ref="allGetters"/>
    </aop:aspect> // bu aslinda class'a @Aspect tanimlamak ile ayni
</aop:config>

Aspect Class inin da bean xml icinde tanimlanmis olmasi lazim bunu tabi unutmamak lazim.
annotated ve xml solution icin de. 

Annotation genelde functionality acisindan, XML configuration acisindan tercih edilir.
Mesela transaction tanimlama functionality dir, debug mod ya da degil flag i mesela
xml configuration dir.