Would it make any sense to put class extensions in their own .h
files and #import
them selectively to get various levels of visibility for a class' methods and properties? If this is a bad idea (or would not work), why?
相关问题
- CALayer - backgroundColor flipped?
- Core Data lightweight migration crashes after App
- back button text does not change
- iOS (objective-c) compression_decode_buffer() retu
- how to find the index position of the ARRAY Where
相关文章
- 现在使用swift开发ios应用好还是swift?
- TCC __TCCAccessRequest_block_invoke
- xcode 4 garbage collection removed?
- Unable to process app at this time due to a genera
- How can I add media attachments to my push notific
- didBeginContact:(SKPhysicsContact *)contact not in
- Custom Marker performance iOS, crash with result “
- Why is my library not able to expand on the CocoaP
It is a great idea and exactly why Class Extensions were designed (and why they are different than categories).
Namely, you can:
Foo.h
Foo_FrameworkOnly.h
Foo.m
And effectively have a property that is publicly readonly and privately read write for only the implementation files that import Foo_FrameworkOnly.h.
Class extension (as opposed to subclassing) in Objective-C is accomplished with Categories. In Xcode, go to File > New > File and select Objective-C Category. It will ask you what to call the category and what class it should extend. You'll get a .h/.m pair in which to put your interface and implementation, respectively. If you want access to the features provided in your extension, just import its .h file.