วัตถุต้องแสดงถึงนิติบุคคลหรือไม่

โดยนิติบุคคลที่ผมหมายถึงสิ่งที่ชอบProduct, Motorเป็นParkingLotฯลฯ ทางกายภาพหรือแม้กระทั่งวัตถุแนวคิดที่ชัดเจนไม่ใช่ทางกายภาพ - บางสิ่งบางอย่างที่กำหนดไว้อย่างดีกับข้อมูลหลักบางอย่างชัดเจนที่อยู่ในวัตถุและบางฟังก์ชั่น / วิธีการ ที่ทำงานอย่างชัดเจนกับข้อมูลหลัก

ตัวอย่างเช่นฉันสามารถมีวัตถุของ a Demon, นิติบุคคลในตัวเองหนึ่งในจินตนาการและอาจไม่ใช่ทางกายภาพ แต่ยังคงเป็นนิติบุคคล

วัตถุสามารถเป็นเพียงชุดของวิธีการชุดของขั้นตอนทั่วไปที่เชื่อมโยงกับเป้าหมายทั่วไปได้หรือไม่

ตัวอย่าง: สามารถเรียกคลาสได้MotorOperationsหรือMotorActionsในกรณีที่ไม่มีเอนทิตี แต่วิธีการภายในคลาสสามารถทำสิ่งต่าง ๆ ได้

• getMotorDataFromHTMLForm ()
• getMotorManufacturers ()
• selectMotorFromUserRequirements ($ ต้องการ)
• canMotorCanHandleOperatingConditions ($ เงื่อนไข)
• computePowerConsumptionForMotor ($ ID)

โดยทั่วไปคลาสจะถูกกำหนดให้เป็นศูนย์กลางข้อมูลของการดำเนินการกับออบเจ็กต์ + กับข้อมูล ดังนั้นสำหรับ a Motorอาจมีตัวแปรยนต์บางอย่างที่เกี่ยวข้องกับข้อมูลจำเพาะของมอเตอร์และอาจมีการดำเนินการที่รวมข้อมูลเหล่านั้นเพื่อสร้างบางสิ่งบางอย่าง

ในกรณีของฉันมันเหมือนกับว่าฉันมีคลาสที่มีการดำเนินงานเกี่ยวกับ data + data ที่ส่งผ่านคลาสไม่มี data centric สำหรับ "Motor Operations" นอกเหนือจากข้อมูลชั่วคราวที่ส่งผ่านคลาส

คำถาม

คลาสสามารถเป็นตัวแทนวัตถุที่ไม่ใช้เอนทิตี้ได้หรือไม่? ถ้าไม่ทำไมพวกเขาถึงไม่ดี / ไม่สมบูรณ์ / ไม่ใช่ OOP-centric? มีวิธีที่พวกเขาจำเป็นต้องเปลี่ยน / ปรับปรุงแนวคิดเพื่อให้สอดคล้องกับ OOP หรือไม่?

ไม่วัตถุไม่จำเป็นต้องแสดงถึงเอนทิตี

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

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

วัตถุเกี่ยวกับข้อความ พวกเขาเกี่ยวกับความรับผิดชอบ พวกเขาไม่ได้เกี่ยวกับรถยนต์ผู้ใช้หรือคำสั่งซื้อ

ฉันรู้ว่าเราสอน OO ด้วยวิธีนี้ แต่มันจะปรากฏให้เห็นชัดเจนหลังจากพยายามสักสองสามครั้งว่าวิธีที่น่าผิดหวังก็คือการรู้ว่าสิ่งต่าง ๆ เกิดขึ้นเมื่อคุณพยายามทำ MVC, MVVM หรือ MVWhething ไม่ว่าแบบจำลองของคุณจะกลายเป็นเรื่องน่าขันหรือตัวควบคุมของคุณทำ สำหรับการนำทางคุณควรรู้ว่าทุกสิ่งที่แตะยานพาหนะอยู่ในไฟล์ Vehicle.ext แต่เมื่อแอปพลิเคชันของคุณเกี่ยวกับยานพาหนะคุณจะต้องจบลงด้วยเส้นสปาเก็ตตี้ 3000 เส้นในไฟล์นั้น

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

มาพูดถึงฟังก์ชั่นถุงกัน

