Archive for the 'translated' Category

DeadLock

admin September 14th, 2008

Translate from DeadLock and Deadlock Prevention of Jakob Jenkov’s tutorial
Thanks a ton to Jakob for allowing me to translate his excellent tutorial

Deadlock คือการที่เธรด (thread) สองเธรดหรือมากกว่านั้นถูกบล็อคการทำงานไว้เพื่อรอเข้าถือจองล็อค (lock) ที่มีเธรดอื่นใน deadlock นั้นได้ทำการจองไว้เรียบร้อยแล้ว. Deadlock สามารถเกิดขึ้นได้เมื่อเธรดต้องการล็อดเดียวกันพร้อมๆกัน เพียงแต่ได้ทำการขอจองล็อคเหล่านั้นในลำดับที่ต่างกันไป
ตัวอย่างเช่น เธรด1 ทำการจองล็อค A ไว้แล้ว และกำลังพยายามจะขอจองล็อค B แต่ในขณะนั้นเองเธรด2 ที่ได้ทำการจองล็อค B ไว้ได้แล้วก็พยายามจะขอจองล๊อค A ที่เธรด1 ถืออยู่ เธรด1 จะไม่มีวันได้ล๊อค B ไปและเธรด2 ก็ไม่มีวันจะได้ล็อค A ไป นอกจากนั้นแล้วทั้งสองเธรดต่างก็ไม่มีทางจะรู้ได้เลยว่าตัวเองต่างก็ไม่มีวันจะได้ล็อคที่ต้องการมา สถานการณ์เช่นนี้เรียกว่าเกิด deadlock ขึ้น
สถานการณ์นี้อาจจะแสดงให้เห็นได้ดังนี้
Thread 1 locks A, waits for B
Thread 2 locks B, waits for A

ตัวอย่างโค้ดด้านล่างนี้คือคลาส TreeNode ที่ได้ทำการเรียกเมธอดที่ทำการ synchronized ในแต่ละอินสแตนต่างกันไป

public class TreeNode {
  TreeNode parent   = null;
  List     children = new ArrayList();

  public synchronized void addChild(TreeNode child){
    if(!this.children.contains(child)) {
      this.children.add(child);
      child.setParentOnly(this);
    }
  }
  public synchronized void addChildOnly(TreeNode child){
    if(!this.children.contains(child) ) {
      this.children.add(child);
    }
  }
  public synchronized void setParent(TreeNode parent){
    this.parent = parent;
    parent.addChildOnly(this);
  }
  public synchronized void setParentOnly(TreeNode parent){
    this.parent = parent;
  }
}

จากตัวอย่างด้านบน deadlock สามารถเกิดขึ้นได้ ถ้าเธรด(1) ทำการเรียก parent.addChild(child) พร้อมๆกับที่เธรด(2) ทำการเรียก child.setParent(parent) บนอินสแตนของ parent และ child ชุดเดียวกันนี้ ด้านล่างเป็นโค้ดจำลองเพื่อแสดงให้เห็นสถานการณ์นี้

Thread 1: parent.addChild(child); //locks parent
–> child.setParentOnly(parent);

Thread 2: child.setParent(parent); //locks child
–> parent.addChildOnly()

เธรด1 เรียกใช้งาน parent.addChild(child) ซึ่งจากการที่ addChild() นั้นเป็น synchronized ดังนั้นเธรด1 ได้ทำการจองล็อคตัว parent อ็อบเจกต์ไว้ทำให้เธรดอื่นไม่สามารถเข้าใช้งานตัว parent อ็อบเจกต์นี้ได้ (ดูเพิ่มเติมข้อ1) ในขณะเดียวกันนั้นเธรด2 ก็ทำการเรียกใช้ child.setParent(parent) ซึ่ง setParent() ก็เป็น synchronized ดังนั้นเธรด2 ก็ได้ทำการจองล็อคตัว child อ็อบเจกต์ไว้ทำให้เธรดอื่นไม่สามารถเข้าใช้งานตัว child อ็อบเจกต์นี้ได้ (ดูเพิ่มเติมข้อ1) จากนั้นเธรด1 ก็ได้พยายามจะเรียกใช้งาน child.setParentOnly() แต่ก็พบว่า child อ็อบเจกต์ได้ถูกล็อคไปแล้วโดยเธรด2 ดังนั้นเธรด1จะเข้าสู่สถานะบล็อค (เพื่อรอจนกว่าคนที่ล็อค child อ็อบเจกต์ไว้จะปล่อยล็อค เธรด1จึงจะสามารถเข้าทำงานเมธอดนี้ได้) ในลักษณะเดียวกันนั้น เธรด2 ก็ได้พยายามจะเรียก parent.addChildOnly() แล้วก็พบว่า parent อ็อบเจกต์นั้นได้ถูกล็อคไปแล้วโดยเธรด1 เป็นผลให้ เธรด2เข้าสู่สถานะบล็อคเช่นเดียวกัน ถึงตอนนี้ทั้งสองเธรดต่างก็อยู่ในสถานะบล็อคเพื่อรอขอล็อคที่อีกเธรดหนึ่งถืออยู่

สถานการณ์ดังกล่าวข้างบนนั้นจะเกิดขึ้นได้เมื่อเธรดหนึ่งเรียก parent.addChild(child) และ อีกเธรดหนึ่งจะเรียก child.setParent(parent) ในขณะเวลาเดียวกัน บนชุด parent และ child อ็อบเจกต์เดียวกัน โค้ดตัวอย่างนี้อาจจะประมวลผลได้ถูกต้องไปเป็นระยะเวลานานจนกระทั่งเกิด deadlock ขึ้นสักวันนึงในทันทีทันใด

โปรดสังเกตุว่าเพื่อที่ deadlock จะเกิดขึ้นได้นั้นทั้งสองเธรดจะต้องพยายามจะขอจองล็อค “ในขณะเวลาเดียวกัน” จริงๆ ถ้าหากว่าเธรด1 เร็วกว่าเธรด2 สักนิดนึงและได้ทำการจองได้ทั้งล็อค A และ B แล้วละก็ จะทำให้เธรด2 เข้าสู่สถานะบล็อคตั้งแต่ตอนที่พยายามจะขอล็อค B แล้ว ซึ่งก็จะไม่ทำให้เกิด deadlock ขึ้น และเนื่องจากการจัดตารางลำดับเวลาการประมวลผลของเธรดนั้นเป็นสิ่งที่คาดเดาไม่ได้ ดังนั้นเราจึงไม่สามารถทำนายได้ว่า deadlock “จะเกิดขึ้นเมื่อไร” เราบอกได้แต่เพียง “มันสามารถเกิดขึ้นได้”

Deadlock ที่ซับซ้อนขึ้น
Deadlock ยังสามารถเกิดขึ้นได้กับเธรดมากกว่าสองซึ่งทำให้เราตรวจหามันได้ยากขึ้น. ด้านล่างเป็นตัวอย่าง เธรด 4 ตัวเกิด deadlock กัน
Thread 1 locks A, waits for B
Thread 2 locks B, waits for C
Thread 3 locks C, waits for D
Thread 4 locks D, waits for A

การป้องกันไม่ให้เกิด deadlock (Deadlock Prevention)
ในบางสถานการณ์นั้นเราสามารถป้องกัน deadlock ไม่ให้เกิดขึ้นได้ ผมจะอธิบายเทคนิคสามข้อดังต่อไปนี้
1. การจัดลำดับการจองล็อค (Lock Ordering)
2. การจำกัดเวลาในการจองล็อค (Lock Timeout)
3. การตรวจหา deadlock (Deadlock Detection )

1. การจัดลำดับการจองล็อค
Deadlock เกิดขึ้นเมื่อเธรดมากกว่าหนึ่งต้องการจองล็อคตัวเดียวกันแต่ทำการเข้าจองในลำดับที่ต่างกัน ถ้าเราสามารถบังคับให้การจองล็อคทั้งหมดนั้นเป็นไปในลำดับเดียวกันในทุกๆเธรดแล้ว deadlock ก็จะไม่เกิด พิจารณาตัวอย่างต่อไปนี้

Thread 1:

lock A
lock B

Thread 2:

wait for A
lock C (when A locked)

Thread 3:

wait for A
wait for B
wait for C

