ภายใต้ระบบ modular system นั้น การทำงานต่างๆ ภายในระบบคอมพิวเตอร์จะถูกซอยออกเป็นหลายๆ หน่วยย่อย (หรือที่เรียกว่า module) ซึ่งแต่ละหน่วยย่อยนั้นต่างมีความเป็นอิสระในตัวของตัวเอง สามารถดัดแปลงแก้ไข, ทดสอบ, และปรับปรุงได้ต่างหากก่อนที่จะนำกลับมาประกอบกันเข้าใหม่เป็นผลลัพธ์รวมได้ในภายหลัง โดยมักจะมีระบบปฏิบัติการ อย่างเช่น MS-DOS เป็นหน่วยย่อยหลักซึ่งทำตัวเหมือนเป็นแกนกลาง (microkernel) ของระบบ สำหรับให้หน่วยย่อยอื่นๆ เช่น Windows หรือ networking ประกอบเข้ามา

1. 1
Object-oriented computing ถึงคราวพยุหยาตราของเหลา objects
สุรพล ศรีบุญทรง
บทความ 1997
ภายในชวงหลายปที่ผานมานี้ เทคโนโลยีการประมวลผลแบบ Microkernel Technology นับ
ไดวาเปนรูปแบบการประมวลผลสําคัญซึ่งไดรับความนิยมยอมรับใชงานอยางกวางขวางมากที่สุดในหมูผูใชเครื่อง
คอมพิวเตอรสวนบุคคลทั่วๆ ไป ไมวาจะเปนเครื่องคอมพิวเตอรตระกูลพีซี หรือตระกูลแมคอินทอช และเปน
รูปแบบการประมวลผลซึ่งตอมาไดพัฒนาไปสูการจัดวาง
ระบบพื้นฐานแบบ modular system อันมีประสิทธิภาพ
และความยืดหยุนในการทํางานเปนอยางมาก
กระนั้น กระบวนการวิวัฒนาการของ
เทคโนโลยีการประมวลผลมิไดจบลงตรงที่ Micrkernel
modular system เทานั้น มันยังมีการพัฒนาสืบเนื่อง
ตอไปอีกเพื่อใหไดรุปแบบการประมวลที่มีประสิทธิภาพ
มากที่สุด ซึ่งรูปแบบการประมวลผลที่ดูเหมือนวากําลัง
มาแรงอยางมากในปจจุบัน และมีความเปนไปไดอยาง
มากที่จะกลายมาเปนรูปแบบการประมวลผลมาตรฐาน
สําหรับอนาคตอันใกลนี้ ก็คือ การประมวลผลแบบ
Object-oriented computing
วิวัฒนาการแหงระบบ Modular system
ภายใตระบบ modular system นั้น การทํางานตางๆ ภายในระบบคอมพิวเตอรจะถูกซอย
ออกเปนหลายๆ หนวยยอย (หรือที่เรียกวา module) ซึ่งแตละหนวยยอยนั้นตางมีความเปนอิสระในตัวของ
ตัวเอง สามารถดัดแปลงแกไข, ทดสอบ, และปรับปรุงไดตางหากกอนที่จะนํากลับมาประกอบกันเขาใหมเปน
ผลลัพธรวมไดในภายหลัง โดยมักจะมีระบบปฏิบัติการ อยางเชน MS-DOS เปนหนวยยอยหลักซึ่งทําตัวเหมือน
เปนแกนกลาง (microkernel) ของระบบ สําหรับใหหนวยยอยอื่นๆ เชน Windows หรือ networking ประกอบ
เขามา
อยางไรก็ตาม การใชระบบปฏิบัติการ DOS หรือ Macintosh เปนแกนกลางสําหรับติดตอกับ
ฮารดแวรคอมพิวเตอรใหกับหนวยยอยอื่นๆ ของระบบ Modular system ยุคตนๆ นั้น ก็ยังมิไดเปนรูปแบบการ
ประมวลผลที่ผสมผสานกลมกลืนเทาที่ควรนัก ยังคงมีความผิดพลาดอันเนื่องมาจากความไมมั่นคง (instability)
หรือความขัดแยงระหวางโปรแกรม (conflict) เกิดขึ้นใหเห็นไดบอยๆ ภายใตรูปแบบการประมวลผลดังกลาว
ซึ่งถาเปนเครื่องคอมพิวเตอรพีซีที่ใชระบบปฏิบัติการ MS-DOS เปน Microkernel ขอผิดพลาด
ที่วานั้นก็มักจะเกิดขึ้นเมื่อมีการเรียกโปรแกรมเขาไปจองพื้นที่ในหนวยความจํามากๆ โดยโปรแกรมที่วานั้น ก็
ไดแก โปรแกรมประเภท TSR (Terminate-and resident program), โปรแกรมพวก Device drivers, หรือ

2. 2
โปรแกรมพวก memory managers ฯลฯ แตถาเปนการประมวลผลแบบ Microkernel บนเครื่องคอมพิวเตอร
Macintosh ขอผิดพลาดดังกลาวก็มักจะมีสาเหตุมาจากการทํางานประเภท INITs* หรือพวก system
extensions ประเภทอื่นๆ
เพื่อแกไขปญหาขอผิดพลาดดังกลาว จึงไดมีความพยายามพัฒนาเทคนิคตางๆ เขามาใชประกอบ
ในระบบ modular system และเทคนิคการประมวลผลที่ดูเหมือนวานาจะเปนทางออกอยางดีของปญหาก็เห็น
จะไดแก การประมวลผลแบบ Object-oriented computing ซึ่งมุงเนนไปที่ตัว object ที่ถูกสรางขึ้นจาก
โปรแกรมหนวยยอยตางๆ และผลลัพธโดยรวมซึ่งประกอบขึ้นจาก object เหลานั้น มากกวาที่จะมุงเนนไปที่ตัว
โปรแกรมประยุกตเชนรูปแบบการประมวลผลเดิมๆ
ดังจะเห็นไดจากการที่เหลา
บริษัทผูผลิตระบบปฏิบัติการรายสําคัญๆ ตางพากันหัน
เหรูปแบบผลิตภัณฑของตนไปสูเทคโนโลยีการ
ประมวลผลแบบ object-oriented computing กัน
ตามๆ กัน ไมวาจะเปนบริษัท Microsoft
Corporation, Apple Computer Corporation,
IBM (International Business Machine) Corporation, Novell/USL (Unix Systems Laboratories), หรือ
Sun Microsystems Incorporated ฯลฯ
* INITs ความจริงก็จัดเปน System extensions หนึ่งเหมือนกัน โดยเฉพาะใน System 7
มักจะเรียกวา System extension รวมกันไปเลย เปนสวนการทํางานที่เกี่ยวของกับการติดตอกับผูใชอยาง
extra sounds, extra pictures, bizarre cursors, หรือ clocks ฯลฯ ซึ่งจะถูกโหลดเขาไปเก็บไวใน
หนวยความจํา RAM โดยอัตโนมัติเพื่อเตรียมพรอมสําหรับการทํางานทันทีเมื่อมีการเปดสวิทซเครื่องคอมพิวเตอร
แมคอินทอชขึ้นใชงาน (คลายๆ กับ Start up ของวินโดวสนั่นแหละ)
ตามปรกติ System extensions นับวาเปนสวนของโปรแกรมที่มีประโยชนเหลือคณา และชวย
อํานวยความสะดวกใหกับผูใชเครื่องคอมพิวเตอรแมคอินทอชเปนอยางมาก แตก็มีบางโปรแกรม System
extension เหมือนกัน ที่อาจจะกอใหเกิดปญหาใหกับการทํางานของเครื่องคอมพิวเตอรแมคอินทอชทั้งระบบ
อันเนื่องมาจากการเขาไปจับจองพื้นที่บนหนวยความจําใน RAM แลวไมยอมใหการทํางานที่สําคัญเขามาใช
หนวยความจําในตําแหนงดังกลาว โดยเฉพาะพวก System extension ของฟรีๆ ทั้งหลาย ไมวาจะเปน
freeware หรือ shareware
"Object-oriented computing" อยูใกลแคปลายจมูก
ผลิตภัณฑระบบปฏิบัติการประเภท object-oriented operating system ที่นับวาโดดเดนเปน
พิเศษก็เห็นไดแก ผลิตภัณฑ Taligent อันเปนผลิตผลที่เกิดขึ้นจากความรวมมือกัน (joint-venture) ระหวางสอง
บริษัทยักษใหญทางคอมพิวเตอร "IBM" และ "Apple" มีลักษณะเดนตรงที่ไดรับการออกแบบมาเพื่อการ