วัตถุอาจเป็นเพียงชุดของวิธีการและยังคงเป็น OO แต่"กฎ" ของฉันค่อนข้างเข้มงวด

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

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

3. วัตถุควรทำงานกับข้อมูล "ชนิด" เดียวกัน วัตถุนี้ทำสิ่งต่าง ๆ ให้กับมอเตอร์ (สตาร์ท / หยุด) อันนี้ทำสิ่งที่มีความยาวข้อเหวี่ยงอันนี้จัดการการเรียงลำดับการจุดระเบิดอันนี้ใช้รูปแบบ html ข้อมูลนี้อาจเป็นฟิลด์บนวัตถุและดูเหมือนจะเหนียวแน่น

โดยทั่วไปฉันสร้างวัตถุประเภทนี้เมื่อฉันแปลงแปลงแต่งหรือไม่ต้องการกังวลเกี่ยวกับความไม่แน่นอน

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

วัตถุเกี่ยวกับข้อความ

ฟิลด์แทบไม่สำคัญกับวัตถุ - การรับและการตั้งค่าการลงทะเบียนจะไม่เปลี่ยนแปลงโลกภายนอกโปรแกรม การร่วมมือกับวัตถุอื่น ๆ จะทำให้งานสำเร็จ อย่างไรก็ตามจุดแข็งของ OO คือเราสามารถสร้าง abstractions ดังนั้นเราไม่ต้องคิดเกี่ยวกับรายละเอียดทั้งหมดในครั้งเดียว บทคัดย่อที่การรั่วไหลหรือไม่สมเหตุสมผลนั้นเป็นปัญหาดังนั้นเราจึงคิดอย่างลึกซึ้ง (มากเกินไป) เกี่ยวกับการสร้างวัตถุที่ตรงกับแบบจำลองทางจิตของเรา

คำถามสำคัญ: ทำไมวัตถุทั้งสองนี้จึงต้องพูดคุยกัน

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

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

ดังนั้นในวันนี้ ( ง่าย ) ตัวอย่างเช่นวัตถุต่อมหมวกไตเพียงต้องการที่จะรู้วิธีการใช้ ACTH และทำให้ตื่นเต้น มันไม่ต้องการฟิลด์ใด ๆ เพื่อทำสิ่งนั้น แต่มันก็ยังดูเหมือนว่าเป็นวัตถุสำหรับฉัน

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

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

ในระยะสั้นคุณสามารถทำอะไรก็ได้ แต่สถานการณ์เฉพาะนี้จะขัดกับหลักการ OOP :)

สิ่งที่คุณกำลังอธิบายบางครั้งเรียกว่าคลาส "ยูทิลิตี้" - โดยปกติจะเป็นสัญญาณของรหัสกลิ่น คุณต้องการหลีกเลี่ยงการสร้างคลาสเพื่อรักษาวิธีการบางอย่างเข้าด้วยกัน

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

คุณควรมีลักษณะที่เป็นรูปแบบสถาปัตยกรรมร่วมกัน - หนึ่งในนั้นคือMVC (Model-View-Controller)

ถ้าฉันจะเผยแพร่วิธีการที่คุณระบุไว้โดยใช้ MVC นี่คือสิ่งที่ฉันจะทำ:

ดูคลาส:

• GetMotorDataFromHTMLForm ()

รุ่นคลาส (มอเตอร์เป็นหลัก):

• GetMotorManufacturer ()
• CanMotorHandleOperationConditions ()
• CalculatePowerConsumption ()

คลาสควบคุม (มอเตอร์ควบคุม):

• GetAllMotors ()
• GetMotorById ()
• GetMotorByUserRequirements ()

ดูเหมือนว่าคุณกำลังใช้ PHP; กรอบ MVC ดีที่จะมีรูปลักษณ์ที่เป็นLaravel ในตัวอย่างของพวกเขาพวกเขาแสดงให้เห็นถึงวิธีการที่ดี

อีกแหล่งข้อมูลทั่วไปเพิ่มเติมวิธีการตัดสินใจที่เป็นวิธีการที่เป็นหลักการGRASPและSOLID

คลาสสามารถเป็นตัวแทนวัตถุที่ไม่ใช้เอนทิตี้ได้หรือไม่?

