แนวคิดในการตั้งชื่อคลาสที่มีคำต่อท้าย“ ข้อมูล” เช่น:“ SomeClass” และ“ SomeClassInfo” คืออะไร

ฉันกำลังทำงานในโปรเจ็กต์ที่เกี่ยวข้องกับอุปกรณ์ทางกายภาพและฉันสับสนว่าจะตั้งชื่อคลาสบางคลาสในโครงการนี้ได้อย่างไร

เมื่อพิจารณาถึงอุปกรณ์จริง (เซ็นเซอร์และตัวรับสัญญาณ) เป็นสิ่งหนึ่งและการเป็นตัวแทนของพวกเขาในซอฟต์แวร์นั้นเป็นอีกสิ่งหนึ่ง

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

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

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

ภาษาที่ฉันทำงานด้วยคือ. NET และรูปแบบการตั้งชื่อนี้ดูเหมือนจะเป็นเรื่องทั่วไปตลอดทั้งเฟรมเวิร์กสำหรับตัวอย่างของคลาสเหล่านี้:

• DirectoryและDirectoryInfoชั้นเรียน
• FileและFileInfoชั้นเรียน
• ConnectionInfoชั้นเรียน (ไม่มีConnectionชั้นเรียนผู้สื่อข่าว);
• DeviceInfoชั้นเรียน (ไม่มีDeviceชั้นเรียนผู้สื่อข่าว);

ดังนั้นคำถามของฉันคือ: มีเหตุผลทั่วไปเกี่ยวกับการใช้รูปแบบการตั้งชื่อนี้หรือไม่? มีกรณีที่เหมาะสมหรือไม่ที่จะมีชื่อคู่ ( ThingและThingInfo) และกรณีอื่น ๆ ที่ควรมีอยู่เฉพาะThingInfoคลาสหรือThingคลาสโดยไม่มีคู่

ฉันคิดว่า "ข้อมูล" เป็นชื่อเรียกผิด วัตถุมีสถานะและการกระทำ: "ข้อมูล" เป็นเพียงชื่ออื่นสำหรับ "สถานะ" ซึ่งถูกอบเข้าสู่ OOP แล้ว

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

นั่นเป็นเรื่องง่ายที่จะพูด แต่เมื่อคุณค้นพบว่ามีมากกว่านั้น "การแทนฮาร์ดแวร์" นั้นกว้างอย่างน่าประหลาดใจ วัตถุที่มีข้อกังวลหลายประการ:

• การสื่อสารอุปกรณ์ระดับต่ำไม่ว่าจะเป็นการพูดคุยกับอินเตอร์เฟส USB, พอร์ตอนุกรม, TCP / IP หรือการเชื่อมต่อที่เป็นกรรมสิทธิ์
• ผู้จัดการรัฐ อุปกรณ์เปิดอยู่หรือไม่ พร้อมที่จะคุยกับซอฟต์แวร์หรือยัง ไม่ว่าง?
• การจัดการเหตุการณ์ อุปกรณ์ผลิตข้อมูล: ตอนนี้เราต้องสร้างกิจกรรมเพื่อส่งผ่านไปยังคลาสอื่น ๆ ที่สนใจ

อุปกรณ์บางอย่างเช่นเซ็นเซอร์จะมีความกังวลน้อยกว่าการพูดของอุปกรณ์มัลติฟังก์ชั่นเครื่องพิมพ์ / สแกนเนอร์ / แฟกซ์ เซ็นเซอร์มีแนวโน้มที่จะสร้างกระแสบิตในขณะที่อุปกรณ์ที่ซับซ้อนอาจมีโปรโตคอลที่ซับซ้อนและการมีปฏิสัมพันธ์

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

นี่คือตัวอย่างของวิธีที่ฉันจะออกแบบลำดับชั้นของชั้นเรียนสำหรับเซ็นเซอร์อุณหภูมิ:

• ITemperatureSource: อินเทอร์เฟซที่แสดงถึงสิ่งใดก็ตามที่สามารถสร้างข้อมูลอุณหภูมิ: เซ็นเซอร์อาจเป็นไฟล์หุ้มหรือข้อมูลที่เขียนโค้ดยาก (คิดว่า: การทดสอบจำลอง)

• Acme4680Sensor: เซ็นเซอร์รุ่น ACME 4680 (เหมาะสำหรับการตรวจจับเมื่อมี Roadrunner อยู่ใกล้เคียง) สิ่งนี้อาจใช้หลายอินเตอร์เฟส: บางทีเซ็นเซอร์นี้ตรวจจับทั้งอุณหภูมิและความชื้น วัตถุนี้มีสถานะระดับโปรแกรมเช่น "มีการเชื่อมต่อเซ็นเซอร์หรือไม่?" และ "สิ่งสุดท้ายที่อ่านคืออะไร"

• Acme4680SensorComm: ใช้แต่เพียงผู้เดียวสำหรับการสื่อสารกับอุปกรณ์ทางกายภาพ มันไม่ได้รักษาสถานะมาก มันใช้สำหรับการส่งและรับข้อความ มันมีวิธี C # สำหรับแต่ละข้อความที่ฮาร์ดแวร์เข้าใจ

• HardwareManager: ใช้สำหรับรับอุปกรณ์ นี่คือโรงงานที่เก็บอินสแตนซ์: ควรมีเพียงหนึ่งอินสแตนซ์ของวัตถุอุปกรณ์สำหรับแต่ละอุปกรณ์ฮาร์ดแวร์ มันต้องฉลาดพอที่จะรู้ว่าถ้าเธรด A ร้องขอเซ็นเซอร์อุณหภูมิ ACME และเธรด B ร้องขอเซ็นเซอร์ความชื้น ACME จริง ๆ แล้วเป็นวัตถุเดียวกันและควรส่งคืนไปยังเธรดทั้งสอง

ที่ระดับบนสุดคุณจะมีส่วนต่อประสานสำหรับฮาร์ดแวร์แต่ละประเภท พวกเขาอธิบายการกระทำที่รหัส C # ของคุณจะใช้กับอุปกรณ์โดยใช้ประเภทข้อมูล C # (ไม่เช่นอาร์เรย์ไบต์ซึ่งไดรเวอร์อุปกรณ์ดิบอาจใช้)

ในระดับเดียวกันคุณมีคลาสการแจงนับพร้อมหนึ่งอินสแตนซ์สำหรับฮาร์ดแวร์แต่ละประเภท เซ็นเซอร์วัดอุณหภูมิอาจเป็นประเภทหนึ่งเซ็นเซอร์ความชื้นอื่น

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

แต่ละคลาสอุปกรณ์มีคลาส Comm (การสื่อสาร) ส่วนตัวที่จัดการงานระดับต่ำของการพูดคุยกับฮาร์ดแวร์

ด้านนอกของโมดูลฮาร์ดแวร์เลเยอร์เดียวที่มองเห็นได้คืออินเตอร์เฟส / enum รวมถึง HardwareManager ชั้นตัว hardware manager เป็นนามธรรมโรงงานที่จับ instantiation ของการเรียนอุปกรณ์แคชอินสแตนซ์ (คุณจริงๆไม่ต้องการสองชั้นเรียนอุปกรณ์การพูดคุยกับอุปกรณ์ฮาร์ดแวร์เดียวกัน) เป็นต้นชั้นที่ต้องการประเภทเฉพาะของเซ็นเซอร์ถามตัว hardware manager ที่จะได้รับ อุปกรณ์สำหรับ enum ที่เฉพาะเจาะจงซึ่งจะเป็นตัวกำหนดว่ามันอินสแตนซ์อยู่แล้วหากไม่ใช่วิธีการสร้างและเริ่มต้น ฯลฯ

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