3. 3
ประมวลผลแบบ object-oriented โดยเฉพาะ ตั้งแตสวนพื้นฐานยอยที่สุดของระบบนั่นเลยทีเดียว (from-
scratch design)
แตถาจะถามวาผลิตภัณฑระบบปฏิบัติการ
แบบที่เปนทั้ง microkernel system และ object-oriented
system ชนิดใดที่นาจะมีความกาวล้ํานําสมัยมากที่สุดใน
ปจจุบัน คําตอบก็เห็นจะไดแก ผลิตภัณฑ NeXTStep จาก
บริษัท NeXT Computer Inc. เพราะถึงแมวาจะมิไดเปน
ระบบปฏิบัติการแบบ object ที่ถูกออกแบบจากสวนรากฐาน
ขึ้นมาเลยเชน Taligent แตมันก็เปนระบบปฏิบัติการแบบ
object รุนแรกที่มีใหผูใชคอมพิวเตอรไดใช ตั้งแตป ค.ศ. 1989 นั่นเลยทีเดียว (ในชวงแรกๆ นั้นผลิตภัณฑ
NeXTStep ยังคงจํากัดอยูเฉพาะกลุมเครื่องเวิรกสเตชั่นซึ่งทํางานภายใตระบบปฏิบัติการ Unix เทานั้น)
กระนั้น สําหรับผูใชคอมพิวเตอรที่คุนเคยกับระบบปฏิบัติการ Windows อยูเปนอยางดีแลว
รูปแบบการประมวลผลแบบ Object-oriented computing ที่พวกเขานาจะรูจักดีที่สุดนาจะเปนผลิตภัณฑ OLE
2.0 ซึ่งไดรับความนิยมสูงจนทางบริษัท Microsoft ตองรีบเข็นระบบปฏิบัติการ Cairo ออกมาอยางตอเนื่อง
อยางไรก็ตาม ระบบ OLE 2.0 หรือ Cairo ก็ยังจํากัดอยูเฉพาะกลุมผูใชวินโดวสเทานั้น ไมไดเปดกวางสําหรับผูใช
ระบบคอมพิวเตอรทั่วๆ ไปเชนผลิตภัณฑ OpenDoc
และสําหรับกลุมผูใชคอมพิวเตอรภายใตระบบปฏิบัติการตระกูล Unix ซึ่งเปนที่ยอมรับกันวามี
ความโดดเดนเปนพิเศษในเรื่องของการสื่อสารขอมูลภายในเครือขายเน็ตเวิรกแลว ปจจุบันก็มีโครงสรางทางส
ถาปตยสําหรับการประมวลผลแบบ Object-oriented computing ชื่อ "COBRA" ใหเลือกใชภายในกลุมไดอีก
เชนกัน จนนาจะเปนที่สังเกตไดวาปจจจุบันนี้ผูใชคอมพิวเตอรอยางเราๆ ทานๆ มีโอกาสที่จะตองเขาไป
เกี่ยวของสัมพันธกับการประมวลผลแบบ object นี้อยูแทบตลอดเวลา ไมวาจะรูตัวหรือไมก็ตาม เชน ผูใช
คอมพิวเตอรบางรายอาจจะเคยชินอยูกับการลากเอารูปตารางของ
Excel มาวางบนเอกสารของ Microsoft Word โดยที่ตัวเองไมทราบ
เสียดวยซ้ําวา ตัวเองกําลังใชการประมวลผลแบบ Object-oriented
computing อยู
คุณานูปการแหง Object-oriented OS
ระบบปฏิบัติการแบบ Fully object-oriented
operating systems ไดนําคุณประโยชนมาสูวงการคอมพิวเตอรคณา
นับประการ ประโยชนที่วานี้มิไดจํากัดเฉพาะเพียงเหลาโปรแกรมเมอร
ผูออกแบบและพัฒนาโปรแกรมระยุกตเทานั้น แตยังสงผลตอเนื่องไป
ยังเหลาผูใชโปรแกรมประยุกตทั่วๆ ไปอีกดวย
สําหรับเหลาโปรแกรมเมอรซึ่งติดตอกับคอมพิวเตอรใน
ระดับระบบปฏิบัติการ (system level) นั้นการประมวลผลแบบ

4. 4
object จะทําใหพวกเขาสามารถเจาะลึกลงไปในระบบปฏิบัติการเพื่อดัดแปลงแกไขรูปแบบการติดตอใหเหมาะสม
(customize) กับที่โปรแกรมประยุกตซึ่งตนพัฒนาขึ้นมาตองการโดยไมทําใหเกิดการสูญเสียความมั่นคงเชื่อถือได
(integrity) ของระบบคอมพิวเตอรโดยรวมไป
สวนในกลุมผูใชคอมพิวเตอรระดับทั่วๆ ไปซึ่งติดตอกับโปรแกรมประยุกต (application level)
การประมวลผลแบบ object จะทําใหผูใชคอมพิวเตอรผสมผสานการทํางานของโปรแกรมประยุกตชนิดตางๆ ไว
ภายในเอกสารไดอยางสะดวกสบาย สามารถนําสวนยอยๆ ของแตละโปรแกรมประยุกตในรูป object มา
ประกอบเขาดวยกันเปนผลิตภัณฑไดทันที ไมตองมานั่งเขียนโปรแกรมตั้งแตตนในทุกๆ สวน และหากตองการ
อัพเกรดผลิตภัณฑ ก็สามารถเลือกอัพเกรดไดเฉพาะเพียงบางสวนได
นอกจากนั้น การประมวลผลแบบ object ยังเปนแนวทางนําไปสูการพัฒนาระบบการ
ประมวลผลแบบกระจาย (Distributed computing) ที่มีประสิทธิภาพอีกดวย เนื่องจากแตละหนวย object
ประกอบไปดวยรหัสคําสั่ง และขอมูลอยูเปนกลุมๆ สามารถจัดสงไปมาระหวางเครือขายเน็ตเวิรกไดอยางสะดวก
(highly interchangeable) เวลาจะนําเอาการทํางานใดบนหนาจอไปทําบนเครื่องคอมพิวเตอรอีกเครื่องซึ่งอยู
หางออกไปในเน็ตเวิรก ก็ใชวิธีสง object ดังกลาวไปทั้ง object เลย
อยางไรก็ตาม สิ่งหนึ่งที่การประมวลผลแบบกระจายซึ่งสงผานขอมูลไปในรูป object นํามาสู
ผูใชคอมพิวเตอร ก็คือความไมแนนอนของตําแหนงสถานที่อยูของขอมูลซึ่งผูใชติดตออยู (จากเดิมที่ผูใชเคยทราบ
แนนอนวาขอมูลของตนถูกจัดเก็บบนสวนใดสวนหนึ่งของหนวยความจําสํารอง) เพราะขอมูลที่จัดเก็บไวภายใน
หนวย object นั้นสามารถที่จะเคลื่อนยายไปไหนตอไหนไดไมจํากัด
(roam) ขึ้นอยูกับวาในชวงเวลาขณะนั้นๆ สวนใดของระบบ
คอมพิวเตอรตองการใชขอมูลภายใน object ดังกลาวมากที่สุด
และดวยความไมแนนอนของตําแหนงที่อยูของขอมูลใน
รูป object นี่เอง ก็ทําใหเกิดความวิตกกังวลขึ้นในหมูผูใชคอมพิวเตอรที่
เกี่ยวของกับขอมูลอันเปนความลับคอนขางมาก เพราะมีความเปนไปได
ที่อาจจะมีผูไมประสงคดีตอเครื่องคอมพิวเตอรของตนเขากับระบบแลว
แอบลักเอา object ขอมูลอันเปนความลับไปเปดดู ดังนั้น ระบบปฏิบัติการ object-oriented Operating
System รุนหลังๆ จึงจําเปนตองเสริมการทํางานอยาง cryptographic protocol ซึ่งติดตอกันดวยรหัสลับ เพื่อ
จํากัดใหขอมูลใน object สามารถถูกเรียกดูไดเฉพาะผูใชที่ไดรับอนุญาตเทานั้น
แนนอน รูปแบบการทํางานตางๆ ที่กลาวมาจะยังคงไมปรากฏขึ้นเปนตัวตนที่แนนอนในขณะนี้
ยังตองไดรับการพัฒนาจากทีมงานผูออกแบบผลิตภัณฑระบบปฏิบัติการไปอีกสักระยะเวลาหนึ่ง แตก็คอนขาง
ชัดเจนแลววาผูใชคอมพิวเตอรอยางเราๆ ทานๆ คงไดมีโอกาสใชขอมูลในรูป object ผานทางเครือขายเน็ตเวิรก
ภายในอนาคตอันใกล โดยอาศัยผลิตภัณฑตอไปนี้| คือ ระบบ OLE (Object Linking & Embedding) ของ
บริษัท Microsoft; ระบบมาตรฐาน OpenDoc ซึ่งเกิดขึ้นจากความรวมมือกันระหวางบริษัทApple, IBM,
WordPerfect, Novell และ Borland; ระบบ DSOM (Distributed System Object Model) ของบริษัท IBM;
และระบบ frameworks ของบริษัท Taligent Inc., ฯลฯ

