วิธีที่ดีที่สุดในการกำหนดวิธีการส่วนตัวสำหรับคลาสใน Objective-C

ฉันเพิ่งเริ่มเขียนโปรแกรม Objective-C และมีพื้นหลังใน Java สงสัยว่าคนเขียนโปรแกรม Objective-C จัดการกับวิธีส่วนตัว

ฉันเข้าใจว่าอาจมีอนุสัญญาและนิสัยหลายอย่างและคิดถึงคำถามนี้ในฐานะผู้รวบรวมเทคนิคที่ดีที่สุดที่ผู้คนใช้ในการจัดการกับวิธีการส่วนตัวใน Objective-C

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

สำหรับการค้นพบของฉันจนถึง

เป็นไปได้ที่จะใช้หมวดหมู่ [เช่น MyClass (ส่วนตัว)] ที่กำหนดไว้ในไฟล์ MyClass.m เพื่อจัดกลุ่มวิธีส่วนตัว

วิธีนี้มี 2 ประเด็น:

1. Xcode (และคอมไพเลอร์?) ไม่ได้ตรวจสอบว่าคุณกำหนดวิธีการทั้งหมดในหมวดหมู่ส่วนตัวในบล็อก @implementation ที่สอดคล้องกัน
2. คุณต้องใส่ @interface ประกาศหมวดหมู่ส่วนตัวของคุณในจุดเริ่มต้นของไฟล์ MyClass.m มิฉะนั้น Xcode บ่นกับข้อความเช่น "ตัวเองอาจไม่ตอบสนองต่อข้อความ" privateFoo "

ปัญหาแรกสามารถแก้ไขได้ด้วยหมวดหมู่ที่ว่าง [เช่น MyClass ()]
คนที่สองรบกวนฉันมาก ฉันต้องการที่จะเห็นวิธีการส่วนตัวนำไปใช้ (และกำหนด) ใกล้ถึงจุดสิ้นสุดของไฟล์; ฉันไม่ทราบว่าเป็นไปได้

ไม่มีอย่างที่คนอื่นพูดไปแล้วสิ่งนี้เป็นวิธีส่วนตัวใน Objective-C แต่เริ่มต้นใน Objective-C 2.0 (หมายถึงระบบปฏิบัติการ Mac OS X Leopard, iPhone OS 2.0 และต่อมา) คุณสามารถสร้างหมวดหมู่ที่มีชื่อที่ว่างเปล่า (คือ@interface MyClass ()) เรียกว่าการขยายชั้นเรียน มีอะไรพิเศษเกี่ยวกับการขยายชั้นเรียนคือการใช้งานวิธีการต้องเหมือนกัน@implementation MyClassกับวิธีการสาธารณะ ดังนั้นฉันจึงจัดโครงสร้างคลาสของฉันดังนี้:

ในไฟล์. h:

@interface MyClass {
    // My Instance Variables
}

- (void)myPublicMethod;

@end

และในไฟล์. m:

@interface MyClass()

- (void)myPrivateMethod;

@end

@implementation MyClass

- (void)myPublicMethod {
    // Implementation goes here
}

- (void)myPrivateMethod {
    // Implementation goes here
}

@end

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

ไม่มี "วิธีส่วนตัว" ใน Objective-C จริงๆหากรันไทม์สามารถทำงานได้ว่าการใช้งานแบบใดจะใช้งานได้ แต่นั่นไม่ใช่การบอกว่าไม่มีวิธีการใดที่ไม่ได้เป็นส่วนหนึ่งของอินเทอร์เฟซที่ทำเป็นเอกสาร สำหรับวิธีการเหล่านั้นฉันคิดว่าหมวดหมู่นั้นใช้ได้ แทนที่จะใส่@interfaceที่ด้านบนของไฟล์. m เช่นจุดที่ 2 ของคุณฉันจะใส่มันลงในไฟล์. h ของมันเอง การประชุมที่ฉันติดตาม (และเคยเห็นที่อื่นฉันคิดว่ามันเป็นแบบแผนของ Apple เนื่องจาก Xcode ตอนนี้ให้การสนับสนุนอัตโนมัติ) คือการตั้งชื่อไฟล์ดังกล่าวหลังจากคลาสและหมวดหมู่ด้วยเครื่องหมาย + แยกพวกมันดังนั้นจึง@interface GLObject (PrivateMethods)สามารถพบGLObject+PrivateMethods.hได้ เหตุผลในการให้ไฟล์ส่วนหัวคือเพื่อให้คุณสามารถนำเข้าในคลาสทดสอบหน่วยของคุณ :-)

