Advantages of seperating interface/implementation?
Could someone give me a quick rundown as to why separating the interface and implementation is beneficial? So far, me being a total noob, I've just been putting both in the same header file instead of the one in a header and the other in a source.
I don't know what dangers I face as a consequence.
Thanks!
**Oh yea-- I recall something about header files potentially being ignored by the compiler. Is that it?
I don't know what dangers I face as a consequence.
Thanks!
**Oh yea-- I recall something about header files potentially being ignored by the compiler. Is that it?
Last edited on
There is no programmatic danger of doing this, it is simply a design principle. The thing you heard about the compiler ignoring is completely false, the compiler literally doesn't care where these are located, it's all the same.
Information hiding, object-oriented design principles, and allowing custom implementations are among the reasons why this is done.
Information hiding, object-oriented design principles, and allowing custom implementations are among the reasons why this is done.
I think there are two different meanings of "separating interface from implementation" going on here.
One meaning is header files vs. cpp files. The reason for doing this is that if you fix a bug in the implementation part, only that .cpp file needs to be recompiled and none others. If the implementation is in the header file instead, you have to recompile every cpp file that includes that header file either directly or indirectly. In a large project, such a change could end up causing a recompile of hundreds or thousands or more source files which might take minutes or hours, instead of compiling a single source file which would take seconds.
The second meaning is from an object-oriented standpoint. Separating interface from implementation there means that the methods you provide in your object should not expose the internal implementation details of the object. The reason for this is because if you change the internal implementation of the object, you end up having to change the interface as well. Once you change the interface, you have to change all the code that uses that interface. This type of change could then ripple through the entire project.
Simple example of the latter. Today, your Person object stores the phone number as an int, because you only need 7-digit phone numbers. So Person::getPhoneNumber() returns an int, and all the code that calls getPhoneNumber() stores the result in ints. Your interface -- getPhoneNumber() is now tied to an implementation detail -- that a phone number is stored internally as an int. Tomorrow, you need to support international phone numbers. Suddenly, int isn't good enough any more. So you're forced to change the phoneNum data member to a long long. Now getPhoneNumber() has to change and every place in the code where getPhoneNumber() is called has to change to store the result in a long long. And then all the functions that get called with a phone number as parameter have to change from taking an int to taking a long long. Etc, etc.
One meaning is header files vs. cpp files. The reason for doing this is that if you fix a bug in the implementation part, only that .cpp file needs to be recompiled and none others. If the implementation is in the header file instead, you have to recompile every cpp file that includes that header file either directly or indirectly. In a large project, such a change could end up causing a recompile of hundreds or thousands or more source files which might take minutes or hours, instead of compiling a single source file which would take seconds.
The second meaning is from an object-oriented standpoint. Separating interface from implementation there means that the methods you provide in your object should not expose the internal implementation details of the object. The reason for this is because if you change the internal implementation of the object, you end up having to change the interface as well. Once you change the interface, you have to change all the code that uses that interface. This type of change could then ripple through the entire project.
Simple example of the latter. Today, your Person object stores the phone number as an int, because you only need 7-digit phone numbers. So Person::getPhoneNumber() returns an int, and all the code that calls getPhoneNumber() stores the result in ints. Your interface -- getPhoneNumber() is now tied to an implementation detail -- that a phone number is stored internally as an int. Tomorrow, you need to support international phone numbers. Suddenly, int isn't good enough any more. So you're forced to change the phoneNum data member to a long long. Now getPhoneNumber() has to change and every place in the code where getPhoneNumber() is called has to change to store the result in a long long. And then all the functions that get called with a phone number as parameter have to change from taking an int to taking a long long. Etc, etc.
closed account (N85iE3v7)
As jsmith said, if the actual implementation is separated from the interface, one gain a lot of freedom. For example, you may target different platforms, that differ only in the kernel or hardware level. By doing that your application is more easily portable.
Topic archived. No new replies allowed.