5. 5
"Microsoft's OLE" object บนวินโดวส
ในวงการโฆษณาประชาสัมพันธ
นั้นมีคํากลาววา "ประสบการณครั้งแรก มักจะ
เปนตัวบงชี้ถึงความนิยมในผลิตภัณฑ" ซึ่งนั่นก็เปน
ความจริง เพราะบอยครั้งที่ผูบริโภคมักจะปฏิเสธ
ผลิตภัณฑยี่หอใดยี่หอหนึ่งไปอยางตัดญาติขาดมิตร
ไปเลย หากวาการทดลองใชครั้งแรกนั้นไมเปนที่
นาประทับใจ หรือเปนความประทับใจในดานลบ
และผูบริโภคที่มีความซื่อสัตยตอชื่อยี่หอมากๆ
(brand loyalty) ก็อาจจะตกลงปลงใจกับ
ผลิตภัณฑใดผลิตภัณฑหนึ่งไปตลอดชีพเลยก็ได
หากวาการทดลองครั้งแรกนั้นใหประสบการณในทางที่ดีเปนอยางมาก
สําหรับในกลุมผูใชคอมพิวเตอรแลว ประสบการณครั้งแรกที่มีตอผลิตภัณฑ Microsoft's OLE
(Object Linking & Embedding) นั้นนาจะเปนไปในทางบวกเสียมากกวาที่จะเปนไปในทางลบ เพราะการ
เปดตัวครั้งแรกของผลิตภัณฑ OLE (version 1.0) ซึ่งติดตั้งมาในระบบปฏิบัติการ Windows 3.1 นั้นนับวา
สามารถสางความประทับใจใหกับผูใชวินโดวสอยางเหลือหลาย ดวยผลิตภัณฑ Microsoft's OLE ไดทําใหผูใช
วินโดวสสามารถสอดแทรก object จากโปรแกรมประยุกตตางๆ เขาไปในเอกสาร (client document) อยาง
สะดวกสบาย
โดยที่ object ซึ่งทํางานภายใตระบบ Microsoft's OLE จะยังคงความเชื่อมโยงสัมพันธกับ
โปรแกรมประยุกตซึ่งสรางมันขึ้นมา (server applications) อยูตลอดเวลา หากผูใชวินโดวสตองการดัดแปลง
รายละเอียดภายใน object การคลิ้กเมาสซ้ําๆ กันสองครั้ง (double clicks) ที่ตัว object ก็จะทําใหโปรแกรม
ประยุกตเจาของ object ดังกลาวถูกเปดขึ้นมาเพื่อการทํางานดัดแปลงแกไข object ไดโดยอัตโนมัต
อยางไรก็ตาม ผลิตภัณฑ Microsoft's OLE 1.0 ยังคงมีขอจํากัดในการทํางานหลายๆ ประการที่
ทําใหงานบนวินโดวสหลายๆ อยางดําเนินไปไมสะดวกเทาที่ควร ยกตัวอยางเชน การอางอิงสถานที่อยูของ
object แบบสัมบูรณ (absolute path) ของ OLE 1.0 นั้นมักจะทําใหความเชื่อมโยงระหวาง object และ
เอกสารถูกทําลายลงอยางสิ้นเชิง หากผูใชวินโดวสมีการเคลื่อนยายตําแหนงของไฟลลซึ่งรับผิดชอบ object
ออกไปจากตําแหนงไดเรกตอรี่เดิม
ขอจํากัดอีกอยางหนึ่งของผลิตภัณฑ OLE 1.0 ก็เห็นจะไดแกการที่ระบบใชวิธีเปดโปรแกรม
server applications ซึ่งเปนเจาของ object ขึ้นซอนทับอยูบนเอกสารหลักอีกทีหนึ่งนั้น ซึ่งอาจจะทําใหผูใช
วินโดวสถูกทําใหออกจากโปรแกรมที่ใชงานอยูโดยไมตั้งใจ หากเกิดไปคลิ้กเมาสในตําแหนงหนาจอที่อยูนอกเหนือ
ขอบเขตของหนาตางที่โปรแกรมประยุกตครอบครองอยู
นอกจากนั้น การจัดการหนวยความจําแบบเรียงตามลําดับของ OLE 1.0 (load from a
stream, or save to a stream) ก็ยังทําใหการทํางานโดยรวมของ OLE 1.0 เปนไปอยางเชื่องชาอยางมาก
เพราะจะตองเรียกเอา object ทั้ง object ขึ้นมาทุกครั้งที่มีการเรียกใช หรือถาตองการจะอัพเกรด object

6. 6
เพียงนิดๆ หนอย ระบบ OLE 1.0 ก็บังคับใหตองบันทึก object ลงไปใหมทั้ง object เลย แทนที่จะอัพเกรด
เฉพาะสวนที่มีการเปลี่นแปลงแกไขเทานั้น
"OLE 2.0" พัฒนาการอีกขั้นของ Microsoft's object
ดังนั้น หลังจากเปดตัวผลิตภัณฑ
Microsoft's OLE เวอรชั่น 1.0 ขึ้นมาไดระยะหนึ่ง บริษัท
Microsoft จึงตองออกผลิตภัณฑ OLE เวอรชั่น 2.0 ติดตามมา
ในรูปของโปรแกรมสวนขยายของ Windows 3.1 (Windows
3.1 extension) โดยใน OLE 2.0 นี้ไดมีการปรับปรุงแกไขขอจํากัดตางๆ ที่เคยปรากฏในผลิตภัณฑ OLE 1.0
ออกไปจนหมดสิ้น อยางเชน การอางอิงแบบสัมบูรณที่เคยเปนสาเหตุของการสูญเสียความเชื่อมโยงโดยถาวรของ
object ก็ถูกปรับเปลี่ยนไปใชการอางอิงตําแหนงที่อยูแบบสัมพัทธแทน ("moniker" adaptable link) ทําใหการ
เชื่อมโยงระหวางเอกสารยังคงสภาพเดิมตลอดไมวาจะมีการยายไฟลลขอมูลไปไหนตอไหน
สวนปญหาเรื่องการหลุดออกจากโปรแกรมโดยไมตั้งใจเพราะไปดับเบิ้ลคลิ้กเมาสนอกหนาตาง
ของโปรแกรมนั้น ผลิตภัณฑ OLE 2.0 ก็ปรับปรุงแกไขดวยการกําหนดรูปแบบเอกสารหลัก (container) เสีย
ใหม ทําใหเวลาที่ผูใชวินโดวสคลิ้กเมาสไปบน object โปรแกรมประยุกตซึ่งควบคุม object อยูก็จะถูกเปดขึ้น
แทนที่เอกสารหลักไปโดยอัตโนมัติ (in-place activation) มิใชการเปดหนาตางขึ้นมาซอนทับอยูบนเอกสารหลัก
เชนในผลิตภัณฑ OLE 1.0
ที่สําคัญ ในผลิตภัณฑ OLE 2.0 นั้น ยังขยายขอบเขตความสามารถในการจัดการ
หนวยความจําขึ้นไปจากเดิม ทําใหผูใชวินโดวสสามารถเรียกอาน หรือบันทึก object เฉพาะสวนที่ตองการ หรือ
เฉพาะสวนที่ถูกอัพเดทเพิ่มขึ้นจากเดิมได ไมตองบันทึก หรือเรียกขอมูลทั้งหมดภายใน object ในแตละครั้ง จึง
ทําใหการทํางานโดยรวมของของระบบ OLE 2.0 มีความสะดวกรวดเร็วกวาผลิตภัณฑ OLE 1.0 มากมายนัก
นอกจากนั้น บริษัทไมโครซอฟทยังไดเสริมการทํางานดานโปรแกรมตางๆ เพิ่มเขามาอีกมากมายภายในผลิตภัณฑ
OLE 2.0 ที่ออกมาใหมของตน
ฉนั้น เมื่อมองจากมุมองของผูใชคอมพิวเตอรทั่วไปที่มีการติดตอกับคอมพิวเตอรในระดับ
โปรแกรมประยุกต ผลิตภัณฑ OLE 2.0 จึงเปนรูปแบบการประมวลผลที่นาประทับใจเปนอยางมาก อยางไรก็
ตาม สําหรับผูใชคอมพิวเตอรอีกกลุมหนึ่ง คือ กลุมโปรแกรมเมอรผูออกแบบและพัฒนาผลิตภัณฑโปรแกรม
ประยุกตสําหรับใชงานกับระบบปฏิบัติการวินโดวสแลว ระบบ OLE 2.0 อาจจะเปนที่มาของความยุงยากใจบาง
ประการสําหรับเหลานักโปรแกรมเมอรทั้งหลาย
เพราะในการทํางานรวมกับระบบ OLE 2.0 นั้น โปรแกรมเมอรจําเปนตองปรับเปลี่ยนแนวคิด
ในการทํางานของตนไปจากเดิมคอนขางมาก จากที่เคยเขียนโปรแกรมใหครอบคลุมการทํางาน user interface
ซึ่งติดตอกับผูใชโปรแกรมประยุกตโดยตรง ก็ตองเปลี่ยนไปเขียนโปรแกรมประยุกตที่โอนออนผอนตามการทํางาน
ของระบบ OLE 2.0 ประดุจทาสผูภักดีคนหนึ่ง และปลอยการติดตอกับผูใชคอมพิวเตอรใหเปนหนาที่ของระบบ
OLE 2.0 แตเพียงผูเดียว