โดยวิธีการที่เกี่ยวข้องกับการใช้ / การกำหนดวิธีการใกล้กับจุดสิ้นสุดของไฟล์. m คุณสามารถทำได้ด้วยหมวดหมู่โดยใช้หมวดหมู่ที่ด้านล่างของไฟล์. m:

@implementation GLObject(PrivateMethods)
- (void)secretFeature;
@end

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

แม้จะมีส่วนขยายชั้นเรียนฉันก็มักจะสร้างส่วนหัวแยกต่างหาก ( GLObject+Extension.h) เพื่อให้ฉันสามารถใช้วิธีการเหล่านั้นได้หากจำเป็นต้องเลียนแบบการมองเห็น "เพื่อน" หรือ "ป้องกัน"

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

ในขณะที่ฉันไม่ใช่ผู้เชี่ยวชาญ Objective-C ฉันเพียงกำหนดวิธีในการใช้งานคลาสของฉัน จริงอยู่ที่มันจะต้องมีการกำหนดไว้ก่อน (ด้านบน) วิธีการใด ๆ ที่เรียกว่า แต่แน่นอนต้องใช้เวลาน้อยที่สุดของงานที่ต้องทำ

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

ในบางกรณีคุณจะต้องประกาศวิธีในการเรียนต่อเนื่องของชั้นเรียน (เช่นหากใช้ตัวเลือกระหว่างการต่อชั้นเรียนกับ@implementation)

static ฟังก์ชั่นดีมากโดยเฉพาะอย่างยิ่งความไวหรือความเร็วของวิธีการส่วนตัวที่สำคัญ

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

หมวดหมู่ที่มีชื่อ (เช่น@interface MONObject (PrivateStuff)) ไม่ใช่แนวคิดที่ดีเป็นพิเศษเนื่องจากอาจมีการชนกันของชื่อเมื่อโหลด พวกเขามีประโยชน์จริง ๆ สำหรับเพื่อนหรือวิธีการป้องกัน (ซึ่งไม่ค่อยเป็นตัวเลือกที่ดี) เพื่อให้แน่ใจว่าคุณได้รับคำเตือนเกี่ยวกับการใช้งานหมวดหมู่ที่ไม่สมบูรณ์คุณควรนำไปใช้จริง:

@implementation MONObject (PrivateStuff)
...HERE...
@end

นี่คือแผ่นโกงที่มีคำอธิบายประกอบเล็กน้อย:

MONObject.h

@interface MONObject : NSObject

// public declaration required for clients' visibility/use.
@property (nonatomic, assign, readwrite) bool publicBool;

// public declaration required for clients' visibility/use.
- (void)publicMethod;

@end

MONObject.m

@interface MONObject ()
@property (nonatomic, assign, readwrite) bool privateBool;

// you can use a convention where the class name prefix is reserved
// for private methods this can reduce accidental overriding:
- (void)MONObject_privateMethod;

@end

// The potentially good thing about functions is that they are truly
// inaccessible; They may not be overridden, accidentally used,
// looked up via the objc runtime, and will often be eliminated from
// backtraces. Unlike methods, they can also be inlined. If unused
// (e.g. diagnostic omitted in release) or every use is inlined,
// they may be removed from the binary:
static void PrivateMethod(MONObject * pObject) {
    pObject.privateBool = true;
}

@implementation MONObject
{
    bool anIvar;
}