เมื่อเธรดใดๆ ต้องการล็อคหลายตัวแล้ว เธรดนั้นจะต้องเข้าของล็อคนั้นๆในลำดับที่ถูกกำหนดไว้ก่อนแล้ว เธรดจะต้องไม่จองล็อคสลับลำดับที่ได้กำหนดไว้ ตัวอย่างเช่น ทั้งเธรด 2 และเธรด 3 ต่างก็ไม่สามารถจะเข้าขอจองล็อค C ได้ถ้าไม่ได้ถือครองล็อค A ไว้ได้ก่อนแล้ว และเมื่อเธรด 1 ถือครองล็อค A ไว้อยู่ ดังนั้นเธรด 2 และเธรด 3 ต้องรอให้เธรด 1 ปล่อยการถือครองล็อค A เสียก่อน จากนั้นจึงเข้าถือครองล็อค A ไว้ได้สำเร็จจึงจะสามารถขอเข้าจองล็อค B และ C ต่อไป การจัดลำดับการเข้าจองล็อคนั้นเป็นวิธีที่เรียบง่ายและได้ผลดีในการป้องกันการเกิด deadlock อย่างไรก็ตาม วิธีนี้จะใช้ได้ก็ต่อเมื่อคุณรู้การใช้งานล็อคทั้งหมดล่วงหน้าก่อนการเข้าจองล็อคใดๆ ซึ่งนั่นก็ไม่ใช่สิ่งที่จะสามารถรู้ล่วงหน้าได้ในทุกกรณี

2. การจำกัดเวลาในการจองล็อค
วิธีการป้องกัน deadlock อีกวิธีหนึ่งคือการกำหนดเวลาในการพยายามจองล็อค นั่นคือเธรดจะพยายามขอจองล็อคในระยะเวลาหนึ่งก่อนที่จะเลิกล้มความพยายาม ถ้าเธรดใดไม่สามารถเข้าถือครองล็อคที่ต้องการไว้ได้ทั้งหมดในระยะเวลาที่กำหนด เธรดนั้นจะถอยกลับโดยปล่อยการถือครองล็อคทั้งหมดที่ถือไว้ จากนั้นทำการรอเป็นระยะเวลาหนึ่งก่อนจะพยายามใหม่ ที่ทำการรอเป็นช่วงเวลาหนึ่งนั้นก็เพื่อจะเปิดโอกาสให้เธรดอื่นเข้าขอจองล็อค (ที่เธรดนั้นได้เคยถือครองไว้ก่อนจะถอยกลับ) และทำให้โปรแกรมสามารถทำงานต่อไปได้

ด้านล่างนี้เป็นตัวอย่างของเธรดสองตัวพยายามจะเข้าจองล็อคชุดเดียวกันในลำดับที่ต่างกัน ซึ่งจะเห็นการถอยกลับและพยายามเข้าจองล็อคใหม่อีกครั้งของเธรดทั้งสองตัว

Thread 1 locks A
Thread 2 locks B

Thread 1 attempts to lock B but is blocked
Thread 2 attempts to lock A but is blocked

Thread 1’s lock attempt on B times out
Thread 1 backs up and releases A as well
Thread 1 waits randomly (e.g. 257 millis) before retrying.

Thread 2’s lock attempt on A times out
Thread 2 backs up and releases B as well
Thread 2 waits randomly (e.g. 43 millis) before retrying

ในตัวอย่างนั้นเธรด 2 จะพยายามเข้าจองล็อคใหม่อีกครั้งก่อนเธรด 1 เป็นระยะเวลาประมาณ 200 มิลลิเซค ซึ่งมีความเป็นไปได้สูงที่เธรด 2 จะประสบความสำเร็จในการเข้าจองล็อคทั้งสองตัว จากนั้นเธรด 1 จึงจะพยายามเข้าจองล็อค A ใหม่อีกครั้ง และเมื่อเธรด 2 ทำการประมวลผลเสร็จแล้ว (และทำการปล่อยการถือครองล็อคที่ถืออยู่) เธรด 1 ก็จะมีโอกาสจะเข้าจองล็อคทั้งสองตัวบ้าง (นอกจากว่าเธรด 2 หรือเธรดอื่นๆเข้าทำการจองล็อคชุดนี้แทรกระหว่างนั้น) ข้อควรจำอย่างหนึ่งคือ การที่เธรดไม่สามารถจองล็อคได้สำเร็จ ในระยะเวลาที่กำหนดนั้นไม่ได้หมายความว่าเป็นเพราะมี deadlock เกิดขึ้นเสมอไป อาจจะเป็นได้ว่าเธรดที่ถือครองล็อค (จนทำให้เธรดอื่นหมดเวลาในการพยายามเข้าจองล็อค ) อยู่นั้น ใช้เวลานานในการทำงานจนสำเร็จ นอกจากนั้นแล้ว ถ้ามีเธรดจำนวนมากเข้าแย่งกันขอจองล็อคแล้ว มีโอกาสสูงที่เธรดจะเข้าแย่งกันจองล็อคพร้อมๆกันครั้งแล้วครั้งเล่า แม้ว่าจะเกิดกระบวนการถอยกลับแล้วพยายามใหม่แล้วก็ตาม เหตุการณ์เช่นนี้ อาจจะไม่เกิดกับเธรดแค่สองตัวที่ทำการรอเป็นเวลา 0 ถึง 500 มิลลิเซค ก่อนพยายามใหม่อีกครั้ง แต่ถ้าหากพูดถึงเธรด 10 – 20 ตัวละก็อีกเรื่องหนึ่ง มีโอกาสสูงที่สองเธรดจะรอเป็นเวลาเท่าๆกัน (หรือใกล้เคียงกันพอที่จะทำให้เกิดปัญหา) ก่อนจะเริ่มพยายามจองล็อคใหม่อีกครั้ง ปัญหาอย่างหนึ่งของการกำหนดเวลาในการจองขอจองล็อคก็คือ เราไม่สามารถจะจำกัดเวลาสำหรับ synchronized block (โค้ดส่วนที่ถูกครอบด้วย synchronized keyword) ได้ เราอาจจะต้องสร้างล็อคขึ้นเองหรือไม่ก็ใช้ล็อคของ Java 5 ใน java.util.concurrency

3. การตรวจหา deadlock
การตรวจหา deadlock นั้นจะถูกใช้ในกรณีที่การจัดลำดับการจองล็อคและการกำหนดเวลาในการพยายามจองล็อคนั้นไม่สามารถทำได้ โดยทุกครั้งที่เธรดได้ทำการถือครองล็อคไว้ เธรดนั้นจะถูกบันทึกไว้ในโครงสร้างข้อมูล (map , graph etc.) ของเธรดและล็อค นอกจากนั้นแล้วเมื่อไรก็ตามที่เธรดทำการขอเข้าจองล็อคตัวใด ข้อมูลการร้องงขอนี้ก็จะถูกบันทำไว้ด้วย เมื่อเธรดหนึ่งเธรดใดขอเข้าจองล็อคแล้วถูกปฏิเสธ เธรดนั้นสามารถตรวจสอบกราฟของล็อคเพื่อตรวจหา deadlock ได้ ตัวอย่างเช่น ถ้าเธรด A ขอจองล็อค 7 ที่ถูกถือครองไว้โดยเธรด B แล้ว เธรด A สามารถตรวจสอบได้ว่าเธรด B ได้ทำการขอจองล็อคใดๆที่เธรด A ได้ถือครองอยู่หรือไม่ ถ้าใช่ก็แสดงว่าเกิด deadlock ขึ้น (เธรด A ถือครองล็อค 1 ไว้อยู่และกำลังพยายามขอจองล็อค 7 ขณะเดียวกันเธรด B ได้ทำการถือครองล็อค 7 ไว้และกำลังพยายามจะขอจองล็อค 1) แน่นอนว่ารูปแบบการเกิด deadlock นั้นสามารถมีความซับซ้อน ได้มากกว่าการที่สองเธรดต่างถือครองล็อคที่อีกเธรดหนึ่งต้องการ เธรด Aอาจจะรอเธรด B, เธรด B รอเธรด C, เธรด C รอเธรด D และเธรด D รอเธรด A การที่เธรด A จะสามารถตรวจหา deadlock ได้นั้น เธรด A ต้องตรวจสอบล็อคทั้งหมดที่ที่เธรด B ต้องการทั้งหมดทั้งทางตรงและทางอ้อม จากล็อคที่เธรด B ร้องขอโดยตรงนั้น เธรด A จะต้องมองไปถึงเธรด C (เพราะ เธรด C ถือล็อคตัวหนึ่งที่เธรด B ต้องการอยู่ เธรด A จึงเหมือนกับรอเธรด C ไปด้วย) จากเธรด C มองต่อไปจนถึงเธรด D จึงจะพบว่ามีล็อคตัวหนึ่ง (ที่เธรด B ต้องการทั้งทางตรงและทางอ้อม) ที่ถูกถือครองไว้แล้วโดยเธรด A ถึงตอนนี้จึงสรุปได้ว่าเกิด deadlock ขึ้น ตัวอย่างด้านล่างคือกราฟของล็อคที่ถูกถือครองอยู่ (taken) และกำลังถูกร้องขอการเข้าจอง (requested) ของเธรดสี่ตัว A, B, C และ D โครงสร้างข้อมูลเช่นนี้สามารถนำมาใช้ตรวจหา deadlock ได้