หมายเหตุ: มีการเชื่อมโยงระหว่าง HardwareManager และอุปกรณ์แต่ละคลาสที่ฉันไม่ได้วาดเพราะแผนภาพจะกลายเป็นซุปลูกศร

อาจเป็นเรื่องยากเล็กน้อยที่จะหาการประชุมแบบรวมเป็นหนึ่งเดียวที่นี่เพราะคลาสเหล่านี้กระจายออกไปทั่วเนมสเปซจำนวนมาก ( ConnectionInfoดูเหมือนจะอยู่ในCrystalDecisionsและDeviceInfoในSystem.Reporting.WebForms)

แม้ว่าการดูตัวอย่างเหล่านี้ดูเหมือนจะมีการใช้คำต่อท้ายที่ต่างกันสองแบบ:

• แยกแยะคลาสที่จัดเตรียมเมธอดแบบสแตติกกับคลาสที่จัดเตรียมเมธอดอินสแตนซ์ นี่เป็นกรณีสำหรับSystem.IOคลาสตามที่ขีดเส้นใต้โดยคำอธิบาย:

  ไดเรกทอรี :

  เปิดเผยวิธีการคงที่สำหรับการสร้างการย้ายและการแจงนับผ่านไดเรกทอรีและไดเรกทอรีย่อย คลาสนี้ไม่สามารถสืบทอดได้

  DirectoryInfo :

  แสดงวิธีการอินสแตนซ์สำหรับการสร้างการย้ายและการแจงนับผ่านไดเรกทอรีและไดเรกทอรีย่อย คลาสนี้ไม่สามารถสืบทอดได้

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

• เน้นว่าคลาสเก็บข้อมูลเท่านั้นและไม่ได้จัดเตรียมลักษณะการทำงานที่อาจถูกคาดหวังจากชื่อที่ไม่ได้ต่อท้าย

  ผมคิดว่าส่วนสุดท้ายของประโยคที่อาจเป็นชิ้นส่วนของจิ๊กซอว์ที่แตกต่าง, กล่าวว่าจากConnectionInfo EmployeeInfoถ้าฉันมีชั้นเรียนที่เรียกว่าConnectionฉันคาดหวังว่ามันจะให้ฟังก์ชั่นการเชื่อมต่อที่ฉันมี - ฉันกำลังมองหาวิธีการเช่นvoid Open()ฯลฯ อย่างไรก็ตามไม่มีใครในใจที่ถูกต้องของพวกเขาจะคาดหวังว่าEmployeeชั้นเรียนจริง ๆ ทำในสิ่งที่จริงEmployeeไม่หรือมองหาวิธีการเช่นหรือvoid DoPaperwork()bool TryDiscreetlyBrowseFacebook()

โดยทั่วไปInfoวัตถุห่อหุ้มข้อมูลเกี่ยวกับสถานะของวัตถุในขณะที่ในบางเวลา ถ้าฉันขอให้ระบบดูไฟล์และให้FileInfoวัตถุที่เกี่ยวข้องกับขนาดของมันฉันคาดหวังว่าวัตถุนั้นจะรายงานขนาดของไฟล์ในเวลาที่มีการร้องขอ (หรือเพื่อให้แม่นยำมากขึ้นขนาดของ ไฟล์ในบางช่วงเวลาระหว่างที่มีการโทรออกและเมื่อมันกลับมา) หากขนาดของไฟล์เปลี่ยนแปลงระหว่างเวลาที่คำขอส่งคืนและเวลาที่FileInfoตรวจสอบวัตถุฉันจะไม่คาดหวังว่าการเปลี่ยนแปลงดังกล่าวจะปรากฏในFileInfoวัตถุ

โปรดทราบว่าพฤติกรรมนี้จะแตกต่างอย่างมากจากFileวัตถุ หากการร้องขอให้เปิดไฟล์ดิสก์ในโหมดที่ไม่ผูกขาดให้Fileวัตถุที่มีSizeคุณสมบัติฉันคาดหวังว่าค่าที่ส่งคืนจะเปลี่ยนดังนั้นเมื่อขนาดของไฟล์ดิสก์เปลี่ยนแปลงเนื่องจากFileวัตถุไม่เพียงแสดงสถานะของ ไฟล์ - มันหมายถึงไฟล์ที่ตัวเอง

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

