การตั้งชื่อส่วนต่อประสานใน Java [ปิด]

ภาษา OO ส่วนใหญ่นำหน้าชื่ออินเตอร์เฟสด้วยตัวพิมพ์ใหญ่ I ทำไม Java ไม่ทำเช่นนี้? อะไรคือเหตุผลที่ไม่ปฏิบัติตามอนุสัญญานี้

เพื่อแสดงให้เห็นถึงสิ่งที่ฉันหมายถึงถ้าฉันต้องการที่จะมีส่วนติดต่อผู้ใช้และการใช้งานของผู้ใช้ฉันมีสองตัวเลือกใน Java:

1. Class = ผู้ใช้ส่วนต่อประสาน = UserInterface
2. Class = UserImpl, Interface = ผู้ใช้

ที่ไหนในภาษาส่วนใหญ่:

Class = ผู้ใช้ส่วนต่อประสาน = IUser

ตอนนี้คุณอาจยืนยันว่าคุณสามารถเลือกชื่อที่สื่อความหมายได้มากที่สุดสำหรับการใช้งานของผู้ใช้และปัญหาจะหายไป แต่ Java ของการผลักดันวิธี POJO กับสิ่งต่าง ๆ และคอนเทนเนอร์ IOC ส่วนใหญ่ใช้ DynamicProxies อย่างกว้างขวาง สองสิ่งเหล่านี้เข้าด้วยกันหมายความว่าคุณจะมีอินเทอร์เฟซมากมายกับการใช้งาน POJO เดียว

ดังนั้นฉันเดาว่าคำถามของฉันจะลดลงไปที่: "มันคุ้มค่าหรือไม่ที่จะต้องปฏิบัติตามระเบียบการตั้งชื่อส่วนต่อประสานที่กว้างขึ้นโดยเฉพาะอย่างยิ่งในที่ที่ Java Frameworks ดูเหมือนจะมุ่งหน้าไปหรือไม่?"

ฉันไม่ต้องการใช้คำนำหน้าบนอินเตอร์เฟส:

• คำนำหน้าเจ็บอ่านง่าย

• การใช้อินเตอร์เฟสในไคลเอนต์เป็นวิธีที่ดีที่สุดในการเขียนโปรแกรมดังนั้นชื่ออินเตอร์เฟสควรสั้นและน่าใช้มากที่สุด การใช้งานคลาสควรเป็นสิ่งที่ไม่ดีเพื่อลดการใช้งาน

• เมื่อเปลี่ยนจากคลาสนามธรรมเป็นอินเตอร์เฟสการเขียนโค้ดด้วยคำนำหน้าฉันหมายถึงการเปลี่ยนชื่อการเกิดขึ้นทั้งหมดของคลาส --- ไม่ดี!

มีความแตกต่างระหว่างจริง ๆ :

class User implements IUser

และ

class UserImpl implements User

ถ้าเรากำลังพูดถึงการตั้งชื่ออนุสัญญา?

โดยส่วนตัวแล้วฉันไม่ต้องการนำหน้าอินเทอร์เฟซด้วยIเพราะฉันต้องการเข้ารหัสให้อินเทอร์เฟซและฉันคิดว่ามันสำคัญกว่าในแง่ของการตั้งชื่อ ถ้าคุณโทรหาอินเตอร์เฟสIUserIUserแล้วผู้บริโภคที่ตอบสนองความต้องการทุกระดับที่จะรู้ว่ามัน ถ้าคุณเรียกชั้นเรียนUserImplแล้วเท่านั้นระดับและภาชนะ DI ของคุณรู้เกี่ยวกับการมีส่วนร่วมและผู้บริโภคเพียงแค่รู้ว่าพวกเขากำลังทำงานร่วมกับImplUser

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

class DbBasedAccountDAO implements AccountDAO
class InMemoryAccountDAO implements AccountDAO

อาจมีหลายสาเหตุที่ Java ไม่ได้ใช้ IUser Convention

1. ส่วนหนึ่งของวิธีการเชิงวัตถุคือคุณไม่ควรรู้ว่าลูกค้ากำลังใช้อินเทอร์เฟซหรือคลาสการใช้งานหรือไม่ ดังนั้นแม้แต่ List คืออินเตอร์เฟสและ String เป็นคลาสจริงวิธีอาจถูกส่งผ่านทั้งสองวิธี - มันไม่สมเหตุสมผลที่จะแยกความแตกต่างระหว่างอินเตอร์เฟส

2. โดยทั่วไปแล้วเราจะชอบการใช้งานอินเทอร์เฟซในรหัสลูกค้า (เช่น List to ArrayList เป็นต้น) ดังนั้นจึงไม่มีเหตุผลที่จะทำให้ส่วนต่อประสานนั้นโดดเด่นเป็นข้อยกเว้น

3. ระเบียบการตั้งชื่อ Java ชอบชื่อที่ยาวกว่าซึ่งมีความหมายตามจริงต่อคำนำหน้าสไตล์ฮังการี ดังนั้นรหัสนั้นจะสามารถอ่านได้มากที่สุด: รายการแสดงถึงรายการและผู้ใช้แทนผู้ใช้ - ไม่ใช่ IUser

นอกจากนี้ยังมีการประชุมอื่นที่ใช้โดยโครงการโอเพ่นซอร์สมากมายรวมถึง Spring

interface User {
}

class DefaultUser implements User {
}

class AnotherClassOfUser implements User {
}

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

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

class Number implements Comparable{...}  
class MyThread implements Runnable{...}
class SessionData implements Serializable{....}