ถามว่าจะทำอย่างไรถ้าเกิด deadlock ขึ้น?
ทางหนึ่งที่เป็นไปได้คือปล่อยการถือครองล็อคทั้งหมด ทำการถอยกลับรอเป็นระยะเวลาหนึ่งแล้วเริ่มพยายามใหม่อีกครั้ง ซึ่งเป็นวิธีเดียวที่ใช้กับการจำกัดเวลาการพยายามจองล็อคต่างกันที่ทำเฉพาะตอนที่เกิด deadlock ขึ้นจริงๆเท่านั้น อย่างไรก็ตาม ถ้าเธรดจำนวนมากทำการเแย่งขอจองล็อคตัวเดียวกันแล้ว ก็มีโอกาสที่เธรดจะเกิด deadlock ซ้ำๆกันบ่อยคร้งแท้ว่าจะทำการถอยกลับและรอพยายามใหม่แล้วก็ตาม

10 เรื่องที่โปรเจคเมเนเจอร์อยากให้ดีเวลลอปเปอร์เข้าใจ

admin September 14th, 2008

Translated from : 10 things Project Managers wish Developers understood
Author : Frank Kelly

ตลอดสองสามเดือนมานี้ผมยุ่งมาก ในการปรับตัวกับบทบาทใหม่ในการเป็น โปรเจคเมเนเจอร์ โดยทางเทคนิคแล้วผมจะถูกเรียกว่า “team lead” หรือ “director” หรือ “senior manager” แล้วแต่ว่าใครจะเรียก หน้าที่จริงๆของผม คือประสานงานกับโปรดักเมเนเจอร์ ในการบริหารจัดการทีมพัฒนาซอฟแวร์ ตามแผนงานของโปรเจค การได้มาอยู่ใน “อีกด้านหนึ่ง” สักพักนึงแล้วนั้นเหมือนกับการได้เปิดตาสู่โลกใหม่ มันเป็นเรื่องจริงที่ว่ามันเป็นเรื่องยากมากๆในการเข้าถึงใครสักคนนั้น จนกว่าคุณจะได้ลองทำลองเป็นอย่างที่คนๆนั้นเป็น จากที่ได้เคยร่วมงานกับโปรเจคเมเนเจอร์มา ผมเคยสงสัยอยู่ตลอดว่าทำไมเรื่องบางอย่างถึงดำเนินไปในบางแนวทาง มันเป็นแนวทางที่ผมเคยคิดว่าผมจะเลือกทำสิ่งที่ต่างออกไป ตอนนี้ผมคงไม่คิดอย่างนั้นอีกแล้ว จากประสบการณ์ในการพยายามทำในสิ่งเหล่านั้น ที่เคยพูดไว้หรือคิดไว้ ผมอยากจะเขียนถึงสิ่งต่างๆ ที่ดีเวลลอปเปอร์ในทีมไม่ได้นึกไปถึง จนกว่าพวกเขาจะได้ลองมาเป็นคนจัดการเอง

10) การท่วมล้นของข้อมูล: ผมก็อยากจะตั้งสมาธิ กับเรื่องใดเรื่องหนึ่ง เป็นอย่างๆไปเหมือนกัน แต่ผมมีคนเป็นล้านพุ่งเข้าหาผมจากทุกทิศทาง
ไม่ว่าจะเป็นโปรดักเมเนเจอร์, ซัพพอร์ท (support), เมเนจเมนท์ (management), เหล่าลูกค้ากับความต้องการต่างๆ, ดีเวลลอปเปอร์ รวมไปถึงเมเนเจอร์, อาร์คีเทค (architects) และดีเวลลอปเปอร์ในทีมอื่นๆอีก มันเป็นข้อมูลและความสัมพันธ์เป็นจำนวนมากที่ต้องบริหารจัดการ ดังนั้นอย่าแปลกใจถ้าคุณเจอกับการโต้ตอบในลักษณะต่อไปนี้

ดีเวลลอปเปอร์ : คุณยังจำปัญหาเรื่อง GUI ในสัปดาห์ที่แล้วได้หรือเปล่า?
(อีกนัยหนึ่งคือ: เจ้าปัญหาร้ายแรงนั่น ที่ผมหาทางแก้ได้ในที่สุดนั่นไง)
เมเนเจอร์: ปัญหาอันไหนละ?
(อีกนัยหนึ่งคือ: ผมเพิ่งจะใช้เวลา 3 ชั่วโมงในการตอบเมลล์กับคนอื่นอีก 14 คน และผมเหนื่อยเหลือเกิน)

9) ความกดดันในการทำงาน: เมเนเจอร์บางครั้งอาจจะตื่นเต้น และรู้สึกกดดันจนเกินไป จนพยายามที่จะ “ชี้ทางแก้ปัญหา” ให้กับดีเวลลอปเปอร์. ปฏิเสธ (อย่างสุภาพ) ไปก็ได้ถ้าหากเห็นว่ามันไม่เหมาะสม
เมื่อคุณมาเป็นเมเนเจอร์และไม่ได้เขียนโค้ดอีกต่อไป คุณจะต้องแบกรับความรับผิดชอบ(ความกังวล) ในการทำงานให้เสร็จตามกำหนด แต่คุณมีอำนาจในการควบคุมมันน้อยเหลือเกิน เหล่าเมเนเจอร์ที่ใช้เวลาเป็นดีเวลลอปเปอร์ไปด้วยในบางครั้ง มักจะคิดว่าพวกเขาสามารถที่จะชี้ทางแก้ปัญหาให้กับดีเวลลอปเปอร์คนอื่นๆได้ แต่นั่นมันไม่ได้ผลหรอก ดีเวลลอปเปอร์เป็นพวกมีความคิดสร้างสรรค์และ(ไม่ว่าจะดีหรือไม่) เป็นพวกยึดมั่นในความคิดของตัวเอง (egotistical) สูง (ผมก็เป็นหนึ่งในนั้น) และพวกเราชอบที่จะทำอะไรให้ประทับใจหัวหน้า มากกว่าที่จะแค่รับคำสั่งไปปฏิบัติตาม ผมได้เรียนรู้ที่จะถามคำถาม ในเชิงชี้นำหรือในเชิงการหาข้อมูล มากว่าการชี้ทางแก้ปัญหา ตัวอย่างเช่น

  • จะมีกี่ไฟล์ที่ได้รับผมกระทบจากการแก้ปัญหานี้ละ
  • การเปลี่ยนของ SQL อันนี้จะกระทบกับประสิทธิภาพการทำงานยังไง
  • การเปลี่ยนของ GUI นี้จะกระทบต่อการทำงานของลูกค้าหลักของเรายังไง
  • ถ้าเราแก้ปัญหานี้แล้วมันจะไปทำให้เกิดปัญหาที่อื่นหรือเปล่า