static void AnotherPrivateMethod(MONObject * pObject) {
    if (0 == pObject) {
        assert(0 && "invalid parameter");
        return;
    }

    // if declared in the @implementation scope, you *could* access the
    // private ivars directly (although you should rarely do this):
    pObject->anIvar = true;
}

- (void)publicMethod
{
    // declared below -- but clang can see its declaration in this
    // translation:
    [self privateMethod];
}

// no declaration required.
- (void)privateMethod
{
}

- (void)MONObject_privateMethod
{
}

@end

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

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

//.h file
@interface MyClass : Object
{
    int test;
}
- (void) someMethod: anArg;

@end


//.m file    
@implementation MyClass

static void somePrivateMethod (MyClass *myClass, id anArg)
{
    fprintf (stderr, "MyClass (%d) was passed %p", myClass->test, anArg);
}


- (void) someMethod: (id) anArg
{
    somePrivateMethod (self, anArg);
}

@end

คุณสามารถใช้บล็อกได้หรือไม่

@implementation MyClass

id (^createTheObject)() = ^(){ return [[NSObject alloc] init];};

NSInteger (^addEm)(NSInteger, NSInteger) =
^(NSInteger a, NSInteger b)
{
    return a + b;
};

//public methods, etc.

- (NSObject) thePublicOne
{
    return createTheObject();
}

@end

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

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

กำหนดวิธีการของคุณด้วยลายเซ็นที่คล้ายกันเป็นรหัสด้านล่าง ...

-(void)myHelperMethod: (id) sender{
     // code here...
}

จากนั้นเมื่อคุณต้องการอ้างอิงวิธีการเพียงเรียกมันว่าเป็นตัวเลือก ...

[self performSelector:@selector(myHelperMethod:)];

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

หากคุณต้องการหลีกเลี่ยงการ@interfaceบล็อกที่ด้านบนคุณสามารถใส่การประกาศส่วนตัวในไฟล์อื่นที่MyClassPrivate.hไม่เหมาะ แต่มันไม่เกะกะการใช้งาน

MyClass.h

interface MyClass : NSObject {
 @private
  BOOL publicIvar_;
  BOOL privateIvar_;
}

@property (nonatomic, assign) BOOL publicIvar;
//any other public methods. etc
@end

MyClassPrivate.h

@interface MyClass ()

@property (nonatomic, assign) BOOL privateIvar;
//any other private methods etc.
@end

MyClass.m

#import "MyClass.h"
#import "MyClassPrivate.h"
@implementation MyClass

@synthesize privateIvar = privateIvar_;
@synthesize publicIvar = publicIvar_;

@end

อีกสิ่งหนึ่งที่ฉันไม่ได้เห็นได้กล่าวถึงที่นี่ - Xcode รองรับไฟล์. h ด้วย "_private" ในชื่อ สมมติว่าคุณมีคลาส MyClass - คุณมี MyClass.m และ MyClass.h และตอนนี้คุณสามารถมี MyClass_private.h Xcode จะจดจำสิ่งนี้และรวมไว้ในรายการ "ส่วน" ในผู้ช่วยแก้ไข

//MyClass.m
#import "MyClass.h"
#import "MyClass_private.h"

ไม่มีวิธีแก้ไขปัญหา # 2 นั่นเป็นเพียงวิธีการที่คอมไพเลอร์ C (และด้วยเหตุนี้คอมไพเลอร์ Objective-C) ทำงาน หากคุณใช้ตัวแก้ไข XCode ป๊อปอัพฟังก์ชั่นควรทำให้ง่ายต่อการสำรวจ@interfaceและ@implementationบล็อกในไฟล์

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

ตามที่คนอื่น ๆ กล่าวว่าการกำหนดวิธีการส่วนตัวใน@implementationบล็อกนั้นก็โอเคสำหรับวัตถุประสงค์ส่วนใหญ่

ในหัวข้อของการจัดระเบียบรหัส - ฉันต้องการให้พวกเขาอยู่ด้วยกันภายใต้pragma mark privateเพื่อความสะดวกในการนำทางใน Xcode

@implementation MyClass 
// .. public methods

# pragma mark private 
// ...

@end