Q: public, private, protect ที่เราใช้ใน Class และ Method ต่างๆ มันเหมือน หรือ แตกต่างกันอย่างไรA: จะแยกตอบที่ละอันตามนี้ เดี๋ยวของเพิ่ม default (เกิดจากการที่เราไมได้กำหนด Access Modifier ให้กับ Class/Method) ลงไปด้วยและกัน- private >> ใช้ได้เฉพาะ class มันเองเท่านั้น- protect >> ใช้ได้เฉพาะ Class แม่(Super Class)กับ Class ลูก(Sub Class) ใช้ได้เท่านั้น- default >> ใช้ได้เฉพาะ Package เดียวกันเท่านั้น- public >> ใช้ได้หมด
ในชีวิตการทำงานจริง การพัฒนาออกแบบ Software ระบบหนึ่งขึ้นมา คงไม่ได้มีเพียง File เดียว หรือ Method Main อย่างเดียวแน่ๆ เหมือนตอนที่เรียนอยู่ในมหาวิทยาลัย โดยการทำงานจริงนั้น เราต้องแบบระบบงาน Software ที่ทำอยู่ออกมาเป็น Module หรือ Component ต่างๆ และท้ายที่สุดได้ Class Diagram แต่เมื่อออกแบบเสร็จแล้ว เราจะมั่นใจได้อย่างไรว่า Code ที่เราออกแบบนั้น ไม่มีการทำงานที่ซับซ้อน หรือมีโครงสร้างที่ซับซ้อนมากเกินไป จนทำให้ในอนาคตเมื่อมีการแก้ไข Code นั้นแล้วอาจจะทำให้กระทบไปทั้งระบบ แล้วเราจะมีวิธีจัดการอย่างไงให้สามารถลดความซับซ้อนของระบบได้ ผมขอแนะนำแนวคิด 2C ได้แก่ Cohesion และ Coupling (ลองดูรูป ด้านล่างครับ อยากได้แบบไหนดี) Cohesion คือ อะไร ? Cohesion คือ การบอกถึงความสอดคล้องกันของการทำงานในหน่วยใดๆ เช่น ถ้าเรามองในมุมของ Coding ในระดับ Class ความสอดคล้องกันของ Class นั้น หมายถึง Method การทำงานต่างๆที่ควรจะเป็นไปในทางเดียวกัน เช่น แล้วทำไมเราต้องทำให้เกิดความสอดคล้อง (Cohesion) หละ ? เพราะ เราต้องการจัดกลุ่มของการทำงานให้เป็นหมวดเดียวกัน ให้อยู่ใน Class เพื่อให้ง่ายต่อการ Maintain และการเพิ่มเติมการทำงานในอนาคต ลองมองง่ายๆ ถ้า Code Export Excel (.CSV) มันมีการทำงานกระจายไปหมดทุก Module ถ้าเปลี่ยน Requirement ที = งานเข้า ชนิดของ Cohesion จากแย่ที่สุด ไป ดีที่สุด ระบบที่ดีความออกแบบให้มี Cohesion สูง (งานที่เหมือนกัน ควรอยู่ในกลุ่มเดียวกัน) Coupling คือ อะไร ? Coupling…
จากบทความที่แล้ว แสดงวิธีการเขียน Code กับโจทย์ปัญหา FizzBuzz โดยไม่ใช่ IF กันแล้วนะครับ แต่ผมยังทิ้งท้ายไว้อีกปัญหานึง คือ ถ้ามีเงื่อนไขเพิ่มขึ้นมาหละ โดยให้แสดง WOOF ้เพิ่ม ถ้าตัวเลขนั้นหาร 7 ได้ลงตัว (อ้างอิงจาก WIKI FIZZ BUZZ WOOF ) เราจะมีวิธีการแก้ปัญหาอย่างไรนะครับ โดยผมขอทวนวิธีการที่ใช้แก้ปัญหาใน Blog ตอนที่แล้วก่อนนะครับ
จากบทความที่แล้ว FizzBuzz Problem ไปนะครับ ต่อไปผมลอง Refactor Code อีกรอบ โดยมีเงื่อนไขว่าห้ามใช้ IF ในส่วนของ Logic Fizz และ Buzz ทำไมถึงต้องห้ามใช้ IF เพราะ การใช้ IF ส่งผลให้เกิดความมักง่ายของ Developer ทำให้เกิดปัญหาในการแก้ไข หรือพัฒนา Module เพิ่มเติม ต้องไปแก้ Code จนเกินความจำเป็น และทำให้เกิด Defect(ฺBug) เพิ่มขึ้นด้วย ซึ่งมีแนวคิดทางวิชาการมาสนันสนุนแนวคิดนี้อย่าง The Open Close Principle (OCP) และ High Coupling & Low Cohesion (สามารถอ่านเพิ่มเติมได้ใน Blog ผมครับ ^__^) หลังจากรู้ที่มาคร่าวๆแล้ว เรามาลองทำ FizzBuzz โดยไม่ใช้ IF กันนะครับ
FizzBuzz เป็นโจทย์ฝึกสมองเด็ก ที่ใช้ช่วยในการเรียนรู้เรื่องการหาร ซึ่งสามารถไปอ่านกฏเพิ่มเติมได้จากใน WIKI: FIZZBUZZ ครับ แต่บทความนี้ผมขอนำกฏของ FizzBuzz มาประยุกต์กับการเขียนโปรแกรม
วันนี้ได้ไปช่วยพี่ที่ทำงานมา ซึ่งตัวรายงานมี Layout ดังนี้ (ขอเบลอรูปนิดนึง 55) โดยโจทย์มีอยู่ว่า ชื่อของรายงาน @ReportName(หมายเลข 1 ในรูป) ขึ้นอยู่ผลรวม(SUM) ของ field #SumNetAmountGrandTotal(หมายเลข 2 ในรูป) โดยมีเงื่อนไข ดังนี้ ซึ่งในตัว Crystal Report เราสามารถเขียน formula เพื่อกำหนดการแสดงผลได้ ดังนี้ แต่เมื่อลองรัน Application และแสดงรายงานดูปรากฏว่า เงื่อนไขที่ได้กำหนดไว้ ไม่ทำงาน แล้วสาเหตุ คือ อะไร ? ลองกลับมาดูการทำงานของ Report กัน ตัว Crystal Report มีการ Render เหมือน Printer หรือถ้าในภาษาขอ Programming คือ Interpreter นี้แหละ เมื่อเรารู้ Consept การทำงานของการสร้าง Report แล้ว วกกลับมาดูที่ Layout ของ Report พบว่าส่วนของ @ReportName(หมายเลข 1 ในรูป) ถูกทำงานก่อนที่ระบบหาค่า #SumNetAmountGrandTotal(หมายเลข 2 ในรูป) ที่ถูกรวม (SUM) ก่อนอีก ? รู้สาเหตุแล้ว แก้ปัญหาอย่างไร ? เมื่อเข้าใจการทำงานของ Report ที่ทำงานจากบนลงล่างแบบ printer ดังนั้น วิธีแก้ คือ ต้องหาผลรวม(SUM) field #SumNetAmountGrandTotal ก่อนเข้าเงื่อนไข โดยแก้ไข formula ดังนี้ หมายเหตุ: จริงๆวิธีแก้ไขกับปัญหานี้มีได้หลายแบบ แต่ที่ผู้เขียนได้ยกตัวอย่างมา เพื่อให้ผู้อ่านได้เข้าใจ Consept การทำงานของ Report Writer แบบต่างๆ ซึ่งไม่จำเป็นต้องเป็น Crystal Report อย่างเดียวครับ…
หลังจากได้ Model มาแล้วสิ่งที่เราต้องทำต่อไป คือ การนำโมเดลที่ได้นั้นมาตรวจสอบความถูกต้อง และนำไปผลที่ได้ไปปรับแต่ง Model ของเราจนได้ผลลัพธ์ออกมาเป็นที่น่าพอใจแล้วนำไปทดสอบกับข้อมูลจริงๆ โดยการตรวจสอบ Model ที่ได้มานั้นมีขั้นตอน ดังนี้ เปิดโปรแกรม WEKA และทำการ load model ที่ได้ save ไว้ขึ้นมาจาก Blog ตอนที่แล้ว มาตั้ง Test Options (ไม่แน่ใจมาจาก sense เพราะมันไม่มี doc ให้อ่าน) Supplied training set: เปิดไฟล์ data ที่เราจะมา Test กับ Model <<เลือกอันนี้>> จากนั้นไปเลือกไฟล์ Customer_for_std_test ดังรูป คลิกขวาที่ Model เลือก Re-evaluate model on current test set สังเกตุผลลัพธ์ที่ได้ ดังรูป ซึ่งจะมีจำนวนที่ทำนายถูก Correctly Classified Instances 119 รายการ ซึ่งคิดเป็น 59.5% ซึ่งเราจะต้องปรับให้มันถูกเยอะๆ จนกว่าจะพอใจ เราสามารถที่จะดูผลลัพธ์ที่ระบบมันทายได้เทียบกับคำตอบ โดยคลิกขวาที่ Model เลือก Visualize Classify error จากนั้นกด save จากนั้นมาเปิดดูด้วย arffViewer ตามรูป หรือจะดูจาก Confusion Matrix ก็ได้ ถ้าเราไม่พอใจก็กลับไปทำใน หัวข้อ “สร้าง Model” และมาปรับค่าในส่วนของข้อที่ 6 และ 9 แต่ถ้าเรา OK กับตัว Model เราสามารถนำ Model ที่ได้ไปใช้งานเพื่อทำนายกับข้อมูลจริงๆได้เลยครับ 😀 การทำ Neural Network คือ…
บางครั้งเวลาเราพัฒนา Application ขึ้นมา เราอยากเก็บค่า Config บางอย่าง เช่น username ครั้งสุดท้ายที่ใช้ Log , ชื่อ Database ที่ใช้งานประจำ หรือเป็นขนาดความกว้าง ยาวของหน้าจอครั้งล่าสุด โดยอาจเราจะเก็บไว้ Text File, Registry หรือเก็บใน Project Setting ที่ทาง .Net Framework ได้เตรียมไว้ให้ โดยวันนี้ผมขอแนะนำการเก็บค่า Config ต่างๆลงใน Project Setting กันครับ คลิกขวาที่ Project File เลือก properties >> เลือกที่ส่วน Setting จากนั้นกำหนดข้อมูล Name : ชื่อ Setting Type : Data type ของ Setting โดย User สามารถกำหนดได้ว่าจะเก็บข้อมูลเป็น String, int หรือ boolean เป็นต้น Scope : ขอบเขตของ Setting นี้ว่าเป็นแบบ Application(ทีผลกับทุก user บนเครื่อง) หรือ เป็นแบบ User(แยก Config ตาม user ที่ใช้งาน) Roaming: กำหนดรูปแบบ Config ถ้า set เป็น True คือ สามารถเก็บ Config ไปใช้งานบนคอมพิวเตอร์เครื่องใดๆก็ได้บนเครือข่าย ที่มีการ Set Active Directory และกำหนด Roaming User Profiles ไว้ ยกตัวอย่างเช่น ถ้า Application ของเราทำงานบนเครื่อง Computer A โดย User…