8 ) ความเสี่ยงของโปรเจค: เทคโนโลยีใหม่ = ความเสี่ยง
ทุกครั้งที่คุณเริ่มต้นโปรเจคใหม่ ดีเวลลอปเปอร์ก็ชอบที่จะใช้เทคโนโลยีใหม่ๆ แต่คุณจะทุ่มทุกอย่างลงไปกับเทคโนโลยีใหม่ไม่ได้ เทคโนโลยีใหม่ย่อมจะนำความเสี่ยงมาสู่โปรเจค ประสิทธิภาพอาจจะเพิ่มขึ้นแต่มันจะคุ้มกับความเสี่ยงหรือเปล่า
ผมเคยมีเมเนเจอร์ที่เอาแต่ปฏิเสธเทคโนโลยีใหม่ๆ เขาไม่เข้าใจถึงความต้องการของดีเวลลอปเปอร์ ในการพัฒนาตัวเองและเรียนรู้เทคโนโลยียอดฮิต (อย่างเช่น Ajax)/ เฟรมเวิร์ค (อย่างเช่น Spring) มันช่างไม่เป็นที่น่าจูงใจเอาเสียเลย อีกอย่างหนึ่งคือ เทคโนโลยีมักจะช่วยให้ทำงานได้ประสิทธิภาพมากขึ้น มันไม่ใช่แนวคิดที่มองการณ์ไกลเลย ในการเอาแต่ปฏิเสธเทคโนโลยีใหม่ๆ
ผมก็เคยมีเมเนเจอร์ ที่คอยแต่มองหาเทคโนโลยีใหม่ๆเหมือนกัน แล้วโปรเจคก็ไปติดแหง่ก อยู่กับปัญหาทางเทคนิคอันแล้วอันเล่า และไม่เคยทำให้ซอฟแวร์ทำงานได้ ภายในเวลาที่กำหนดได้เลย เนื่องจากดีเวลลอปเปอร์ต้องใช้เวลามาก ในการเรียนรู้เทคโนโลยีใหม่ๆเหล่านั้น ในฐานะที่ผมก็เป็นดีเวลลอปเปอร์ ผมเข้าใจว่าพวกเขารักที่จะเรียนรู้ แต่ในฐานะของเมเนเจอร์ ผมต้องชั่งน้ำหนัก ระหว่างแรงจูงใจของดีเวลลอปเปอร์ กับเป้าหมายในการทำให้โปรดักสำเร็จใช้งานได้

7) ประสิทธิภาพ: เมเนเจอร์ที่ยอดเยี่ยม จะกันดีเวลลอปเปอร์ออกจากเรื่องบ้าบอต่างๆ ที่เกิดขึ้นในระหว่างการบริหารงาน อย่างเช่น เสปคที่ไม่ได้เรื่อง, แนวความคิดแปลกๆ, การเปลี่ยนลำดับความสำคัญของงาน หรือการประชุมที่มากจนเกินไป
ถ้าคุณคิดว่าหัวหน้างี่เง่า (pointy haired boss) ของคุณนั้นช่างเสียสติจริงๆ รอให้คุณเห็นพวกคนที่เขาทำงานให้ก่อนเถอะ ปัญหาในการพัฒนาซอฟแวร์ในปัจจุบันก็คือ มันต้องเกี่ยวข้องกับทีมมากมายหลายทีม ทีมของดีเวลลอปเปอร์, ทีมของ QA, ซัพพอร์ท, ฝ่ายลูกค้าสัมพันธ์, ฝ่ายที่ปรึกษา และทุกคนต่างก็มีมุมมองและเป้าหมายของตัวเอง พวกเขามีมุมมองในภาพที่ใหญ่กว่า หรือเป็นอีกมุมมองหนึ่งต่างออกไปเลย ดีเวลลอปเปอร์บางคนก็พอคิดได้ว่า ขณะที่สิ่งเหล่านี้ดำเนินไปนั้น เมเนเจอร์กำลังกันเวลาไว้ เพื่อให้คุณทำงานได้อย่างมีประสิทธิภาพ และทำในสิ่งที่คุณรัก นั่นคือการเขียนโค้ด

6) การแสวงหารายได้: บริษัทนั้นอยู่เพื่อต้องการทำเงิน บางครั้งคุณก็ต้องทำเรื่องที่คล้ายว่าโง่ๆเพื่อที่จะได้เงินมา
ลูกค้านั้นก็ใช่ว่าจะมีเหตุมีผลทุกคนไป พวกเขามีเป้าหมายและมุมมองของตัวเอง บางครั้งพนักงานงายก็ต้องยอมสัญญาว่าจะทำอะไรบางอย่าง เพื่อให้ข้อตกลงทางการค้าเกิดขึ้นได้ แน่นอนละว่ามันฟังดูมีเหตุมีผลเพียงพอทีเดียว ถ้าหากว่าคุณไม่ใช่คนที่จะต้องสร้างมันขึ้นมานะ แน่นอน คุณมีสิทธิ์ที่จะต่อว่าเอากับพนักงานขายนั้น แต่ก็นั่นละ ยังไงบริษัทที่คุณทำงานอยู่ก็ถูกตั้งขึ้นมาเพื่อ (หวังว่าจะ) หาเงิน พนักงานเขายก็เปรียบได้กับคนหาช่องทางทำเงิน ดังนั้นดีที่สุดที่คุณทำได้คือ สร้างความสัมพันธ์ที่เกื้อกูลกัน โดยพวกเขาทำการปรึกษาคุณว่าอะไรที่สามารถเป็นไปได้ และอะไรที่เกินขอบเขตไป

5) ทำในสิ่งที่เราไม่อยากทำ: เราเรียกประชุมก็เพราะมันเป็นสิ่งที่จำเป็น
ผมรู้ว่าการประชุมนั้นขัดจังหวะการเขียนโค้ด อันเป็นกิจกรรมสุดโปรดของคุณ แต่มันก็เป็นสิ่งที่ช่วยไม่ได้เลยในบางโอกาส ผมต้องการรู้ว่า คุณเข้าไจความเป็นไปในขณะนี้หรือไม่ จริงๆแล้วผมแทบจะไม่รู้เลยว่า ความคืบหน้าเป็นอย่างไรบ้างแล้ว จนกว่ามันใกล้ๆจะเสร็จโน่นแหละ โชคดีอยู่บ้าง ในฐานะที่ผมก็เป็นดีเวลลอปเปอร์(ในบางโอกาส) ผมใช้เครื่องมือเช่น FindBugs, PMD, CheckStyle เพื่อตรวจสอบโค้ด และใช้ Unit Test กับ Code Coverage เพื่อประเมิณคุณภาพของโค้ดอย่างคร่าวๆ แต่สิ่งที่วัดได้ก็เป็นแค่ตัวแทนของค่าที่ต้องการจริง นั่นก็คือ คุณภาพของโปรดักในมุมมองของผู้ใช้งานเท่านั้นแล้วมีวิธีอื่นไหนอีก ที่จะทำให้ผมรู้ความไปต่างๆได้อย่างรวดเร็ว การประชุมไงละ ขอโทษด้วยแล้วกันนะ

4) การท่วมล้นของจ้อมูล ภาคสอง: อย่าหวังว่าผมจะจดจำสิ่งต่างๆได้ทุกเรื่องไป
ผมลืมไปเลยที่เราได้สัญญากันว่าจะนัดคุยกันเรื่องปัญหานั้น ผมอยากจะใส่ตัวเรียกเตือนความจำไว้ใน Outlook แต่ก็ดันถูกขัดจังหวะสองครั้ง แล้วยังถูกตามตัวไปหาหัวหน้าอีก แล้วผมก็ลืมไปเลย เข้าใจเมเนเจอร์ของคุณสักนิดเถอะ พวกเขาได้พยายาม (หรือควรจะพยายาม) แล้วจริงๆ ถ้าหากผมหลงลืมไปก็ช่วยเตือนด้วย ให้ผมอยู่ในวงข่าวสาร แค่หาโอกาสเหมาะๆบอกผมเท่านั้นละ

3) การท่วมล้นของจ้อมูล ภาคสาม: อย่าเพิ่งลงไปถึงรายละเอียดเลย บอกผมก่อนเถอะว่าทำไมผมต้องสนใจมันด้วย
ดีเวลลอปเปอร์มีมากมายหลายแนว บางคนก็เก็บงำข้อมูลต่างๆ ก้มหน้าก้มตาอยู่ในห้องทำงานของตัวเอง โผล่มาอีกทีก็ต่อเมื่องานเสร็จแล้ว ที่น่ากลัวก็คือ คุณไม่มีทางรู้เลยว่าพวกเขาทำงานเสร็จแล้ว จนกว่า … อืม .. จนกว่าพวกเขาจะทำเสร็จนั่นละ ผมจัดการกับคนประเภทนี้ค่อนข้างง่าย ก็แค่ไปสอบถามเป็นระยะๆ และหวังว่าคงไม่ต้องทำบ่อย อีกฝั่งนึง คือดีเวลลอปเปอร์ที่คิดเอาว่า คุณคงอยากจะรู้ไปซะทุกรายละเอียดยิบย่อย และหวังให้คุณรู้ถึงผลกระทบของมัน ตัวอย่างเช่น

