เหตุใดฉันจึงเห็นชั้นเรียนที่เปิดใช้งานได้จำนวนมากโดยไม่มีรัฐ

ฉันเห็นคลาสที่สามารถใช้งานได้ทันทีจำนวนมากในโลก C ++ และ Java ที่ไม่มีสถานะใด ๆ

ฉันไม่สามารถเข้าใจได้ว่าทำไมผู้คนถึงทำอย่างนั้นพวกเขาสามารถใช้เนมสเปซที่มีฟังก์ชั่นฟรีใน C ++ หรือคลาสที่มีคอนสตรัคเตอร์ส่วนตัวและวิธีการคงที่ใน Java เท่านั้น

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

ฉันได้รับสิ่งนี้ผิดหรือเปล่า? ไม่ใช่ OOP หากฉันไม่ใส่ทุกสิ่งลงในวัตถุ (เช่นคลาสที่สร้างอินสแตนซ์)? แล้วทำไมมีเนมสเปซและคลาสยูทิลิตี้มากมายในไลบรารีมาตรฐานของ C ++ และ Java

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

ฉันเห็นคลาสที่สามารถใช้งานได้ทันทีจำนวนมากในโลก C ++ และ Java ที่ไม่มีสถานะใด ๆ

เหตุผลที่เป็นไปได้บางอย่างในการสร้างคลาสโดยไม่มี ivars ของตนเอง:

• สถานะเป็นหรืออาจมีอยู่ในซูเปอร์คลาส

• คลาสใช้อินเทอร์เฟซบางอย่างและจำเป็นต้องมีในทันทีเพื่อให้อินสแตนซ์สามารถส่งผ่านไปยังวัตถุอื่น

• คลาสมีวัตถุประสงค์เพื่อเป็นคลาสย่อย

• วิธีที่สะดวกในการจัดกลุ่มฟังก์ชั่นที่เกี่ยวข้อง (ใช่อาจมีวิธีที่ดีกว่าหรือแตกต่างกันในการทำเช่นเดียวกัน)

ฉันได้รับสิ่งนี้ผิดหรือเปล่า? ไม่ใช่ OOP หากฉันไม่ใส่ทุกสิ่งลงในวัตถุ (เช่นคลาสที่สร้างอินสแตนซ์)?

OOP เป็นกระบวนทัศน์ไม่ใช่กฎแห่งธรรมชาติ มีบางภาษาที่ทุกอย่างเป็นวัตถุดังนั้นคุณจึงไม่มีทางเลือก ภาษาอื่น ๆ (เช่น C) ไม่ได้ให้การสนับสนุนใด ๆ สำหรับ OOP เลย แต่คุณยังสามารถตั้งโปรแกรมในลักษณะเชิงวัตถุได้ ฉันว่าคุณสามารถมี OOP ได้ถ้าคุณไม่ทำทุกอย่างในคลาส ... คุณอาจบอกว่าคุณมีOOP น้อยลงในกรณีนี้

Caleb และ Robert Harvey ได้ชี้ให้เห็นแล้วว่าคลาสยูทิลิตี้คืออะไรและมีเหตุผลที่ถูกต้องสำหรับการมีคลาส "data-less" คำอธิบายเหล่านั้นเป็นจุดบน แต่จัดการกับด้านบวก

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

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

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

คลาสยูทิลิตี้ใน Java และ C ++ ใช้เพื่อดูแลไลบรารีของเมธอดที่รับพารามิเตอร์อินพุตตั้งแต่หนึ่งพารามิเตอร์ขึ้นไปและส่งคืนผลลัพธ์ พวกเขาไม่จำเป็นต้องถือสถานะหากพวกเขาเพียงแค่คืนค่า ในแง่ที่ว่าวิธีการเหล่านี้สามารถถือเป็นรูปแบบหยาบของการเขียนโปรแกรมการทำงานด้วยข้อดีทั้งหมดของมัน (ไม่มีปัญหากับการเกิดพร้อมกันสำหรับสิ่งหนึ่ง)

ไม่ว่าในกรณีใดคลาสเหล่านี้จะทำหน้าที่จัดกลุ่มวิธีการที่เกี่ยวข้องกันในที่เก็บเดียววิธีการที่ไม่ต้องการการสร้างอินสแตนซ์ของวัตถุให้ทำงานอย่างถูกต้อง ตัวอย่างของคลาสดังกล่าวคือคลาสคณิตศาสตร์ที่มีฟังก์ชัน SINE และ COSINE (และคณิตศาสตร์อื่น ๆ )

คลาสเหล่านั้นจำนวนมากโต้ตอบกับข้อมูลแม้ว่าจะไม่ได้มีอยู่อย่างชัดเจนและจำเป็นต้องทำเช่นนั้นด้วยวิธีที่ต้องการอินสแตนซ์หลายรายการพร้อมกัน เช่นเซสชั่นไร้สัญชาติ bean ที่ตอบสนองกับโพรซีเดอร์ที่เก็บฐานข้อมูลส่งผ่านข้อมูลขาเข้าไปยังแพ็คเกจ PL / SQL และส่งผลลัพธ์กลับไปยังแอปพลิเคชันที่เรียก สิ่งนั้นจำเป็นต้องมีอยู่ในหลาย ๆ กรณี แต่ไม่มีเขตข้อมูลใด ๆ

ในภาษาเชิงวัตถุที่คลาสไม่ได้เป็นวัตถุคุณสามารถทำสิ่งต่าง ๆ ได้มากกว่าวัตถุ

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

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