สามารถ? ใช่. ควร? อาจไม่ใช่ - หรืออย่างน้อยไม่ใช่วิธีที่คุณใช้ถ้อยคำ

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

เพียงการรวมกลุ่มของฟังก์ชั่นที่เกี่ยวข้องกันเป็นกลุ่มเป็น namespace หรือโมดูล - ไม่ใช่วัตถุใน OOP parlance สิ่งเหล่านั้นมีประโยชน์ แต่ก็ไม่เหมือนกันและต้องการการใช้งาน / การคิดที่แตกต่างเพื่อทำงานด้วยอย่างมีประสิทธิภาพ

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

ขอให้โชคดี

ไม่ (มีการแก้ไขชื่อเพื่อถามคำถามตรงข้าม!)

เช่น:

Public class MyRepository
{
    public MyObject GetObject(string id)
    {
        //get data from the DB and build an object
    }
}

หรือ

Public class MyService
{
    public MyObject3 ProcessData(MyObject1 obj1, MyObject2 obj2)
    {
         //perform a process which is not a sole responsiblity of obj1 or obj2
    }
}

อย่างไรก็ตามโดยทั่วไปแล้วอุดมคติเบื้องหลังของ OOP คือการย้ายออกไป

public struct Car
{
    public Wheel[] Wheels;
}

public int CountWheelsOnCar(MyCarStruct car)
{
   return car.Wheels.Length;
}

ไปยัง

public class Car
{
    private Wheel[] wheels;
    Public int CountWheels()
    {
        return this.wheels.Length;
    }
}

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

ในความเป็นจริงขึ้นอยู่กับว่าคุณต้องการเป็นตัวอักษรหรือไม่วัตถุหลายอย่างที่เราทำงานด้วยไม่มีการเป็นตัวแทนทางกายภาพเลย ตัวอย่างเช่น - พิจารณาสถาปัตยกรรม MVC ในโลกแห่งความเป็นจริงไม่มี Model หรือ Controller แม้ว่าโดยทั่วไปแล้วจะมีชั้นเรียนเป็นตัวแทน สามคนด้วยกันมักจะเป็นตัวแทนของบางสิ่ง แต่ไม่เสมอไป - แต่อย่างที่ฉันบอกว่าคุณอาจบังคับให้เข้ากับบางสิ่งได้หากคุณต้องการ (และสามารถจินตนาการถึงสิ่งที่จะช่วยได้! ฉันเห็นภาพวัตถุส่วนใหญ่ในทางใดทางหนึ่ง คุณเคยเห็นในโลกแห่งความจริง)

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

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

วัตถุต้องแสดงถึงนิติบุคคลหรือไม่

คำถาม: นิติบุคคลใดที่เป็นLoggerตัวแทน?

ไม่เชิงอุปมา - อย่างแท้จริง

เมื่ออธิบาย OOP ให้กับนักเรียนจะเป็นประโยชน์ในการอธิบายวัตถุที่มีการเปรียบเทียบกับโลกทางกายภาพ

Alan Kay - หนึ่งในบรรพบุรุษของOOP - เขียนสิ่งต่อไปนี้:

[ ... ]

แนวคิดดั้งเดิมของมันมีส่วนต่าง ๆ ดังต่อไปนี้

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

[ ... ]

OOP สำหรับฉันหมายถึงเฉพาะการส่งข้อความการเก็บรักษาในท้องถิ่นและการป้องกันและ

การซ่อนกระบวนการของรัฐและการผูกมัดปลายสุดของทุกสิ่ง

สถาปัตยกรรม HW แทบไม่น่าเชื่อ ฉันตระหนักว่า

การเปรียบเทียบเซลล์ / ทั้งคอมพิวเตอร์จะกำจัดข้อมูล

แหล่ง

จากนี้เป็นวัตถุที่เข้าใจดีที่สุดว่า

• วัตถุ autarkic encapsulating / ซ่อนข้อมูล

• การสื่อสารกับวัตถุอื่นผ่านข้อความ

คลาสสามารถเป็นตัวแทนวัตถุที่ไม่ใช้เอนทิตี้ได้หรือไม่?

แน่นอน: คิดถึง Math

เกี่ยวกับตัวอย่างของคุณ:

ตัวอย่าง: คลาสสามารถเรียกว่า MotorOperations หรือ MotorActions โดยที่ไม่มีเอนทิตี แต่วิธีการภายในคลาสทำสิ่งต่าง ๆ เช่น

• getMotorDataFromHTMLForm ()

• getMotorManufacturers ()

• selectMotorFromUserRequirements ($ ต้องการ)

• canMotorCanHandleOperatingConditions ($ เงื่อนไข)

• computePowerConsumptionForMotor ($ ID)

การตัดสินใจที่จะนำวิธีการเหล่านี้คุณต้องใช้เวลาดูที่responsibilities: ที่เป็น respnsible สำหรับสิ่งที่

getMotorDataFromHTMLForm ()

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

getMotorManufacturers ()

serviceบริบททั่วไปในที่หนึ่งที่จะเขียนวิธีการดังกล่าวเป็น

selectMotorFromUserRequirements ($ ต้องการ)

สิ่งนี้จะถูกนำมาใช้ใน - serviceเนื้อหา

canMotorCanHandleOperatingConditions ($ เงื่อนไข)

นี่เป็นคำถามสำหรับmotor-object

computePowerConsumptionForMotor ($ ID)

นี่ก็เป็นคำถามที่ดีที่สุดถามตัวเองมอเตอร์

TL; DR

อุปมาของobjectsเป็นวัตถุทางร่างกายคือเกิดการระคายเคืองมากขึ้นกว่าที่เป็นประโยชน์

ใช่คุณสามารถทำได้ แต่คุณจะต้องสร้างคลาสเพื่อให้มีฟังก์ชั่นเช่นเดียวกับไลบรารีขั้นตอน เหตุผลเดียวที่ต้องทำคือถ้าภาษาของคุณขาดโมดูลขั้นตอน (เช่น Java หรือ Ruby)

ในภาษาที่มีโมดูลโพรซีเดอร์ (ฉันคิดว่า PHP มีโมดูลโพรซีเดอร์) คุณอาจพิจารณาใช้โมดูลโพรซีเดอร์

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

แต่ใช้สัญกรณ์ OO เฉพาะเมื่อมันให้พลังพิเศษแก่คุณไม่ใช่เพื่อประโยชน์ในการเป็น OO!

ในคำพูดของคนธรรมดา

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

คลาสดังกล่าวมีอยู่ตัวอย่างเช่น Java SDK มีคลาส Collections ซึ่งประกอบด้วยวิธีคงที่เท่านั้นที่ทำงานบนหรือส่งคืนคอลเลกชัน

ดังนั้นคำตอบจะไม่ใช่ไม่ทุกคลาสจำเป็นต้องจำลองจากเอนทิตีโดเมน

ในทางตรงกันข้ามคลาสดังกล่าวมีเพียงไม่กี่หรือควรจะมีเพียงไม่กี่ในโปรแกรมที่ทำในภาษา OOP เนื่องจากพลังที่แท้จริงของ OOP วางใน polymorphism และ encapsulation

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

ไม่คลาสเพียงแสดงบางสิ่งที่สามารถยกตัวอย่างมีสมาชิกและสามารถสืบทอดได้

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

.NET'sMathเป็นตัวอย่างที่ยอดเยี่ยมของคลาส "มืออาชีพ" ที่เป็นตัวแทนของเอนทิตี (เว้นแต่คุณต้องการได้รับปรัชญาเกี่ยวกับคณิตศาสตร์คืออะไร) และยังเกิดขึ้นเพื่อแสดงให้เห็นถึงกรณีการใช้งานที่ถูกกฎหมายของคลาสนั้น มันมีเพียงวิธีการและ 2 เขตข้อมูล

ลำดับชั้นของชั้นเรียนของห้องสมุดที่คล้ายกันMath.Netจัดกลุ่มวิธีการทางคณิตศาสตร์ / ตัวเลขลงในชั้นเรียนตามประเภท ชั้นเรียนที่นี่ไม่ได้เป็นตัวแทน แต่เป็นหมวดหมู่ตรรกะ

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