ดีเวลลอปเปอร์: “คุณรู้เรื่องคลาส Finder ที่ทีม X ทำขึ้นมาหรือยัง พวกเขาสร้าง Factory เมธอดอันไหม่ที่ไม่ปลอดภัยในการทำงานกับ thread ขึ้นมา ผมคิดว่ามันบ้ามากเลยละ พวกเขาไม่รู้เลยหรือไงว่า thread pool ของเราจะ … … …”
เมเนเจอร์(ผู้ที่กำลังครุ่นคิดอย่างหนักกับเรื่องอื่นอยู่ อย่างความขึ้นต่อกันต่างๆในโปรเจค): (คิดในใจ) เขาจะคิดว่าผมเป็นพวกงี่เง่าหรือเปล่านะ ถ้าผมจะตอบแค่ว่า “หือ”

มันจะดีกว่าถ้าคุณบอกแค่ผลกระทบและเอาเรื่องรายลเอียดไว้ทีหลัง เช่น “ผมคิดว่าการทำงานแบบผู้ใช้งานหลายคนของเราจะมีปัญหากับโค้ดอันไหม่ของทีม X” นั่นมันตรงประเด็นเลย (มีปัญหาเกิดขึ้น) และยังทำให้ผมไม่ต้องไปคิดมากมาย (ทำไมผมต้องสนใจเรื่อง ความปลอดภัยในการทำงานกับ thread ของคลาสบางคลาสด้วย)

2) คุณ (ดีเวลลอปเปอร์) ไม่ได้สำคัญอยู่คนเดียว
ผมเคยสำคัญผิดแบบนั้นไปพักหนึ่ง สมัยเมื่อผมยังเป็นดีเวลลอปเปอร์อยู่ ผมคิดจริงๆว่าในปัญหาทั้งหมดที่เผชิญอยู่ ปัญหาที่ผมรับผิดชอบอยู่นั้นสำคัญที่สุด ผมจะรู้สึกหัวเสีย เมื่อปัญหาที่ผมมองว่าสำคัญถูกมองข้ามไป ในความเป็นจริงแล้วก็คือ ผมไม่คิดไปถึงปัญหาอื่นอีกหลายๆอย่าง ที่มีความสำคัญกว่าเลย ว้าว มันขึ้นอยู่กับมุมมองจริงๆ

1) เป็นราชานี่มันก็ดีเหมือนกัน
ความจริงแล้วมันดีมากๆเลยละ สมัยก่อนที่ผมเป็นอาร์คีเทค หรือหัวหน้าวิศวกรซอฟแวร์ ผมอยู่ในตำแหน่งที่สามารถให้ข้อมูลช่วยการตัดสินใจได้ แต่ก็ไม่ได้มีอำนาจจริงๆอะไรเลย ตอนนี้ผมมีผู้คนที่ต้องรายงานตรงต่อผม ผมควบคุมการประเมินงาน และอัตตราการขึ้นเงินเดือนของพวกเขา ดูว่าพวกเขาควรจะทำงานแค่ไหน และล่าช้าได้เท่าไร หรือตัดสินใจว่าควรจะทำโปรเจคไหนต่อไป ผมยังคงมองตัวเองว่าเป็นอาร์คีเทคอยู่ และผมรักที่จะเขียนโค้ด แต่มันดีมากเลยที่ผมรู้เรื่องเทคโนโลยี หรือเรื่องแรงจูงใจของดีเวลลอปเปอร์ และยังมีส่วนสำคัญในการตัดสินใจว่าอะไรควรจะต้องทำหรือทำอย่างไรในที่สุด

ตัวอย่างเช่น เรามีโค้ดที่ค่อนข้างซับซ้อนที่เราเพิ่งเขียนขึ้นไม่นานมานี้ ด้วยความซับซ้อน(ที่จำเป็น) นั้นทำให้โค้ดค่อนข้างบอบบาง ถ้าอยู่ในฐานะที่เป็นดีเวลลอปเปอร์ ผมอาจจะรู้สึกขี้เกียจ หรืออาจจะไม่มีเวลามากพอที่จะเขียนยูนิทเทสให้ครอบลุมทั้งหมด ถ้าอยู่ในฐานะที่เป็นอาร์คีเทค ผมรู้ว่านั่นเป็นสิ่งที่เราต้องทำ แต่บ่อยครั้งที่ผมไม่สามารถกล่อมโปรเจคเมเนเจอร์ ให้จัดเวลาให้ดีเวลลอปเปอร์ได้เขียนยูนิทเทสนั้นได้ ตอนนี้ผมเป็นโปรเจคเมเนเจอร์ ที่สามารถอ่านตัวเลขค่า code coverage ได้อีกทั้งยังรู้เรื่องการใช้งานโปรดักของผู้ใช้อีกด้วย ผมก็เลยให้ดีเวลลอปเปอร์เขียนยูนิทเทสประมาณ 40 ตัว ครอบคลุมการประมวลผลลักษณะต่างๆทั้งหมด กินเวลาเกือบเดือน ถึงจะเสร็จเรียบร้อย (กระอักเลยทีเดียว) แต่กระบวนการนั้นก็ช่วยให้เราค้นพบจุดบกพร่องใหม่ 3 จุด ในที่สุดแล้ว เราได้จำกัดความเสี่ยงหลายๆอย่าง ที่เคยมีอยู่ในโค้ดส่วนนั้น เมื่อมีจุดบกพร่องในโปรแกรมอันใหม่พบจากการใช้งานจริงหรือมาจาก QA เราก็จะสามารถแก้ไขมัน และสั่งประมวลผลยูนิทเทสนั้นอีกครั้ง ได้อย่างรวดเร็ว เรายังได้เพิ่มยูนิทเทส สำหรับตรวจสอบจุดบกพร่อง ที่เราเพิ่งพบนั้นด้วย คราวนี้ในฐานะที่เป็นเมเนเจอร์ ผมรู้ว่าเมื่อเราประมวลผลยูนิสเทสแล้วไม่พบปัญหาใดๆ ถึงแม้ว่าโค้ดจะมีความซับซ้อนเพียงใด เราก็ยังอยู่ในสถานะที่ดีทีเดียวเมื่อมองในมุมของ การประเมินความเสี่ยงเทียบกับคุณภาพ แน่นอนว่ามันเป็นสิ่งที่ต้องชั่งส่วนได้ส่วนเสีย เราพบว่าเราต้องเขียนยูนิทเทสเพิ่มเติม สำหรับโค้ดส่วนนี้ (ประเมินจากการใช้งาน ของผู้ใช้โปรแกรมในช่วงทดลองใช้) แต่เรากำลังอยู่ในความกดดัน ในการทำโค้ดส่วนอื่นให้เสร็จ ภายในไม่กี่สัปดาห์ข้างหน้า ดังนั้นเราจึงชะลอเรื่องยูนิทเทสนี้ไว้ก่อน แล้วจึงจะกลับมาทำทีหลัง
นอกจากนั้นมันยังมีส่วนดีเกี่ยวกับการจ้างงานอีกด้วย เมเนเจอร์น้อยเหลือเกิน ที่รู้วิธีดูดีเวลลอปเปอร์เก่งๆ อาศัยที่ผมเคยเป็นดีเวลลอปเปอร์ และมีประสบการณ์ไม่น้อย เกี่ยวกับคำถามในการคัดคน และเทคนิคในการสัมภาษณ์ ผมคิดว่าผมค่อนข้างเก่งทีเดียวในการชี้ตัวคนมีความสามารถ ผมมักจะทำการคัดเบื้องต้นก่อน เพื่อ ลูกทีมของผม จะได้ทำการสัมภาษณ์ผู้สมัครที่มีคุณภาพ ที่ไม่ได้ดีแต่พูดหรือมีคำหรูๆในใบสมัครงาน แต่ไม่มีความสามารถมารองรับเท่านั้น

Reflections on Java Reflection

admin September 14th, 2008

Translated from : Reflections on Java Reflection

Author : Russ Olsen

Thanks to Russ who allow me to translate his blog here

Russ is also the author of Design Patterns in Ruby