7. 7
ในขณะเดียวกัน ถึงแมวาจะสูญเสียอํานาจในการติดตอกับผูใชคอมพิวเตอรไปใหระบบ OLE
2.0 แลวแตโปรแกรมประยุกตที่ถูกออกแบบมาเพื่อการทํางานภายใต OLE 2.0 ก็ยังคงตองออกแบบการอิน
เทอรซเฟระหวางโปรแกรม (interface) ใหมีความมั่นคงเชื่อถือได เพื่อวาจะสามารถติดตอสัมพันธกับ object
ของโปรแกรมประยุกตอื่นๆ (object interaction) ไดอยางถูกตองมีประสิทธิภาพมากที่สุด
ความสัมพันธระหวาง OLE 2.0 และ C++
การทํางานที่ผสานสัมพันธระหวาง object หลายๆ object ของโปรแกรมประยุกตตางชนิดกัน
ภายใตระบบ OLE 2.0 นั้น
เปนไปโดยผานการทํางาน
QueryInterface ของสวน
เชื่อมโยงสัญญาณหลัก (root
interface) ของระบบ OLE 2.0
ซึ่งมีชื่อเรียกวา "IUnknown"
เวลาที่ตองมีการติดตอระหวาง
object เกิดขึ้น ตัวโปรแกรม
เจาของ object ก็จะติดตอไปยังการทํางาน QueryInterface เพื่อรองขอรูปแบบการอินเทอรเฟซที่เหมาะสม ซึ่ง
จัดเก็บไวในตารางระบุชนิดการทํางานเสมือน (virtual function table หรือเรียกสั้นๆ วา vtable)
ตาราง vtable ของระบบ OLE 2.0 นี้จะมีลักษณะคลายคลึงกับตาราง vtable ซึ่งถุกสรางขึ้น
โดยโปรแกรม C++ compiler แตจะไมจําเพาะกับชนิด และประเภทของของแพล็ตฟอรมคอมพิวเตอร หรือชนิด
ของโปรแกรมคอมไพลลเลอรเชน vtable ของ C++ compiler (โครงสรางตาราง vtable ซึ่งถูกสรางขึ้นโดย C++
compiler จะมีรูปแบบแตกตางกันไปตามชนิดของระบบคอมพิวเตอร หรือชนิดของโปรแกรมคอมไพลลเลอรที่ใช
แต vtable ของระบบ OLE 2.0 จะเปนมาตรฐานเดียวกันตลอดไมวาจะใชกับเครื่องคอมพิวเตอรแพล็ตฟอรมใด)
ความคลายคลึงกับโปรแกรม C++ นั้น สงผลใหระบบ OLE 2.0 สามารถใชรวมกับโปรแกรม
C++ ไดงายกวาการใชงานรวมกับโปรแกรมภาษาชนิดอื่นๆ ทําใหโปรแกรมเมอรที่มีความถนัดในภาษา C++
สามารถเรียกใช object ของระบบ OLE 2.0 โดยผานทางโปรแกรมภาษา C++ ไดอยางไมมีปญหาในขณะที่การ
เรียกใช object ของ OLE ผานทางโปรแกรมภาษา C ธรรมดานั้นผูใชโปรแกรม C จะตองใชความพยายามขึ้น
จากการใชโปรแกรม C++ อีกกวาเทาตัว เพราะจะตองมีการจัดสราง vtable และเรียกใชอยางถูกตองชัดเจน
ความโนมเอียงไปสัมพันธกับโปรแกรมภาษา C++(C++ bias) ของผลิตภัณฑ OLE 2.0 สงผล
ใหมันมีภาพลักษณที่แตกตางไปอยางเดนชัดเมื่อเทียบกับระบบ OpenDoc ซึ่งเปนรูปแบบการประมวลผล
object-oriented computing อีกชนิดที่ไดรับความนิยมไมยิ่งหยอนไปจาก OLE 2.0 เพราะหัวใจของระบบ
OpenDoc นั้น อยูที่ IBM's SOM (System Object Mode) ซึ่งใชภาษาคําสั่ง neutrality language ที่มีความ
เปนกลางมากที่สุดในหมูบริษัทผูผลิตคอมพิวเตอรทั่วๆ ไป (คลายๆ กับวา OLE 2.0 นั้นเปนระบบปด ในขณะที่
OpenDoc เปนระบบเปด)

8. 8
แตละหนวย object ภายใตระบบ OLE 2.0 นั้น สามารถรองรับการทํางานตางๆ ภายในระบบ
คอมพิวเตอรไดอยางหลากหลาย ไมวาจะเปน การจัดการหนวยความจํา (memory management), การ
เชื่อมโยงระหวางชื่อของ object (name binding), การสงผานขอมูลไปมา (data transfer), หรือการจัดเก็บ
ขอมูลในรูป object (object storage) ฯลฯ
ในหมูของการทํางานภายในระบบคอมพิวเตอรซึ่ง object สัมพันธเกี่ยวของอยูดวยนั้น สวนที่
นับวามีความสําคัญมากที่สุด เห็นจะไดแกการอินเทอรเฟซซึ่งระบุถึงวิธีการซึ่งแตละ object ใชการตกลง
แบงสรรปนสวนทรัพยากร (resource negotiation) กับเอกสารหลัก เชนวา จะใหภาพของเอกสารที่ประกอบ
ไปดวย object หลายๆ ชนิดนั้นปรากฏบนหนาจอมอนิเตอรนั้นมีลักษณะ
อยางไร, หรือจะจัดเก็บขอมูลไวในหนวยความจําในลักษณะใด ฯลฯ
กลาวไดวาผลิตภัณฑ " OLE 2.0" ของบริษัทไมโครซอฟท
นี้ เปนหนึ่งในสุดยอดระบบการประมวลผลแบบ object-oriented
computing ที่มีอยูในปจจุบัน เพราะเพรียบพรอมไปดวยการทํางานอันมี
ประสิทธิภาพแทบทุกอยางที่ผูใชคอมพิวเตอรจะคาดหวังไดจากผลิตภัณฑ
ประเภทนี้ จะขาดไปบางก็เพียงความสามารถในการทํางานดานเน็ตเวิรก
(networking) เทานั้น ซึ่งทางบริษัทไมโครซอฟทเองก็กําลังมีแผนที่จะ
ออกผลิตภัณฑระบบปฏิบัติการ distributed, object-oriented
Windows ใหมของตนออกสูตลาดในชื่อ "Cairo" ภายในไมเกินป ค.ศ.
1995 ที่กําลังจะมาถึงนี้
"OpenDoc" มาตรฐาน object ที่เปนกลาง
เมื่อบริษัทไมโครซอฟทมีการพัฒนาระบบการประมวลผล object-orient computing "OLE"
ออกสูตลาด และไดรับความนิยมจากเหลาผูใชคอมพิวเตอรอยางกวางขวางดังที่กลาวมาแลวนั้น มีหรือที่บริษัท
ยักษใหญทางคอมพิวเตอรอยาง บริษัท Apple Computer จะยอมนอยหนา จึงไดรวมมืออีกเจ็ดบริษัท
คอมพิวเตอร อันไดแก IBM, WordPerfect, Novell, Sun, Xerox, Oracle และ Taligent จัดตั้งหนวยงานกลาง
ขึ้นมาในชื่อ the Component Integration laboratories (CIL) เพื่อออกแบบผลิตภัณฑ OpenDoc อันเปน
โครงสรางทางสถาปตยกลางสําหรับการประมวลผลแบบ object-oriented computing โดยเฉพาะ
ระบบ OpenDoc นี้เปนโครงสถาปตยแบบ object-oriented compound document
architecture ซึ่งถูกออกแบบมาอยางเปดกวางและเปนกลางไมขึ้นกับรูปแบบการทํางานของระบบคอมพิวเตอร
ยี่หอใดยี่หอหนึ่ง (vendor neutral) สามารถใชไดกับโปรแกรมประยุกตที่ถูกออกแบบมาใหทํางานตางระบบกันได
(cross-platform architecture) ไมวาโปรแกรมประยุกตดังกลาวนั้นจะถูกออกแบบมาเพื่อใชงานบนแพล็ตฟอรม
ระบบ PC-compatible, ระบบ Macintosh, ระบบ Unix หรือ ระบบ Netware ฯลฯ
อยางไรก็ตาม ระบบ OpenDoc ที่วานี้ยังคงเชื่องชาลาหลังไปจากผลิตภัณฑ OLE 2.0 ของ
ไมโครซอฟทอยูคอนขางมาก เพราะจนแมกระทั่งบัดนี้ผูใชคอมพิวเตอรอยางเราๆ ทานๆ ก็ยังไมมีโอกสาใช
ผลิตภัณฑ OpenDoc ที่วานี้กันเสียที เทาที่มีอยูก็ยังคงเปนผลิตภัณฑ Alpha version สําหรับทดสอบลองใชกัน