ท้ายที่สุดคำตอบสำหรับคำถามของคุณจะขึ้นอยู่กับว่าคำจำกัดความเช่น "class" และ "เอนทิตี" นั้นแม่นยำเพียงใด คุณทำงานได้ดีในการกำหนดสิ่งหลังซึ่งอนุญาตทั้งเอนทิตีทางกายภาพและแนวคิด แต่คำว่า "คลาส" สำหรับผู้ที่พิถีพิถันมักจะเป็น "โรงงานสำหรับอินสแตนซ์ของวัตถุที่มีการเป็นตัวแทนภายในเฉพาะ" และสำหรับนักปฏิบัติก็จะรวมถึงสิ่งที่ Java หรือ C ++ ดูถูกโดยนักปราชญ์ เหมือนกันสำหรับคำว่า "OOP" ซึ่งนักปฏิบัตินิยมอาจบอกว่า Java และ C ++ ทำ แต่นักที่จะใช้หมายถึงสิ่งที่ Alan Kay หมายถึงเมื่อเขาพูดถึง ["ฉันคิดค้นคำศัพท์เชิงวัตถุและฉันสามารถบอกคุณได้ว่าฉันไม่ได้ มี C ++ อยู่ในใจ "] ( ดังนั้น * Alan * หมายถึงอะไรโดยคำว่า" object-oriented "? )

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

คลาสสามารถเป็นตัวแทนวัตถุที่ไม่ใช้เอนทิตี้ได้หรือไม่?

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

ถ้าไม่ทำไมพวกเขาถึงไม่ดี / ไม่สมบูรณ์ / ไม่ใช่ OOP-centric?

พวกเขาไม่ได้เลวร้าย อย่าเรียกพวกเขาว่าคลาส มัดของวิธีการคือ OOPable: สิ่งที่คุณสามารถส่งข้อความไปเพื่อที่จะเรียกใช้วิธีการ แต่มันไม่ได้เป็นชั้นเรียนเว้นแต่จะสามารถยกตัวอย่างวัตถุ คุณรู้จักรูบี้หรือไม่ ใน Ruby โมดูลเป็นกลุ่มของวิธีการ ระดับเป็นโมดูลที่สามารถยกตัวอย่างวัตถุ ไม่มีอะไรที่ไม่ดีเกี่ยวกับโมดูลคือ แต่สิ่งที่ทำให้คลาสแตกต่างจากโมดูล (ในเงื่อนไข OOP บริสุทธิ์) คือคลาสสามารถมีอินสแตนซ์ โมดูลเป็นเพียงวิธีการบางอย่าง ความสับสนคือ C ++ และ Java และภาษาอื่น ๆ ใช้คำว่า "คลาส" สำหรับทั้งการเรียนและโมดูล

ตอนนี้ไปดูที่หนึ่งในตัวอย่างของคุณโดยเฉพาะคุณถามเกี่ยวกับMotorOperationsระดับที่คุณสามารถส่งข้อความที่มีการโต้แย้งcomputePowerConsumptionForMotor idมันแย่ใช่ไหม อย่างน้อยก็ไม่ละเมิดบอกอย่าถามหลักการ เราต้องสร้างคลาสยนต์และส่งpowerConsumptionข้อความหรือไม่ อาจไม่ใช่ 100% ของเวลา แต่อาจพยายามทำสิ่งต่าง ๆ จะนำไปสู่ความเข้าใจที่ดีเกี่ยวกับรหัสของคุณ หรืออาจนำไปสู่การระเบิดของชนชั้นน้อยซึ่งจะไม่ดี

มีวิธีที่พวกเขาจำเป็นต้องเปลี่ยน / ปรับปรุงแนวคิดเพื่อให้สอดคล้องกับ OOP หรือไม่?

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

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

TL; DR - บันเดิลเมธอดไม่ได้เลวร้ายเสมอไป ลองใช้คลาสที่สามารถใช้งานได้ทันทีก่อน ถอยกลับไปที่ "โมดูล" เมื่อจำเป็นเท่านั้น

ยกตัวอย่างที่ได้รับ:

getMotorDataFromHTMLForm()
selectMotorFromUserRequirements($requirements)

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

getMotorManufacturers()

คุณรับจากที่ไหน นั่นคือสิ่งที่ควรเป็นวิธี

canMotorCanHandleOperatingConditions($conditions)
computePowerConsumptionForMotor($id)

ดูเหมือนว่าพวกเขาควรจะมีวิธีการMotorเหล่านี้

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

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

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

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