ในชีวิตปกติ รีเฟลคชัน (reflection) คือภาพสะท้อนในกระจก แต่ในโลกของการเขียนโปรแกรมแล้ว รีเฟลคชันคือการที่โปรแกรม สามารถรู้ถึงโครงสร้างของตัวเอง และยังสามารถปรับเปลี่ยนโครงสร้างนั้นได้อีกด้วย Java reflection API มอบหน้าต่างให้คุณมองเข้าไปสู่ ค่าพื้นฐานต่างๆของภาษา นั่นคือ คลาส, ฟิลด์และเมท็อด ผ่านทาง Java API ธรรมดาง่ายๆ
การเข้าใจ รีเฟลคชัน จะช่วยให้คุณ เข้าใจเครื่องมือต่างๆ ที่คุณใช้อยู่ประจำวันเช่น eclipseทำ auto-completion ของชื่อเมท็อดได้อย่างไร หรือ Tomcat สามารถสร้าง servlet ขึ้นมาใช้งานได้ จากเพียงแค่ชื่อของคลาสใน web.xml ได้อย่างไร และ Spring ควบคุมการทำ dependency injection ราวกับมายากลนั้นได้อย่างไร ด้วยรีเฟลคชันคุณสามารถเขียนโค้ดที่มีความยืนหยุ่น ได้มากกว่าระดับไดนามิค นั่นคือโปรแกรมของคุณ สามารถจัดการกับคลาส ที่มันไม่เคยเจอมาก่อนเลยได้
การเรียก Class มาใช้งาน
ดังที่ผมได้พูดไปแล้วว่า แนวคิดพื้นฐานของรีแฟลคชัน คือการใช้ Java API ธรรมดาๆเข้าไปดูการทำงานข้างในของตัวโปรแกรม เนื่องจากสิ่งที่เป็นพื้นฐานที่สุดของจาวาคือคลาส (ลองเขียนจาวาโปรแกรมสักอันโดยไม่ต้องใช้คลาสดูสิ) ดังนั้นจุดเริ่มต้นที่ดีที่สุดก็คือการเรียนรู้คลาสที่ชื่อว่า “Class” ทุกคลาสในจาวาจะมีอ็อบเจกต์ตัวหนึ่งซึ่งเก็บข้อมูลทุกอย่างเกี่ยวกับคลาสนั้นไว้ อ็อบเจกต์นั้นเป็นอ็อบเจกต์ของคลาส Class คุณสามารถดึงเอาข้อมูลทุกอย่างของคลาสนั้นจากมันได้ (ต่อไปนี้จะขอเรียกอ็อบเจกต์ตัวนี้ว่า คลาสอ็อบเจกต์)เช่น ชื่อของคลาส หรือข้อมูลว่าคลาสนั้นเป็น public หรือ abstract หรือ final หรือไม่ หรือแม้กระทั่งข้อมูลของคลาสแม่ของมัน เรามาลองใช้รีเฟลคชันส่องดูคลาส Employee ง่ายๆอันนี้กัน

package com.russolsen.reflect;

public class Employee
{
   public String _firstName;
   public String _lastName;
   private int _salary;

      public Employee(){
        this( "John", "Smith", 50000);
      }

   public Employee(String fn, String ln, int salary){
      _firstName = fn;
      _lastName = ln;
      _salary = salary;
   }

   public int getSalary(){
      return _salary;
   }

   public void setSalary(int salary){
      _salary = salary;
   }

   public String toString(){
      return "Employee: " + _firstName +  " "
             + _lastName + " " + _salary;
   }

}

วิธีที่ง่ายที่สุดในการนำเอาคลาสอ็อบเจกต์มาใช้ ก็คือเพียงแค่ใช้เมท็อด getClass เรียกเอาคลาสอ็อบเจกต์ของอ็อบเจกต์ตัวนั้นออกมา โค้ดข้างล่างนี้สร้างอ็อบเจคต์ของ Employee ดึงเอาคลาสอ็อบเจกต์ของมันออกมา และทำการแสดงค่าข้อมูลบางอย่างของคลาสนั้น

package com.russolsen.reflect;
import java.lang.reflect.Modifier;

public class GetClassExample{

   public static void main(String[] args){

      Employee employee = new Employee();

      Class klass = employee.getClass();

      System.out.println( "Class name: " + klass.getName());
      System.out.println( "Class super class: " + klass.getSuperclass());

      int mods = klass.getModifiers();
      System.out.println( "Class is public: " + Modifier.isPublic(mods));
      System.out.println( "Class is final: " +  Modifier.isFinal(mods));
      System.out.println( "Class is abstract: " + Modifier.isAbstract(mods));
   }
}

ทำการสั่งประมวลผลโค้ดข้างบนนี้แล้วคุณจะเห็น:
Class name: com.russolsen.reflect.Employee
Class super class: class java.lang.Object
Class is public: true
Class is final: false
Class is abstract: false

ดังที่เห็นในตัวอย่าง การดึงข้อมูลชื่อของคลาสและคลาสแม่นั้น ง่ายพอๆกับการเรียกเมท็อดสำหรับดึงข้อมูลธรรมดาๆ ถ้าคุณอยากจะรู้ว่าคลาสนั้นเป็น public หรือ abstract หรือ final กระบวนการจะยากขึ้นเล็กน้อย ข้อมูลเหล่านั้นจะถูกแสดงอยู่ในรูปของ int ตัวหนึ่งซึ่งได้มาจากการเรียกเมท็อด getModifiers และคุณสามารถใช้สแตติคเมท็อดทั้งหลายในคลาส Modifier เพื่อช่วยตีความค่าตัวเลขนั้น

การเรียกเมท็อด getClass นั้น ไม่ได้เป็นทางเดียวในการเรียกใช้งานคลาสอ็อบเจกต์ คุณยังสามารถเรียกเอาคลาสอ็อบเจกต์ออกมาโดยตรงจากชื่อคลาสนั้นก็ได้

Class klass = Employee.class;

วิธีที่สามในการดึงคลาสออกมาใช้งานนั้น น่าสนใจทีเดียว คุณสามารถสร้างอ็อบเจกต์ของ Class จากสตริงได้ ซึ่งสตริงนั้นก็ต้องมีค่าเป็นชื่อของคลาสด้วย วิธีการก็คือเรียกเมท็อด forName ของคลาส Class

Class klass = Class.forName("com.russolsen.reflect.Employee");

System.out.println( "Class name: " + klass.getName());
System.out.println( "Class super class: " + klass.getSuperclass());

// Print out the rest...

สิ่งหนึ่งที่ต้องจดจำไว้เสมอก็คือ คุณจะต้องใช้ชื่อเต็มของคลาส ซึ่งเป็นชื่อที่รวมชื่อของ package ของคลาสนั้นด้วย คุณไม่สามารถใช้แค่ชื่อ “Employee” คุณจะต้องใช้ “com.russolsen.reflect.Employee” จากการใช้งานเมท็อด forName นั้นเราก็เริ่มจะเห็นพลังความสามารถพื้นฐานของรีเฟลคชัน นั่นคือคุณสามารถใช้ชื่อของคลาสในสตริง เพื่อสร้างคลาสอ็อบเจกต์เอามาใช้งานได้

สร้างอินสแตนได้ในทันที
การดึงเอาคลาสอ็อบเจกต์ออกมาเพื่อเรียกดูค่าต่างๆของมัน ก็มีความน่าสนใจ และมีประโยชน์ในตัวของมันเองอยู่แล้ว แต่การได้ ”ทำอะไรบางอย่าง” จริงๆกับคลาสนั้นเป็นสิ่งที่ทำให้รีเฟลคชัน เริ่มที่จะดูน่าตื่นเต้นขึ้น และสิ่งที่ชัดเจนที่สุดในการใช้งาน Class ก็คือการสร้างอินสแตนใหม่ของคลาสนั้น
วิธีที่ง่ายที่สุดก็คือการใช้เมท็อด newInstance โปรแกรมข้างล่าง ได้แสดงตัวอย่าง การรับตัวแปรจากภายนอกโปรแกรม (ซึ่งควรจะมีค่าเป็นชื่อของคลาสๆหนึ่ง) สร้างคลาสจากค่านั้นแล้วสร้างอินสแตนใหม่จากคลาสนั้น

package com.russolsen.reflect;

public class NewInstanceExample{
   public static void main(String[] args) throws ClassNotFoundException,
      		InstantiationException, IllegalAccessException {

      Class klass = Class.forName(args[0]);
      Object theNewObject = klass.newInstance();
      System.out.println("Just made: " + theNewObject);
   }
}