9. 9
เฉพาะในหมูผูพัฒนาระบบเทานั้น และกวาจะถึงขั้นการทดสอบแบบ Beta test ก็คงจะตองลวงเขาชวงซัมเมอร
ของฝรั่ง ซึ่งเปนชวงของการประชุมใหญประจําปเหลาผูพัฒนาโปรแกรมประยุกตของบริษัทแอปเปล (the Apple
Worldwide Develoer's Conference) พอดี
รายละเอียดพื้นฐานของ OpenDoc
แกนหลักในการทํางานของระบบ OpenDoc อยูที่เทคนิคการจัดเก็บขอมูลในหนวยความจําแบบ
"Bento storage mechenism" ซึ่งมีชื่อแปลกๆ เพราะตั้งชื่อตามชุดอาหาร
ญี่ปุน Bento plates โดยอางอิงจากความหลากหลายของชนิดอาหารที่
ประกอบอยูบนชุดอาหาร Bento ที่วานั้น, เทคนิคการจัดสรางชุดคําสั่ง
script (Scripting technology) ที่สวนใหญถูกหยิบยืมมาจากชุดคําสั่ง
AppleScript, และแบบจําลองระบบ IBM's SOM (System Object
Model)
การจัดวางหนวย object ตางๆ บนเอกสารภายใตการ
ทํางานของ Bento storage mechanism นั้น แตละหนวย object จะมี
หมายเลขรหัสประจําตัวที่ชัดเจนแนนอน (persistent ID) ไมเปลี่ยนแปลง
ไมวา object ดังกลาวนั้นจะถูกเคลื่อนยายไปไหนตอไหนภายในระบบ
คอมพิวเตอร หรือขามระบบคอมพิวเตอร ทําใหผูใชคอมพิวเตอรสามารถเรียกใช object ที่ตองการกลับมาใชได
อยางสะดวกสบาย ไมตางไปจากการติดตอกับ object ในระบบ OLE 2.0
แตที่การทํางาน Bento storage mechanism ของระบบ OpenDoc แตกตางไปจากระบบ
OLE 2.0 อยางชัดเจนเห็นจะไดแกวิธีการจัดการกับหนวยความจํา เพราะมันมิไดจัดเก็บไวเฉพาะขอมูลทราน
แซกชั่นที่ระบุวามีการดําเนินการอะไรกับ object บนเอกสารบางเหมือนในผลิตภัณฑ OLE 2.0 แตสามารถจัดเก็บ
และเรียกคนรายการปรับปรุงแกไขที่มีตอ object แตละ object ตั้งแตตนจนจบออกมาดูไดดวย (multiple
revision storing & tracking)
นอกจากนั้น หากมีการดัดแปลงแกไขรูปแบบเอกสารโดยรวม (Compound document) ไป
จากเดิมหลายๆ แบบราง (several drafts) ระบบการจัดเก็บขออมูลบนหนวยความจําของ OpenDoc ก็จะเลือก
เก็บเฉพาะสวนที่ไดรับการเปลี่ยนแปลงแกไขเพิ่มขึ้นจากเดิมเทานั้น (incremental changes) มิไดจัดเก็บแบบราง
ทั้งแบบราง ทําใหสามารถลดพื้นที่จัดเก็บขอมูลบนหนวยความจําลงไปไดอยางมาก รวมทั้งยังทําใหการเรียกดู
ขอมูลเอกสารแบบรางเปนไปอยางสะดวกรวดเร็วอีกดวย
ความสามารถในการจัดการเอกสารที่ไดรับการปรับเปลี่ยนไปในหลายๆ แบบราง (revision
control) นี่เองที่ทําใหระบบ OpenDoc ดูเหมือนวาจะมีภาษีเหนือกวาผลิตภัณฑ OLE 2.0 ของบริษัท
ไมโครซอฟทอยูคอนขางมาก (บริษัทไมโครซอฟทยืนยันวาจะมีการเสริมความสามารถในการทํางานแบบ revision
control ใหกับผลิตภัณฑ Object-oriented Operating system ของตนเหมือนกัน แตคงตองรอใชในผลิตภัณฑ
ระบบปฏิบัติการ cairo ที่กําลังจะออกสูตลาดนั่นแหละ)

