Kata Open/Closed Principle ในงาน Agile Thailand 2014

1. The Open/Closed Principle
Agile Thailand 2014

2. Pairs

3. เริ่มต้นกับ FizzBuzz
1, 2, Fizz, 4, Buzz, Fizz, 7,
8, Fizz, Buzz, 11, Fizz, 13,
14, FizzBuzz, 16, 17, Fizz
ถ้าตัวเลขหาร 3 ลงตัว แสดงคําว่า Fizz
ถ้าตัวเลขหาร 5 ลงตัว แสดงคําว่า Buzz
ถ้าตัวเลขหาร 3 และ 5 ลงตัว แสดงคําว่า FizzBuzz
๤่วนอื่นๆ แสดงค่าเลขนั้นๆ

4. มันง่ายเกินไปนะ
public String say(Integer number) {
if( isFizz( number ) && isBuzz( number ) ) {
return “FizzBuzz”;
}
if( isFizz( number ) ) {
return “Fizz”;
}
if( isBuzz( number ) ) {
return “Buzz”;
}
return number.toString();
}
private boolean isFizz(Integer number) {
return number % 3 == 0;
}

5. ลองเพิ่ม Requirement หน่อย
ถ้าตัวเลขหาร7 ลงตัว แสดงคําว่า Bang

6. มันก็ง่ายนะ
public String say(Integer number) {
if( isBang( number ) ) {
return “Bang”;
}
if( isFizz( number ) && isBuzz( number ) ) {
return “FizzBuzz”;
}
if( isFizz( number ) ) {
return “Fizz”;
}
if( isBuzz( number ) ) {
return “Buzz”;
}
return number.toString();
}

7. แต่ยังก่อน … ต้องการแบบนี้
ถ้าตัวเลขหาร 3 และ 7 ลงตัว แสดงคําว่า FizzBang
ถ้าตัวเลขหาร 5 และ 7 ลงตัว แสดงคําว่า BuzzBang
ถ้าตัวเลขหาร 3, 5 และ 7 ลงตัว แสดงคําว่า FizzBuzzBang

8. วิธีการที่ไม่ควรทํา !!!
public String say(Integer number) {
if( isFizz( number ) && isBuzz( number ) && isBang( number ) ) {
return “FizzBuzzBang”
}
if( isBuzz( number ) && isBang( number ) ) {
return “BuzzBang”;
}
if( isFizz( number ) && isBang( number ) ) {
return “FizzBang”;
}
…
…
}
นี่คือวิธีการที่ดีแล้วหรือ ?
ทุกๆ ครั้งที่มีการเพิ่ม หรือ แก้ไขความต้องการจากลูกค้า
คุณทำแบบนี้หรือ ?

9. มีคนบอกว่า
การเพิ่ม IF เข้าไป มันคือการสร้างปีศาจขึ้นมา
http://www.antiifcampaign.com/

10. The Open/Closed Principle
๤่วนการทํางานต่างๆ ของ Software
เ๡่น class, module, function และ๤่วนอื่นๆ
ควรจะ
เปิด ๤ําหรับการเพิ่มหรือขยาย
แต่ ปิด ๤ําหรับการแก้ไข

11. เราสร้าง feature อย่างไร

12. แนวทางการเพิ่ม feature
• คุณสามารถทําการแก้ไขเฉพาะ ตอนการสร้าง object และสร้าง
class ใหม่ขึ้นมาเท่านั้น ?
• ถ้าสามารถทําได้ แสดงว่าระบบดีล่ะ
• ถ้าไม่ ให้ทําการ refactor จนกว่าจะทําได้

13. กฎของ OCP Kata
1. เขียน Fail test
2. เขียน code เพื่อสร้าง object ขึ้นมา ทําให้ test ผ่าน
1. เ๡่นการสร้าง Factory class ๤ําหรับสร้าง object
2. ไม่มี if-else
3. เขียน Fail test เพิ่มอีก
4. สามารถเขียน code ให้ผ่านด้วยการเปลี่ยนแปลง code ใน Factory
หรือทําการสร้าง class ใหม่หรือไม่
1. ถ้า ใ๡่ กลับไปทําข้อ 3
2. ถ้า ไม่ ให้ทําการ refactor code จนกระทั่งทําข้อ 4 ได้

14. เริ่ม coding กันดีกว่า

15. Test case ที่ 1
say(1) return 1
say(2) return 2

16. Test case ที่ 2
say(3) return “Fizz”
say(6) return “Fizz”

17. Test case ที่ 3
say(5) return “Buzz”
say(10) return “Buzz”

18. Test case ที่ 4
say(3*5) return “FizzBuzz”

19. Test case ที่ 5
say(7) return “Bang”
say(14) return “Bang”

20. Test case สุดท้าย
say(3*7) return “FizzBang”
say(5*7) return “BuzzBang”
say(3*5*7) return “FizzBuzzBang”

21. เอามาโชว์หน่อย๤ิ

22. Test case ที่ 1

25. Test case ที่ 2

30. ๤ําหรับ Test case อื่นๆ
https://github.com/up1/kata_fizzbuzz_ocp

31. ข้อคิดสะกิดใจ
1. ก่อนที่จะทําการ code ต้องคิดว่าจะสร้าง feature ให้ง่ายได้อย่างไร
2. ก่อนที่จะ refactor ต้อง คิด และ วางแผน
3. ทําการ Refactor ตอนที่ test ผ่านทั้งหมด
4. ถ้าแก้ไขแล้วงง แนะนําให้ใ๡้ Ctrl+Z ไปจนกว่า test จะผ่าน
5. เมื่อต้องการเพิ่ม feature ใหม่ ให้เพิ่มใน๤่วนขยายเท่านั้น

32. เริ่มต้นกันใหม่ …