เมื่อพิจารณาถึงอุปกรณ์จริง (เซ็นเซอร์และตัวรับสัญญาณ) เป็นสิ่งหนึ่งและการเป็นตัวแทนของพวกเขาในซอฟต์แวร์นั้นเป็นอีกสิ่งหนึ่ง

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

ฉันไม่ชอบความแตกต่างนี้ วัตถุทั้งหมดคือ "การแสดง [s] ในซอฟต์แวร์" นั่นคือความหมายของคำว่า "วัตถุ"

ตอนนี้มันอาจจะเหมาะสมที่จะแยกข้อมูลเกี่ยวกับอุปกรณ์ต่อพ่วงออกจากรหัสจริงที่เชื่อมต่อกับอุปกรณ์ต่อพ่วง ตัวอย่างเช่นเซ็นเซอร์มี SensorInfo ซึ่งประกอบด้วยตัวแปรอินสแตนซ์ส่วนใหญ่พร้อมกับวิธีการบางอย่างที่ไม่ต้องการฮาร์ดแวร์ในขณะที่คลาสเซ็นเซอร์มีหน้าที่รับผิดชอบในการโต้ตอบกับเซ็นเซอร์จริง คุณไม่จำเป็นต้อง-A Sensorเว้นแต่คอมพิวเตอร์ของคุณมีเซ็นเซอร์ SensorInfoแต่คุณอาจจะมีเหตุผล-A

ปัญหาคือการออกแบบประเภทนี้สามารถทำให้เป็นมาตรฐาน (เกือบ) คลาสใดก็ได้ ดังนั้นคุณต้องระวัง เห็นได้ชัดว่าคุณจะไม่ได้SensorInfoInfoเรียน และถ้าคุณมีSensorตัวแปรคุณอาจพบว่าตัวเองละเมิดกฎหมายของ Demeterโดยโต้ตอบกับSensorInfoสมาชิก สิ่งนี้ไม่เป็นอันตราย แต่การออกแบบ API ไม่ได้มีไว้สำหรับผู้เขียนห้องสมุดเท่านั้น หากคุณรักษา API ของคุณให้สะอาดและเรียบง่ายโค้ดของคุณจะรักษาได้ดีกว่า

ทรัพยากรระบบไฟล์เช่นไดเรกทอรีในความคิดของฉันอยู่ใกล้กับขอบนี้มาก มีบางสถานการณ์ที่คุณต้องการอธิบายถึงไดเรกทอรีที่ไม่สามารถเข้าถึงได้ในพื้นที่จริง แต่นักพัฒนาโดยเฉลี่ยอาจไม่ได้อยู่ในสถานการณ์เหล่านั้น ความซับซ้อนของโครงสร้างชั้นเรียนในแบบนี้คือในความคิดของฉันไม่ช่วยเหลือ Contrast Python เข้าใกล้pathlib: มีคลาสเดียวที่ "น่าจะเป็นสิ่งที่คุณต้องการ" และคลาสเสริมต่าง ๆ ซึ่งผู้พัฒนาส่วนใหญ่สามารถเพิกเฉยได้อย่างปลอดภัย หากคุณต้องการพวกเขาจริงๆพวกเขาให้อินเตอร์เฟซเดียวกันส่วนใหญ่เพียงแค่มีวิธีการที่เป็นรูปธรรม

ฉันจะบอกว่าบริบท / โดเมนมีความสำคัญเนื่องจากเรามีรหัสตรรกะทางธุรกิจระดับสูงและโมเดลระดับต่ำส่วนประกอบสถาปัตยกรรมและอื่น ๆ ...

