Bummer! You must be logged in to access this page.

Welcome to the Treehouse Community

Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.

Looking to learn something new?

Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.

Start your free trial

iOS

Posted by Michael Vilabrera
Michael Vilabrera
Courses Plus Student 11,252 Points

is it possible to have both @interface & @implementation in a .h file?

I was looking over code which had this. Is it standard practice for programmers using Obj-C to make classes which are to be public? Would we classify this as a protocol or a category?

1 Answer

John W
John W
21,558 Points
John W
John W
21,558 Points

This is a horrible practice. Don't do it unless you have a really really good reason. Having @interface in the .m is fine, but having @implementation in .h is bad juju and should be avoided for so many reasons.

Also protocol and category are very different things from what you described.

Michael Vilabrera
Michael Vilabrera
Courses Plus Student 11,252 Points

@John W please detail the reasons!

John W
John W
21,558 Points

To make it clear, you are allowed to do it and there are cases that this is the preferred way. It is just not recommended unless you know exactly why you should do it for a specific case and the implications. This can be a slightly more advanced subject depending on your level of knowledge, or maybe I'm just complicating things here. So take what follows with a grain of salt and understand what you can.

For one, instead of the code being compiled with the implementation of the class interface .m and generate the code object, it is now becoming part of the code from which you called #import.

To keep it short, imagine if you import your header at multiple locations, you are essentially telling the compiler to compile the same code twice and have the code exist within multiple objects in your program. Unlike including the same header twice in the same object, this won't break the code, but it causes some ambiguous effects during dynamic binding that can make debugging really hard in some rare cases. And you definitely want to start building a good habit now instead of dealing with them later when it happens.

Next, a more philosophical reason, one of the corner stones of objective-oriented programming is encapsulation, and exposing implementation is quite far from this. The only time you want to use this anti-pattern, i.e. exposure, is when requirement to understand the implementation is absolutely necessary for usage. But always think of an alternative to encapsulate before you expose yourself.

For protocol, please check out this post by Amit for a brief example: https://teamtreehouse.com/forum/protocols

Michael Vilabrera
Michael Vilabrera
Courses Plus Student 11,252 Points

Thank you very much, @John W for your assistance! I appreciate the detailed response, my understanding is clearer now. Cheers!