10. 10
ชุดคําสั่ง Scripting ของ OpenDoc
สวนชุดคําสั่ง Scripting ของระบบ OpenDoc นั้นก็ดังที่กลาวมาแลวขางตนวาจําลองมาจาก
ชุดคําสั่ง AppleScript ของระบบปฏิบัติการ Macintosh เปนสวนใหญ จะมีปรับปรุงเพิ่มเติมบางก็ในสวนของ
ความพยายามติดตั้งชุดคํากริยามาตรฐานใหอยูในรูปแบบ polymorphism อันนาจะเปนที่ยอมรับโดยทั่วไปมาก
ที่สุดเทาที่จะมากได (as general as possible verbs) โดยเฉพาะกับกลุมของโปรแกรมประยุกตที่ถูกออกแบบมา
เพื่อรองรับการทํางานของระบบ OpenDoc
ตัวอยางที่แสดงใหเห็นการครอบคลุมความหมายอยางกวางๆ ของคํากริยาในชุดคําสั่ง
OpenDoc's Scripting ก็ไดแก คําสั่งที่บอกวา "move to next item" นั้น หากเปนคําสั่งที่ใชกับเอกสารประเภท
เวิรด ก็จะหมายความถึงการเคลื่อนไปยังคําถัดไป (move to next word) แตถาเปนการทํางานบนเอกสารตาราง
สเปรดชีต คําสั่งดังกลาวก็จะหมายถึงการเคลื่อนที่ไปยังชองตารางถัดไป (move to next cell)
การตกลงใจใชเทคนิค Polymorphism กับชุดคําสั่ง OpenDoc Scripting language ของ
บริษัท Appleนี้ เปนผลสืบเนื่องมาจากประสบการณของบริษัทที่มีมาอยางยาวนานในผลิตภัณฑ HyperCard และ
เชื่อมั่นในกลไกการทํางาน XCMD (ยอจาก external command) mechanism ของ HyperCard จะอนุญาตให
นักโปรแกรมเมอรที่ตองการเสริมการทํางานของตนเขามาในระบบ HyperCard สามารถสอดแทรกคําสั่ง
arbitrary commands เขาไวภายในชุดคําสั่ง HyperCard's Scripting language ได
อยางไรก็ตาม การที่จะทําอยางวานั้นได นักโปรแกรมเมอรผูออกแบบโปรแกรมประยุกตสําหรับ
ทํางานรวมกับผลิตภัณฑ HyperCard จําเปนตองอาศัยลูกไม และเทคนิคพลิกแพลงหลายๆ ประการมาประกอบ
เขากับการทํางาน XCMD ดวย (ความลําบากเล็กๆ นอยๆ เหลานี้เปนสิ่งนาจะหลีกเลี่ยงได หากวาแบบจําลอง
ชุดคําสั่ง HyperCard Language's model ไดรับการออกแบบโดยมีการคํานึงถึงจุดนี้ไวตั้งแตแรก)
ดังนั้น เพื่อใหชุดคําสั่ง Scripting ของผลิตภัณฑ
OpenDoc มีความสละสลวยหมดจดงดงามมากขึ้น ทีมงาน
ผูออกแบบผลิตภัณฑจึงตกลงใจที่จะใชแบบจําลอง IBM's SOM
แทนที่จะเปน HyperCard Scripting เพราะชุดคําสั่ง IBM's SOM
Scripting นั้นไมขึ้นกับภาษาคอมพิวเตอรประเภทใดประเภทหนึ่ง
(language-independent engine) ทั้งยังเพียบพรอมไปดวย
ความสามารถในการทํางานแบบ Inheritance และ Method-
dispatching ทําใหนักโปรแกรมเมอรตางๆ สามารถรวมเอา
โปรแกรมประยุกตที่แตกตางกันมากๆ เขามาไวดวยกันภายในระบบเดียวกันได
ยิ่งไปกวานั้น ทีมงานผูออกแบบผลิตภัณฑ OpenDoc ของบริษัท Apple ยังมีแผนที่จะ
ออกแบบใหระบบ OpenDoc สามารถทํางานรวมกับระบบ OLE ของไมโครซอฟทได (OLE's compatible) อีก
ดวย ซึ่งถาแผนดังกลาวประสบความสําเร็จตามที่ทีมผูออกแบบมุงมายไว มันก็หมายความวาตอไปผูใชระบบ
OpenDoc จะสามารถนําเอาขอมูลในรูป object จากระบบ OLE เขามาประกอบ และใชงานภายในเอกสารของ
OpenDoc ไดดุจดังวา object ดังกลาวนั้น เปน object ที่ถุกสรางขึ้นโดยตัวระบบ OpenDoc เองเลย และตัว

11. 11
object ที่ถูกเขามาวางไวในเอกสาร Compound document ของระบบ OpenDoc ก็จะรับรูถึงตัวเอกสารใน
รูปแบบเดียวกับเอกสาร Container* ที่มันติดตออยูตามปรกติออยางไรอยางนั้น
ในทางกลับกัน ผูใชผลิตภัณฑ OLE 2.0 ก็สามารถจะดึงเอาขอมูลใน รูป object ซึ่งสรางขึ้น
โดยระบบ OpenDoc เขาไปใชในเอกสาร container ของตนในรูปลักษณแนวทางเดียวกัน เพียงแตตองผานการ
แปลงรูปแบบฟอรแมทของ object (reverse translation) สักเล็กนอย โดยอาศัยการทํางาน Application
layer ซึ่งกําลังอยูระหวางการดําเนินการพัฒนาโดยบริษัท WordPerfect (เปนความรวมมือระหวางบริษัท
WordPerfect, Borland, Claris, Lotus และบริษัทผูผลิตซอฟทแวรคอมพิวเตอรอื่นๆ )
* ระบบ OpenDoc และ OLE 2.0 มีวิธีการเรียกเอกสารซึ่งประกอบไปดวย object ตางๆ ของตนที่แตกตางกัน
ขณะที่ผลิตภัณฑ OpenDoc เรียกเอกสารดังกลาววา "Compound document" ผลิตภัณฑ OLE 2.0 กลับ
เรียกวา "Container"
ซึ่งหากจะถามวา การพัฒนาใหผลิตภัณฑ object-oriented operating system ทั้งสองระบบ
สามารถทํางานรวมกัน และสามารถเคลื่อนยาย object ไปมาระหวางระบบไดนี้ มีโอกาสเกิดขึ้นจริงมากนอย
เพียงไร คําตอบในขณะนี้ก็ยังคงตองบอกวามันไมใชเรื่องที่จะกระทําไดอยางงายๆ นัก กระนั้น มันก็มีลูทางและ
แนวโนมที่จะเกิดขึ้นไดคอนขางมากอยู เพราะอยางนอยแนวคิดพื้นฐานเรื่อง object ของผลิตภัณฑทั้งสองระบบนี้
ก็เปนไปในทิศทางเดียวกัน, มีรูปแบบการทํางานพื้นฐานอยาง save และ delete เหมือนๆ กัน และมีรูปแบบการ
อินเทอรเฟซที่คลายคลึงกันอยางมาก ฯลฯ
"SOM & COM modeling" ใครจะเปนหมู ใครจะเปนจา ?
สวนสําคัญที่รองรับระบบ OpenDoc และ OLE 2.0 อยู คือแบบจําลองของการประมวลผล
แบบ object สองชนิดที่ดูเหมือนวาจะแขงขันกันอยางเอาเปนเอาตายอยูในขณะนี้ คือ แบบจําลอง IBM's SOM
(System Oboject Model) และแบบจําลอง
Microsoft's COM (Component Object Model)
ซึ่งแตละแบบจําลองก็ตางมีรูปแบบโปรโตคอลซึ่งใช
สําหรับการติดตอระหวาง object ที่มีลักษณะเฉพาะตัว
แตกตางกันออกไป
ความแตกตางที่เห็นไดชัดระหวาง
แบบจําลอง SOM และ แบบจําลอง COM คือในขณะที่
แบบจําลอง SOM ของบริษัท IBM ใชภาษาคําสั่งที่
คอนขางเปนกลางสําหรับเหลาบริษัทผูผลิตผลิตภัณฑ
ทางคอมพิวเตอรทั่วๆ ไป (language-neutral) และมี
การสนับสนุนการทํางานแบบ Inheritance ซึ่งอนุญาต

12. 12
ใหแตละโปรแกรมประยุกตสามารถถายทอดคุณลักษณะไปยัง object ยอยๆ ที่มันเปนผูใหกําเนิดขึ้นมาได
(คลายๆ กับการถายทอดพันธุกรรมจากพอแมปูยาตายายไปยังลูกหลานนั่นแหละ)
แตแบบจําลอง COM ของบริษัทไมโครซอฟทกลับใชภาษาซึ่งคอนขางมุงเนนไปในลักษณะของ
ภาษา C++ เสียสวนมาก และแทนที่จะใชวิธีการสืบทอดคุณลักษณะตางๆ ของตัวโปรแกรมประยุกตไปยัง object
ซึ่งมันสรางขึ้นแบบแบบ Inheritance แบบจําลอง COM ก็เลี่ยงไปใชวิธีการเชื่อมโยงความสัมพันธระหวาง
โปรแกรมประยุกตและ object กันแบบ aggregation แทน
แบบจําลอง SOM ถูกนําออกสูตลาดคอมพิวเตอรครั้งแรกโดยบริษัท IBM ดวยการติดตั้งมากับ
ระบบปฏิบัติการ OS/2 2.0 เพื่อใชสนับสนุนการทํางาน class hierachy ในสวน WorkPlace Shell ของ
ระบบปฏิบัติการ OS/2 2.0 แตรูปแบบของแบบจําลอง SOM ในขณะนั้นยังมีสภาพเปนเพียงโปรแกรมประยุกต
ที่ใชสําหรับกําหนดลําดับชั้นของ object (object heirachies defining) และกระตุนเรียกเอา object ขึ้นมา
ทํางาน (object invoking) โปรแกรมหนึ่งเทานั้น
ภายใตการทํางานของแบบจําลอง SOM รุนแรกที่วานั้น เมื่อ SOM object หนึ่งเรียกกระตุนไป
ยังอีก SOM object หนึ่ง โปรแกรมการทํางาน SOM run-time engine จะทําหนาที่ขัดจังหวะการเรียก แลว
จัดการกําหนดตําแหนงเปาหมายของ object ที่ถูกเรียก, และกระตุนเอา object เปาหมายดังกลาวขึ้นมาทํางาน
พรอมกับที่จัดสงเอาคาพารามิเตอรตางๆ ที่เกี่ยวของกับการทํางานไปยัง object เปาหมาย ในรูปของขอมูลฐาน
สองมาตรฐาน (standard binary format parameter)
ดวยรูปแบบ
การทํางานดังกลาวของ
แบบจําลอง SOM ไดชวย
แกปญหาความไมผสมผสาน
ระหวางภาษา (poorly
interoperate) ที่เคยเปน
อุปสรรคสําหรับเหลา
โปรแกรมเมอรผูใชโปรแกรม
ภาษา OOP (Object-
oriented programing) language มาอยางเนิ่นนานลงได โดยปญหาความไมผสมผสานลงตัวระหวางภาษานี้
เดิมเกิดขึ้นเพราะยังไมมีมาตรฐานขอมูลฐานสอง (binary standard) ที่จะใชสนับสนุนการทํางานแบบ
inheritance และ Method dispatching ระหวางโปรแกรมที่ผานการคอมไพลลมาโดยโปรแกรมคอมไพลลเลอร
ที่ตางกันได
ตัวอยางของความไมผสมผสานระหวางโปรแกรมภาษาก็ไดแก การที่เราไมสามารถนําเอากลุม
โปรแกรม class libraries ซึ่งถูกเขียนขึ้นดวยโปรแกรมภาษา Borland C++ มาดัดแปลงงาน (extend) ดวย
โปรแกรมภาษา Microsoft C++ ได, หรืออีกกรณีหนึ่งก็ไดแกการที่เราไมสามารถจะนําเอากลุมโปรแกรม class
libraries ที่สรางขึ้นโดยโปรแกรม Microsoft C++ หรือ Borland C++ มาใชงาน (inherit) หรือดัดแปลง
(extend) ดวยโปรแกรมภาษา COBOL, C, หรือ Smalltalk ได ฯลฯ

13. 13
อยางไรก็ตาม ปญหาความไมผสมผสานระหวางโปรแกรมภาษาตางๆ เหลานี้จะสามารถกําจัดให
หมดสิ้นไปได หากปลอยใหโปรแกรม SOM เปนผูรับผิดชอบตอการทํางานสวน inheritance และ method
dispatching แทนที่จะปลอยใหเปนการทํางานของโปรแกรมภาษา Borand C++, Microsoft C++ หรือ
โปรแกรมภาษา Object-oriented programming language ประเภทอื่นๆ
นอกจากนี้ แบบจําลอง SOM ยังนํามาซึ่งคุณประโยชนอื่นๆ อีกหลายอยาง ที่เห็นไดชัดๆ ก็คือ
เรื่องความสะดวกรวดเร็วในการพัฒนาโปรแกรม (rapid development) อันเปนเรื่องที่ผูพัฒนาโปรแกรมสวน
ใหญมักจะใหความสําคัญกับมันเปนอยางมาก บางคนถึงกับเลิกใชโปรแกรมบางภาษาไปเลยเพราะความชักชา
เสียเวลา โดยเฉพาะกลุมโปรแกรมประเภทที่ตองมีการคอมไพลลโปรแกรมทั้งโปรแกรมใหมหมด (recompile)
ทุกครั้งมีการดัดแปลงแกไขอะไรเพียงนิดหนอยในโปรแกรม
ความรวดเร็วในการทํางานของแบบจําลอง SOM เปนผลมาจากการที่มันถูกออกแบบมาใหไม
จําเปนตองมีการคอมไพลลโปรแกรมใหม (recompile) ทุกครั้งที่การดัดแปลงแกไขโปรแกรม ผูใชแบบจําลอง
SOM สามารถเสริมรูปแบบการทํางานใหมๆ (new method) หรือคาตัวแปรจําเพาะที่ (local variables) เขาไป
ในโปรแกรมหลัก (base class) ไดโดยไมจําเปนตองคอมไพลลโปรแกรมดังกลาวเสียใหม ในขณะที่โปรแกรมซึ่ง
ผานการดัดแปลงแกไขจากเดิมไปแลวนั้นก็ยังคงความสามารถในการเรียกใชการทํางานเดิมๆ ที่เคยมีอยูใน
โปรแกรมหลัก (base class's method) ไดอยางไมมีปญหา
ความยืดหยุนของโปรแกรมดังกลาวมีความสําคัญอยางมาก หากวาเราตองการใหระบบ
คอมพิวเตอรสามารถพัฒนาขอบเขตความสามารถการทํางานขึ้นไปจากเดิมไดอยางไมมีปญหา ยกตัวอยางเชน
ถาเรามีการจัดสรางหนาตาง object สําคัญๆ ขึ้นมาหนาตางหนึ่ง โดยภายในหนาตางนั้นเกี่ยวของสัมพันธกับ
โปรแกรมประยุกตหลายๆ โปรแกรม เราก็คงไมคาดหวังวาจะตองกลับมานั่งคอมไพลลหนาตางดังกลาวใหมหมด
เมื่ออยูๆ วันดีคืนดีทางบริษัท IBM มีการอัพเดทระบบซี่งรองรับหนาตางดังกลาวเสียใหม
ตรงนี้เองที่แบบจําลอง SOM เปนเสมือนอัศวินขี่มาขาวเขามา เพราะมันทําใหผูใชไมตองคอม
ไพลลโปรแกรมเสียใหมทุกครั้งที่มีการเปลี่ยนแปลงของระบบหลัก (base system) อยางไรก็ตาม ความยืดหยุน
ดังกลาวของระบบก็มิไดเปนสิ่งจะไดมาฟรีๆ ตองแลกมาดวยขอจํากัดบางอยาง เพราะการติดตั้งแบบจําลอง
SOM เขามานั้นหมายถึงวาตัวโปรแกรมคอมไพลลเลอรจะไมสามารถปรับเปลี่ยนรูปแบบการสื่อสารระหวาง
object (interobject communication optimize) เชนเคยทําได
นอกจากนั้น เมื่อไมนานมานี้ทางบริษัท IBM ยังมี
การจะพัฒนาขีดความสามารถของแบบจําลอง SOM ใหขึ้นไปเลนบน
ระบบการประมวลผลบนเครือขายเน็ตเวิรกคอมพิวเตอรอยาง
IPX/SPX, TCP/IP, และ NetBIOS networks ภายใตชื่อ DSOM
(Distributed SOM) อีกดวย โดยแบบจําลอง DSOM ซึ่งไดรับการ
พัฒนาขึ้นมาใหมนี้ จะมีรูปลักษณที่ไทแตกตางไปจากแบบจําลอง
SOM เลยในสายตาของโปรแกรมเมอรทั่วๆ ไป เพียงแตวา

14. 14
แบบจําลอง DSOM นั้นจะมีโปรแกรม run-time engine ที่สามารถจับคู object เขากับคําสั่งรองขอ (request)
ตางๆ ไดอยางเหมาะสม ไมจํากัดวาคํารองขอดังกลาวนั้นจะมาจากกระบวนการทํางานประเภทใด หรืออยูภายใต
การทํางานของคอมพิวเตอรประเภทใด
แบบจําลอง COM
แบบจําลอง COM (Compound Object Model) ไดรับการพัฒนาขึ้นโดยบริษัทไมโครซอฟทไว
เพื่อใชงานกับผลิตภัณฑ OLE 2.0 ของตนโดยเฉพาะ มีเปาหมายในการทํางานไมตางไปจากแบบจําลอง SOM
ของบริษัทไอบีเอ็มสักเทาใดนัก เพียงแตใชรูปแบบวิธีการที่ตางออกไปเทานั้น ความแตกตางสําคัญอยูตรงที่
บริษัทไมโครซอฟทเลือกที่จะใชเทคนิค aggregation ในการเชื่อมโยงความสัมพันธระหวางโปรแกรมประยุกตกับ
object ที่มันสรางขึ้น แทนที่จะเปนเทคนิค inheritance เชนในแบบจําลอง SOM
การทํางานของเทคนิค aggregation ของแบบจําลอง COM นั้น จําเปนที่แตละ object จะตอง
ประกอบไวดวยคาตัวชี้ (pointer) ซึ่งระบุไปยัง object ที่อยูลําดับสูงขึ้นไป (higher hierachy) เชน สมมติวา
เรามีการจัดสราง object ในรูปตารางสเปรดชีตขึ้นมาสัก object หนึ่ง โดยตารางที่สรางขึ้นนี้มีขอพิเศษจาก
ตารางสเปรดชีตทั่วๆ ไปหนอยตรงที่ตองการใหขนาดความกวางคอลัมนของตารางสามารถปรับขยายไดตาม
ตองการ(flexible columns width) ไมจํากัดที่ขนาดความกวางขนาดใดขนาดหนึ่ง (fixed columns)
หากเปนการทํางานของโปรแกรมภาษา OOPs รุนเกาๆ ทั่วๆ ไป ก็คงจะตองมีการถายทอด
คุณสมบัติตางๆ ดานตารางตามที่กําหนดไปยัง object จากโปรแกรมพื้นฐาน (capabilties inherit) จากนั้นก็
จัดการครอบงําสวนการทํางาน display function ที่เกี่ยวของการแสดงภาพบนหนาจอ ใหจัดสรางตารางสเปรด
ชีตที่มีชองคอลัมนซึ่งสามารถปรับขยายขนาดได แลวตัวโปรแกรมคอมไพลลเลอรภาษา C++ หรือโปรแกรม SOM
run-time machine จะเปนตัวกําหนดสงคําสั่งการแสดงออกบนหนาจอมอนิเตอร (display call) ที่วานั้นไปยัง
object สเปรดชีตที่เราสราง พรอมๆ กับที่มีการสรางเสนทางการเดินทางของคําสั่งดังกลาวอีกสายหนึ่งไปยัง
object เดิมซึ่งเปนตนกําเนิดของตารางสเปรดชีต
แตสําหรับเทคนิค
aggregation ของแบบจําลอง COM แลว
มันจะไมมีการกําหนดทิศทางคําสั่งแสดงออก
บนหนาจอใหมโดยอัตโนมัติ (automatic
redirection) เชนแบบจําลอง SOM ผูใช
แบบจําลอง COM ตองระบุรายละเอียด
คาตัวชี้ซึ่งอางอิงไปยัง object ลําดับสูงขึ้น
ไป (upper class reference pointer)
เพิ่มใหกับตาราง vtable ของ object สเป
ปรดชีตที่ไดรับการดัดแปลงแกไขดวยตนเอง
ซึ่งการรวมเอา pointer เขากับ object นี้
เองที่ทางบริษัทไมโครซอฟทเรียกวาการ aggregate

15. 15
การ aggregrate หรือการผนึกคา pointer เขากับ object นี้มีความสําคัญอยางมากสําหรับ
แบบจําลอง COM เพราะการทํางาน QueryInterface ในแตละ object ของ OLE จะรูจักวาตองติดตอกับ
object อื่นๆ อยางไรบางก็อาศัยขอมูลภายในตาราง vtable (virtual function table) เทานั้น มันไมสามารถ
สืบคนกลับไปยัง object อื่นๆ ไดดวยตัวของมันเอง แมวา object นั้นจะเปนตนกําเนิดและเทือกเถาเหลากอของ
มันเองก็ตาม (ancestor objects)
ที่ทีมงานวิศวกรผูออกแบบโครงสรางทางสถาปตยของไมโครซอฟทเลือกตกลงใจที่จะใชเทคนิค
การ aggregation กับแบบจําลอง COM ของตนก็เนื่องมาจากเหตุผลวาตองการปกปองตัวโปรแกรมอันเปนตน
กําเนิดดั้งเดิมของ object จากขอผิดพลาดที่คาดไมถึง (fragile base class) อันเนื่องมาจากการดัดแปลงแกไข
รายละเอียดไปจากเดิม แตในขณะเดียวกันพวกเขาก็ไมตองการตัดขาดความสัมพันธระหวาง object กับรากฐาน
เดิมที่สรางมันขึ้นมา จึงใชวิธีเพิ่มคาตัวชี้ (pointers) เขาไปในตาราง vtable ของ object แทน
การปฏิวัติครั้งสําคัญของ Taligent
ระบบปฏิบัติการ Taligent นั้นนับวาเปนปรากฏการณที่คอนขางใหมในหมูระบบปฏิบัติการ
object-oriented operating system เพราะแทนที่จะไปนําเอาแบบจําลอง และโครงสรางทางสถาปตยที่มีๆ
อยูมาดัดแปลงแกไขใหมใหเปนการประมวลผลในแบบ object เชนผลิตภัณฑ object-oriented OS รายอื่นๆ
ทางบริษัท
Taligent กลับ
เลือกจัดสราง
ระบบปฏิบัติการใน
แนว object-
oriented ขึ้นมา
จากรากฐานเลย
ทีเดียว
ทําใหทุกๆ สวนของระบบปฏิบัติการ Taligent ไมวาจะเปนสวนโปรแกรมขับอุปกรณ (device drivers)
หรือสวนของโปรแกรมประยุกต (applications) ตางก็ลวนอางอิงถึงแบบจําลอง object เดียวกันทั้งสิ้น
(common object model) โดยทางบริษัท Taligent เชื่อวาดวยรูปแบบการพัฒนาบริษัทระบบปฏิบัติการแนวนี้
เทานั้น จึงจะทําใหระบบปฏิบัติการที่ไดมามีความบริสุทธผุดผอง ไมมีขอติดขัดขัดแยงอันเนื่องจากการผสม
กลมกลืนระหวางผลิตภัณฑตางระบบ และสามารถพัฒนาขยับขยายตอไปไดอยางไมจํากัด (completly
extensible)
พื้นฐานโครงสรางหลักของระบบปฏิบัติการ Taligent อยูที่สวนการทํางานที่เรียกวา
"framework" อันเปรียบเสมือนบังเหียนที่คอยควบคุมบังคับกลุมของ object ตางๆ ที่เขามาประกอบในระบบให
ดําเนินไปในิศทางเดียวกัน อยางไรก็ตาม คําวา Framework ของระบบปฏิบัติการ Taligent นี้จะแตกตางไปจาก
ความหมายของคําวา Framework เดิมๆ(conventional framework) ที่เคยรูจักกันมา

16. 16
โดยในความหมายของ Framework แบบเกาๆ ซึ่งประกอบไปดวยกลุมโปรแกรม Object
Windows Library (OWL) ของบริษัท Borland และกลุมโปรแกรม MacApp ของบริษัท Apple นั้น จะ
ครอบคลุมเฉพาะในระดับของการจัดสรางโปรแกรมประยุกตซึ่งทํางานภายใตระบบปฏิบัติการ Windows หรือ
Macintosh อันประกอบไปดวยกลุมโปรแกรม classes for Windows, controls, menus และรูปแบบการ
ทํางานของโปรแกรมประเภท GUI (Graphic User Interface) ประเภทตางๆ เทานั้น
ซึ่งการทํางานของ Framework แบบเดิมๆ หรือ Conventional framework นี้ จะมุงเนนไป
ที่ความสะดวกสบายและความเปนมาตรฐานในการติดตอกับผูใชคอมพิวเตอร ทําใหเหลาโปรแกรมเมอรทั้งหลาย
สามารถทุมเทเวลาสวนใหญไปมุงเนนไปที่การออกแบบโปรแกรมประยุกตของตนไดอยางลึกซึ้ง และมี
ประสิทธิภาพมากยิ่งขึ้น โดยปลอยใหสวนของการติดตอกับผูใชกลายเปนอํานาจหนาที่ของสวนการทํางาน
Framework ไป
แตสําหรับสวนการทํางาน Framework ของระบบปฏิบัติการ Taligent แลว มันจะลงลึกไปกวา
การทํางาน Framework แบบเดิมๆ มากมายนัก เพราะไดมีการเจาะลึกลงไปถึงกนบึ้งของระบบปฏิบัติการนั่น
เลยทีเดียว ซึ่งนั่นก็ยอมทําใหโปรแกรมประยุกตตางๆ ที่ถูกเขียนขึ้นเพื่อการทํางานรวมกับระบบปฏิบัติการ
Taligent มีอิสระในการทํางานไดมากยิ่งขึ้น แตก็อีกนั่นแหละ เสรีภาพในการออกแบบโปรแกรมประยุกตของ
โปรแกรมเมอรนั้นก็หมายถึงวาเหลาโปรแกรมเมอรจะตองมีความระมัดระวัง และความรับผิดชอบในการเขียน
โปรแกรมมากยิ่งขึ้นตามไปดวย จะตองระมัดระวังวาการดัดแปลงปรับรูปแบบการทํางานตางๆ ของตนจะตองไม
ไปรบกวนกับการทํางานของระบบปฏิบัติการโดยรวมดวย
กลาวโดยรวมๆ แลว ระบบปฏิบัติการ Taligent นี้ก็นับไดวาเปนระบบปฏิบัติการแบบ Object-
oriented OS ที่นาสนใจเปนอยางมาก เพราะเปนผลิตภัณฑที่ไดรับการออกแบบขึ้นเพื่องานประมวลผลแบบ
object ตั้งแตสวนรากฐานขึ้นมาเลยทีเดียว จะมีปญหาอยูบางก็เฉพาะเรื่องความไมแนนอนในนโยบายของ
บริษัทเทานั้น เพราะบริษัท Taligent นั้นเปนผลิตผลรวมระหวางบริษัท Apple และบริษัท IBM ดังนั้นจะทํา
อะไรสักอยางก็ติดขัดวาทางบริษัทแมของตนจะวาอยางไร (คลายๆ กับรัฐบาลผสมหาพรรคของไทยเรานั่นๆ แหละ
จะทําอะไรก็ดูเหมือนยึกยักเอาแนนอนไมคอยไดเหมือนกัน)
"NeXTStep" ผูมากอนกาล
ความฮือฮาในเทคโนโลยีการประมวลผลแบบ object-oriented computing ที่เกิดขึ้นภายใน
ชวงสองสามปที่ผานมา รวมทั้งขาวสารขอมูลที่ออกมาจากเหลาบริษัทผูผลิตผลิตภัณฑคอมพิวเตอรรายสําคัญๆ
เชน Apple, IBM, Microsoft และ Taligent ที่ปรากฏออกสูสายตาผูคนในวงการคอมพิวเตอรอยางตอเนื่อง
อาจจะทําใหผูใชคอมพิวเตอรอยางเราๆ ทานๆ หลงประเด็นไปไดเหมือนกันวา บริษัทเหลานี้นี่แหละที่เปนผูให
กําเนิดเทคโนโลยีการประมวลผลแบบ object-oriented ทั้งที่จริงๆ แลวพวกเขาเปนเพียงผูที่เขามาเก็บเกี่ยว
ผลประโยชนจากสิ่งที่บริษัท Next เขามาบุกเบิกหักรางถางพงแตแรกดวยผลิตภัณฑระบบปฏิบัติการ NeXTStep
ระบบปฏิบัติการ NeXTStep ซึ่งนับไดวาเปนผูเปดศักราชแหงเทคโนโลยีการประมวลผลแบบ
object-oriented ที่วานี้ไดเปนที่ปรากฏตอสายตาผูใชคอมพิวเตอรครั้งแรกก็ตั้งแตหาปที่แลว (ค.ศ. 1989) โดย
ถูกติดตั้งมากับผลิตภัณฑเครื่องคอมพิวเตอร Personal workstation ของบริษัท Next ประกอบไปดวย