'Info', 'Data', 'Manager', 'Object', 'Class', 'Model', 'Controller' เป็นต้นสามารถส่งต่อท้ายโดยเฉพาะอย่างยิ่งในระดับที่ต่ำกว่าเนื่องจากวัตถุทุกชิ้นมีข้อมูลหรือข้อมูลดังนั้น ข้อมูลนั้นไม่จำเป็น

ชื่อคลาสของโดเมนธุรกิจควรเป็นเหมือนที่ผู้มีส่วนได้ส่วนเสียทุกคนพูดถึงไม่ว่าจะฟังดูแปลกหรือเป็นภาษาที่ไม่ถูกต้อง 100%

ส่วนต่อท้ายที่ดีสำหรับโครงสร้างข้อมูลเช่น 'รายการ', 'แผนที่' และสำหรับรูปแบบที่บอกใบ้ 'มัณฑนากร', 'อะแดปเตอร์' หากคุณคิดว่าจำเป็น

สถานการณ์เซ็นเซอร์ของคุณผมจะไม่คาดหวังSensorInfoที่จะบันทึกสิ่งที่เซ็นเซอร์ของคุณมี SensorSpecแต่ Infoimho เป็นข้อมูลที่ได้รับมามากกว่าเช่นFileInfoเดียวกับขนาดคุณไม่ได้บันทึกหรือไฟล์พา ธ ที่สร้างจากพา ธ และชื่อไฟล์ ฯลฯ

จุดอื่น:

มีเพียงสองสิ่งที่ยากในวิทยาการคอมพิวเตอร์คือ: การตรวจสอบแคชและการตั้งชื่อสิ่ง

- ฟิลคาร์ลตัน

มันทำให้ฉันนึกถึงชื่อเพียงไม่กี่วินาทีและถ้าฉันไม่พบชื่อใดฉันก็ใช้ชื่อแปลก ๆ และ 'todo'- ทำเครื่องหมายไว้ ฉันสามารถเปลี่ยนได้ในภายหลังเนื่องจาก IDE ของฉันให้การสนับสนุนการปรับโครงสร้างใหม่ มันไม่ใช่สโลแกนของ บริษัท ที่ต้องดี แต่แค่บางรหัสที่เราสามารถเปลี่ยนได้ทุกครั้งที่เราต้องการ เก็บไว้ในใจ

ThingInfo สามารถใช้เป็นพร็อกซีสำหรับอ่านอย่างเดียวที่ยอดเยี่ยม

ดูhttp://www.dofactory.com/net/proxy-design-pattern

พร็อกซี: "ระบุตัวแทนหรือตัวยึดสำหรับวัตถุอื่นเพื่อควบคุมการเข้าถึง"

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

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

จนถึงขณะนี้ไม่มีใครในคำถามนี้ดูเหมือนจะได้รับเหตุผลที่แท้จริงสำหรับการตั้งชื่อนี้

DirectoryInfoไม่ไดเรกทอรี มันเป็นDTO ที่มีข้อมูลเกี่ยวกับไดเรกทอรี อาจมีหลายอินสแตนซ์ที่อธิบายถึงไดเรกทอรีเดียวกัน มันไม่ได้เป็นนิติบุคคล มันเป็นวัตถุที่มีค่าทิ้ง A ไม่ได้แสดงถึงไดเรกทอรีจริง คุณสามารถคิดว่ามันเป็นจุดจับหรือตัวควบคุมสำหรับไดเรกทอรีDirectoryInfo

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

มีตัวอย่างจริงใน BCL ที่มีคลาสทั้งสองอยู่: A ServiceControllerเป็นคลาสที่อธิบายบริการของ Windows สามารถมีคอนโทรลเลอร์จำนวนเท่าใดก็ได้สำหรับแต่ละบริการ A ServiceBase(หรือคลาสที่ได้รับ) เป็นบริการจริงและไม่เข้าใจว่ามีหลายอินสแตนซ์ต่อบริการที่แตกต่างกัน