ประมวลผลโค้ดข้างบนพร้อมกับส่งค่า “com.russolsen.reflect.Employee” เข้าไปในโปรแกรม และคุณก็จะได้อ็อบเจกต์ใหม่เอี่ยมของ Employee ออกมา

Just made: Employee: John Smith 50000

ส่งประมวลผลอีกครั้ง พร้อมกับใส่ค่า “java.util.Date” แล้วคุณจะได้

Just made: Tue Feb 27 20:25:20 EST 2007

ลองนึกถึงความยืดหยุ่นของโปรแกรมที่คุณได้ จากเพียงแค่โค้ดไม่กี่บรรทัด โปรแกรมข้างบนนั้นแทบไม่มีข้อมูลอะไรเลยเกี่ยวกับ Employee หรือ Date แต่ก็ยังสามารถสร้างอินสแตนจากทั้งสองคลาสได้ นี่เป็นวิธีใช้จาวาอีกแบบหนึ่ง

มากกว่าคอนสตรัคเตอร์ที่ไม่มี argument
การเรียกเมท็อด Class.newInstance นั้นก็เหมือนกับการเรียกใช้ new แบบไม่ใส่ argument แต่จะเกิดอะไรขึ้นละ ถ้าคุณเรียก newInstance บนคลาสที่ไม่มีคอนสตรัคเตอร์ที่ไม่มี argument คำตอบคือคุณจะเจอกับ InstantiationException นะสิ
ข่าวดีก็คือคุณสามารถสร้างอินสแตนของคลาสที่มี constructor แบบรับ argument ได้ เพียงแค่ต้องทำงานเพิ่มอีกนิดหน่อย สิ่งที่ต้องทำคือ หาคอนสตรัคเตอร์ที่คุณต้องการของคลาสนั้น และเรียกใช้มันพร้อมกับ ส่งค่า argument ที่ถูกต้องเข้าไป วิธีสำหรับค้นหาคอนสตรัคเตอร์ในฝันของคุณก็คือ การเรียกเมท็อด getConstructor พร้อมกับข้อมูลอธิบายลักษณะคอนสตรัคเตอร์ ที่คุณกำลังค้นหา สิ่งที่คุณจะได้กลับมาคืออ็อบเจกต์ของคลาส Constructor ซึ่งคุณสามารถนำไปใช้สร้างอินสแตนใหม่ได้
มาดูกันว่าทั้งหมดนี้ทำงานอย่างไร

      Class klass = Class.forName("com.russolsen.reflect.Employee");

      Class[] paramTypes = {
            String.class,
            String.class,
            Integer.TYPE };

      Constructor cons = klass.getConstructor(paramTypes);

      System.out.println( "Found the constructor: " + cons);

      Object[] args = {
            "Fred",
            "Fintstone",
            new Integer(90000) };

      Object theObject = cons.newInstance(args);
      System.out.println( "New object: " + theObject);

ความแตกต่างอย่างเดียว ระหว่างคอนสตรัคเตอร์แต่ละตัว ก็คือพารามิเตอร์ที่มันรับ ดังนั้นวิธีที่คุณจะบอก getConstructor ว่าคุณกำลังมองหาคอนสตรัคเตอร์ตัวไหนอยู่ ก็คือการส่งอาเรย์ของคลาสเข้าไป โดยแต่ละคลาสในอาเรย์ จะแทนแต่ละพารามิเตอร์ในคอนสตรัคเตอร์ ตัวอย่างข้างบนนั้น ทำการค้นหาคอนสตรัคเตอร์ ที่รับค่าสตริง 2 ตัวกับ int หนึ่งตัว เมื่อคุณได้คอนสตรัคเตอร์แล้ว การสร้างอ็อบเจกต์ใหม่นั้นก็แสนง่าย เพียงแค่เรียกเมท็อด newInstance โดยส่งอาเรย์อีกหนึ่งอันเข้าไป คราวนี้อาเรย์นั้นจะบรรจุค่าของ argument

มีข้อควรระวังอย่างหนึ่ง ในการกำหนดชนิดของพารามิเตอร์ สำหรับคอนสตรัคเตอร์ที่คุณกำลังค้นหาอยู่ คุณควรจะระมัดระวัง ในการแยกความแตกต่างระหว่าง argument ที่เป็น primitive กับอ็อบเจคที่เป็น wrapper ของมัน ต้องดูให้แน่ว่าคอนสตรัคเตอร์นั้นรับ argument ที่เป็น int หรือเป็นอ็อบเจกต์ของคลาส java.lang.Integer ถ้าคุณกำลังมองหาคอนสตรัคเตอร์ที่รับ wrapper ของชนิดข้อมูล primitive เช่น java.lang.Integer ก็ให้ใช้คลาสของ wrapper นั้นเลยเช่น Integer.class แต่ถ้าคุณต้องการคอนสตรัคเตอร์ที่รับค่า primitive int คุณจะต้องใช้ Integer.TYPE ซึ่งเป็นสิ่งที่ใช้แทนคลาสของ primitive int

ค้นลึกลงไปในคลาส
ดังที่คุณได้เห็นจากตัวอย่างแรก อ็อบเจกต์ของ Class สามารถให้ข้อมูลพื้นฐานทุกอย่าง เกี่ยวกับคลาสแก่คุณได้ ข้อมูลเช่นชื่อ หรือคลาสที่เป็นคลาสแม่ แต่คุณสามารถทำได้มากกว่า การเรียกดูข้อมูลในระดับพื้นฐานเช่นชื่อหรืออันดับ หรือตัวเลข serial เหล่านี้ ตัวอย่างเช่น คุณสามารถที่จะค้นหาเมท็อดที่เป็น public ทั้งหมดในคลาสโดยใช้เมท็อด getMethods

Class klass = Class.forName("com.russolsen.reflect.Employee");

Method[] methods = klass.getMethods();

for(Method m : methods ){
         System.out.println( "Found a method: " + m );
}

getMethods จะคืนกลับอาเรย์ของอ็อบเจกต์ของคลาส Method แต่ละอันคือหนึ่งเมท็อดที่เป็น public ที่สามารถเรียกใช้ได้บนอินสแตนของคลาสนั้น

Found a method: public java.lang.String com.russolsen.reflect.Employee.toString()
Found a method: public int com.russolsen.reflect.Employee.getSalary()
Found a method: public void com.russolsen.reflect.Employee.setSalary(int)
Found a method: public native int java.lang.Object.hashCode()
Found a method: public final native java.lang.Class java.lang.Object.getClass()
Found a method: public final native void java.lang.Object.wait(long) throws java.lang.InterruptedException
Found a method: public final void java.lang.Object.wait(long,int) throws java.lang.InterruptedException
Found a method: public final void java.lang.Object.wait() throws java.lang.InterruptedException
Found a method: public boolean java.lang.Object.equals(java.lang.Object)
Found a method: public java.lang.String java.lang.Object.toString()
Found a method: public final native void java.lang.Object.notify()
Found a method: public final native void java.lang.Object.notifyAll()

เพราะว่าเมท็อด getMethods นั้นมองคลาสในมุมมองของผู้ใช้งานคลาสนั้น ดังนั้นอาเรย์จะบรรจุเมท็อดที่เป็น public ทั้งหมดที่ถูกประกาศไว้ในคลาสของมันเอง รวมไปถึงคลาสแม่และคลาสเหนือคลาสแม่ขึ้นไปเรื่อยๆ จนถึงคลาส Object

ถ้าคุณสนใจเมท็อดอันใดอันหนึ่งโดยเฉพาะ คุณสามารถใช้ getMethod (โปรดสังเกตุว่าชื่อเมท็อดอยู่ในรูปเอกพจน์) ซึ่งทำงานคล้ายกับ getConstructor เว้นแต่ว่าคุณจะต้องใส่ชื่อเมท็อดพร้อมกับชนิดของพารามิเตอร์ โค้ดข้างล่างนี้ทำการค้นหาเมท็อดชื่อ setSalary ซึ่งรับพารามิเตอร์เป็น int หนึ่งตัว

Class klass = Class.forName("com.russolsen.reflect.Employee");
Class[] paramTypes = {Integer.TYPE };
Method setSalaryMethod = klass.getMethod("setSalary", paramTypes);

System.out.println( "Found method: " + setSalaryMethod);