บางครั้งคำคุณศัพท์ไม่สมเหตุสมผล แต่โดยทั่วไปแล้วฉันยังคงใช้อินเทอร์เฟซสำหรับลักษณะการทำงานแบบจำลองการกระทำความสามารถคุณสมบัติ ฯลฯ ... ไม่ใช่ประเภท

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

ฉันคิดว่าตัวอย่างที่เป็นจริงมากขึ้นคือผู้ใช้บางประเภทต้องสามารถลงชื่อเข้าใช้ API เฉพาะ เราสามารถกำหนดอินเทอร์เฟซการเข้าสู่ระบบแล้วมีคลาส "ผู้ใช้" กับ SuperUser, DefaultUser, AdminUser, AdministrativeContact ฯลฯ suclasses ซึ่งบางส่วนจะหรือไม่ใช้อินเทอร์เฟซการเข้าสู่ระบบ (Loginable?) ตามความจำเป็น

บ๊อบลีกล่าวอีกครั้งหนึ่งในการนำเสนอ:

จุดอินเทอร์เฟซคืออะไรถ้าคุณมีการนำไปใช้เพียงครั้งเดียว

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

จากนั้นจะชัดเจน: คลาสดั้งเดิมของคุณถูกเรียกว่าผู้ใช้ ส่วนต่อประสานของคุณตอนนี้เรียกว่าผู้ใช้ บางทีคุณอาจมี UserProdImpl และ UserTestImpl หากคุณออกแบบแอปพลิเคชันของคุณได้ดีทุกคลาส (ยกเว้นแอพที่สร้างอินสแตนซ์ผู้ใช้) จะไม่เปลี่ยนแปลง

เพื่อให้ชัดเจน -> การปรับใช้ User Interface UserImpl

ใน C # มันคือ

public class AdminForumUser : UserBase, IUser

Java จะพูดว่า

public class AdminForumUser extends User implements ForumUserInterface

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

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

ยกตัวอย่างเช่นในกรณีของคุณผมเพียง แต่คาดว่าจะเห็นหากผู้ใช้เท่านั้นที่คุณตั้งใจจะมีคือIUser Userหากคุณวางแผนที่จะมีผู้ใช้หลายประเภท - NoviceUser, ExpertUserและอื่น ๆ - ฉันคาดว่าจะเห็นUserอินเทอร์เฟซ (และบางทีAbstractUserคลาสที่ใช้ฟังก์ชั่นทั่วไปบางอย่างเช่นget/setName() )

ฉันยังอยากจะคาดหวังว่าอินเตอร์เฟซที่กำหนดความสามารถ - Comparable, Iterableฯลฯ - จะตั้งชื่อเช่นนั้นและไม่ชอบหรือIComparableIIterable

ตามหลักการของ OO ที่ดีรหัสของคุณควร (เท่าที่สามารถนำไปใช้ได้จริง / เป็นไปได้) ขึ้นอยู่กับ abstractions มากกว่าคลาสที่เป็นรูปธรรม ตัวอย่างเช่นโดยทั่วไปควรเขียนวิธีดังนี้:

public void doSomething(Collection someStuff) {
    ...
}

กว่านี้:

public void doSomething(Vector someStuff) {
    ...
}

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

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

หากคุณทำเช่นนี้ชื่อคลาสที่ "น่าเกลียด" ที่เป็นรูปธรรมเช่น "UserImpl" ควรถูกซ่อนไว้อย่างปลอดภัยจากรหัสที่เหลือซึ่งสามารถดำเนินการต่อโดยใช้ชื่ออินเตอร์เฟส "nice"

= v = คำนำหน้า "ฉัน" ยังใช้ในกรอบประตูซึ่งฉันคุ้นเคยกับมันอย่างรวดเร็ว โดยทั่วไปฉันยินดีต้อนรับการประชุมใด ๆ ที่ทำให้ชื่อคลาส Java สั้นลง มันเป็นเรื่องยุ่งยากแม้ว่าทุกอย่างจะมีตัวอักษรภายใต้ "ฉัน" ในไดเรกทอรีและใน Javadoc

การเข้ารหัสแบบ Wicket คล้ายกับ Swing ในอินสแตนซ์ควบคุม / วิดเจ็ตจำนวนมากนั้นถูกสร้างเป็นคลาสภายในที่ไม่ระบุชื่อพร้อมการประกาศเมธอดแบบอินไลน์ น่ารำคาญมันแตกต่างจาก Swing ใน 180 °ใน Swing นั้นใช้คำนำหน้า ("J") สำหรับคลาสการใช้งาน

ส่วนต่อท้าย "Impl" เป็นตัวย่อที่มีความละเอียดอ่อนและไม่เป็นสากล ถ้าอย่างน้อยเราก็ไปด้วย "Imp" มันจะน่ารักกว่า (และสั้นกว่า) "Impl" ใช้สำหรับ IOC โดยเฉพาะ Spring ดังนั้นเราจึงติดอยู่กับตอนนี้ ได้รับ schizo เล็กน้อยตาม 3 อนุสัญญาที่แตกต่างกันในสามส่วนที่แตกต่างกันของ codebase หนึ่งแม้ว่า

นี่เป็นรูปแบบการตั้งชื่อที่กว้างขึ้นในแง่ที่แท้จริงหรือไม่? ฉันอยู่ด้าน C ++ มากกว่าและไม่ขึ้นกับ Java และผู้สืบทอด ชุมชนภาษาจำนวนเท่าใดที่ใช้การประชุม I

หากคุณมีแบบแผนการตั้งชื่อมาตรฐานของร้านที่ไม่ขึ้นอยู่กับภาษาที่นี่ให้ใช้ ถ้าไม่ใช่ให้ไปที่แผนการตั้งชื่อภาษา