From -2200085256871418569 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,5e585716c0fba88e X-Google-Attributes: gidf78e5,public From: cgenly@teleport.com Subject: Re: why are private functions part of a class' interface? Date: 1995/04/14 Message-ID: #1/1 X-Deja-AN: 100441609 references: content-type: TEXT/PLAIN; charset=US-ASCII organization: Teleport - Portland's Public Access (503) 220-1016 mime-version: 1.0 newsgroups: comp.std.c++ >> Whenever I add a private helper function to a class, I have to change >> its interface in the .h file and thus recompile all dependent classes >> (unless I think it would be useful to permit member function definitions >> without requiring a declaration. >> >> Also, if I can define a "member" function without the class >> declaring it as a member/friend, this blows encapsulation. What stops >> me from doing anything I want to the private/protected instance data? > It could be possible to declare private methods without adding them to > the .h file, since you can do it with Ada. > But with C++, the encapsulation is performed *only* by the class > descrition, which is usually in the .h file. > As a result, there is no way you can safely define such a function > outside the .h file and avoid recompiling everything. I was concerned with this problem too. Bjarne Stroustrup replied with the technique of using an abstract class to be included by clients of the class. This abstract class would not declare private members. A derived class of the abstract class would be used in the implmentaion, and would declare the private members. This isolates clients from implementation issues. I find this a bit of awkward, but workable.