การเรียกใช้เมท็อดผ่านทางรีเฟลคชันนั้น คล้ายกันมากกับการเรียกคอนสตรัคเตอร์ คุณต้องการเพียงแค่อ็อบเจกต์ของคลาส Method ที่เราได้พูดไปแล้วก่อนหน้านี้ รวมไปถึงอาเรย์ของ argument ที่จะส่งเข้าไปในเมท็อด และตัวอินแสตนจริงๆ ที่บรรจุเมท็อดที่คุณกำลังจะเรียก โค้ดข้างล่างนี้เรียกใช้เมท็อด setSalary บนอ็อบเจกต์ Employee เพื่อทำการเพิ่มเงินเดือน

     Class klass = Class.forName("com.russolsen.reflect.Employee");

      Class[] paramTypes = {Integer.TYPE };
      Method setSalaryMethod = klass.getMethod("setSalary", paramTypes);

      Object theObject = klass.newInstance();
      Object[] parameters = { new Integer(90000) };

      setSalaryMethod.invoke(theObject, parameters);

ทำไมต้องมาเสียเวลากับสิ่งเหล่านี้ เพื่อแลกกับการพิมพ์แค่ theObject.setSalary(90000) ละ อืม ลองดูโค้ดข้างบนอีกสักครั้ง นอกจากชื่อคลาสในบรรทัดแรกแล้ว โปรแกรมข้างบนนั้นมีความเป็น generic ในทั้งโปรแกรม คุณสามารถใช้มันเรียกเมท็อด setSalary ของอินสแตนใดๆบนคลาสใดก็ได้ ด้วยการปรับแต่งเล็กน้อย คุณก็จะสามารถใช้โค้ดข้างบนนั้น เรียกเมท็อดใดๆบนคลาสใดๆก็ได้

เล่นกับฟิลด์ (field)
คุณไม่ได้ถูกจำกัดให้ใช้รีเฟลคชันจัดการได้เฉพาะเมท็อด คุณยังสามารถทำอะไรก็ได้กับฟิลด์อีกด้วย เราได้เห็นการใช้งาน getMethods ไปแล้ว การใช้งาน getFields นั้นก็คล้ายๆกันคือจะส่งกลับอาเรย์ของ Field แต่ละอ็อบเจกต์ในอาเรย์นั้น ก็คือแต่ละอินสแตนฟิลด์ (instance field) ที่อยู่ในคลาสนั้น รวมไปถึงอินสแตนฟิลด์ที่ถูกประกาศในคลาสแม่ของมัน

Class klass = Class.forName("com.russolsen.reflect.Employee");

System.out.println( "Class name: " + klass.getName());
Field[] fields = klass.getFields();

for(Field f : fields ){
    System.out.println( "Found field: " + f);
}

เนื่องจาก Employee มีฟิลด์แค่สองตัว ดังนั้นคุณจะได้อาเรย์ที่มีสมาชิกสองตัวกลับมา

Class name: com.russolsen.reflect.Employee
Found field: public java.lang.String com.russolsen.reflect.Employee._firstName
Found field: public java.lang.String com.russolsen.reflect.Employee._lastName

คุณสามารถที่เจาะจงดึงเอาฟิลด์อันใดอันหนึ่งมาด้วยชื่อโดยการใช้เมท็อด getField

Field field = klass.getField(”_firstName”);
System.out.println(”Found field: ” + field);

เมื่อคุณได้อ็อบเจกต์ของ Field แล้ว การดึงค่าของฟิลด์นั้นก็ง่ายพอๆกับการเรียกเมท็อด get และการกำหนดค่าให้กับฟิลด์นั้นก็เพียงแค่เรียกเมท็อด set

      Object theObject = new Employee("Tom", "Smith", 25);

      Class klass = Class.forName("com.russolsen.reflect.Employee");

      Field field = klass.getField("_firstName");

      Object oldValue = field.get(theObject);
      System.out.println( "Old first name is: " + oldValue);

      field.set( theObject, "Harry");
      Object newValue = field.get(theObject);
      System.out.println( "New first name is: " + newValue);

ส่งประมวลผลโค้ดข้างต้นแล้วมองดูฟิลด์ _firstName เปลี่ยนค่าไปให้เห็นกับตาคุณ

Old first name is: Tom
New first name is: Harry

แหกกฎ
การศึกษาเกี่ยวกับรีเฟลคชันนั้น จะครบถ้วนไปไม่ได้ หากไม่ได้พูดถึงการฝ่าฝืนกฎศักสิทธิ์อันหนึ่งของจาวาทุกคนคงรู้ดีว่าไพรเวทเมท็อด (private method) นั้นไม่สามารถเข้าถึงได้จากภายนอกคลาส ที่ประกาศมันไว้ วิธีการใช้งานทั่วไปนั้นไม่สามารถทำได้ แต่กับรีเฟลคชันแล้ว คุณแทบจะทำอะไรได้ทุกอย่าง

สิ่งแรกที่คุณต้องการในการเรียกใช้ไพรเวทเมท็อดก็คืออ็อบเจกต์ Method ของเมท็อดที่คุณต้องการเรียก คุณไม่สามารถดึงมันออกมาได้จากการเรียก getMethod เพราะ getMethod จะส่งกลับเฉพาะเมท็อดที่เป็น public เท่านั้น วิธีที่คุณจะได้มาซึ่งไพรเวทเมท็อด(หรือ protected) ก็คือการใช้ getDeclaredMethod ในขณะที่ getMethod มองคลาสในมุมมองของผู้ใช้งาน และส่งกลับเฉพาะเมท็อดที่เป็น public แต่ getDeclaredMethod จะส่งกลับทุกเมท็อดที่ถูกประกาศไว้ในคลาสนั้น ตัวอย่างข้างล่างเราใช้ getDeclaredMethod ในการดึงไพรเวทเมท็อด removeRange ของคลาส java.util.ArrayList

ArrayList list = new ArrayList();
list.add("Larry");
list.add("Moe");
list.add("Curley");

System.out.println("The list is: " + list);

Class klass = list.getClass();

Class[] paramTypes = { Integer.TYPE, Integer.TYPE };
Method m = klass.getDeclaredMethod("removeRange", paramTypes);

Object[] arguments = { new Integer(0), new Integer(2) };
m.setAccessible(true);
m.invoke(list, arguments);
System.out.println("The new list is: " + list);

เมื่อคุณได้ไพรเวทเมท็อดมาแล้ว การจะเรียกใช้มันได้ก็เพียงแค่ปิดการป้องกันสุดท้ายโดยการเรียก setAccessable

The list is: [Larry, Moe, Curley]
The new list is: [Curley]

เมท็อด removeRange จะทำการดึงเอาไอเทมในช่วงหนึ่งออกจากลิสต์ นี่อาจจะออกแนวไสยศาสตร์วูดูเลยทีเดียว คุณพึ่งจะเข้าไปเรียกไพรเวทเมท็อดของ java.util class แต่ถามว่าคุณอยากจะสร้างนิสัยในการเขียนโค้ดที่คลุมเครือ อย่างการเรียกใช้งานไพรเวทเมท็อดแบบนี้ไหมละ ก็คงไม่หรอก แต่อย่างน้อยมันก็เป็นสิ่งที่รู้กัน ว่ามีประโยชน์ ในบางสถาณการณ์ที่จำเป็นจริงๆ

สรุป
รีเฟลคชันอนุญาตให้โปรแกรมของคุณ ทำในสิ่งที่เหมือนจะไม่เป็นไปตากกฎของจาวา คุณสามารถเขียนโค้ด เพื่อหาข้อมูลทุกอย่างของคลาสหนึ่งๆ ที่โค้ดของคุณเพิ่งเจอเป็นครั้งแรก และเรียกใช้งานข้อมูลที่เพิ่งจะค้นพบในคลาสใหม่นั้นได้ทันที เช่นมันสามารถสร้างอินสแตนไหม่ หรือเรียกใช้เมท็อด และดึงค่าหรือกำหนดค่าให้กับฟิลด์ คุณสามารถทำได้แม้กระทั่ง เล่นเล่นกับข้อมูลที่เป็นไพรเวทข้างในคลาส ความเข้าใจที่ดีในรีเฟลคชันเป็นสิ่งที่สำคัญในการทำความเข้าใจ เครื่องมือที่ซับซ้อนบางอย่าง ในโลกของจาวา และมันก็เป็นสิ่งที่คุณต้องการ ในการเขียนโปรแกรมที่ทำได้มากกว่าโปรแกรมจาวาทั่วไป

Next »