What is an Interface?

Can we say the set of  methods specified in public region of
class is the interface to the object i.e methods the application
using the object  would use to get the services from the object?
or is there anything more to it?
Any different views/opinions ?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

I think you could say that. But I'd also add public data members as part of the interface as well.

Sounds good for me but I would call it public interface. The application using the class may introduce some derived classes in which implementation protected interface may be also used. I also agree with jhance's comment.
kgreddyAuthor Commented:

Why would anyone needs to expose data members as part
of public. Because I have read somewhere that exposing
the data to client is a bad way to design the reason is
are we not violating the "data hiding " concept by doing so?

Cloud Class® Course: Microsoft Office 2010

This course will introduce you to the interfaces and features of Microsoft Office 2010 Word, Excel, PowerPoint, Outlook, and Access. You will learn about the features that are shared between all products in the Office suite, as well as the new features that are product specific.

object-oriented purists always say that.Alsoin real oop realm,all objects are relatives.However,you can see it's not the case in C++.
There are many reasons you need to do that.E.g: in MFC,all window class have a window handle data as public,why? for your convenience,you can easy get the handle by &windowclass.
So,never stick to something.
>Why would anyone needs to expose data
>members as part

I'm not talking about style or good practice.  The fact is that C++ permits public data members in a class.  It's perfectly legal and also commonly done.

Whether or not it's a good thing to do is a philosophical question that doesn't change the fact that they should be considered part of the interface to the class if they exist.
The question is should they be considered if they don't exist? :)
>>The question is should they be considered if they don't exist? :)

since it doesnt exist,how you consider?
If there is legitimate reason for anyone outside a class to have full access to a data member then a) it should be public, not thinly veiled behind primitive accessor functions and b) there's probably something wrong with the design.  From an OO purist's point of view, you shouldn't be manipulating data to begin with - you should be performing operations.  In the (extremely rare) case that an actual operation really does make sense to consist of nothing other than accessing data - then offer access to the data.

(By this argument, the MFC CWnd class is flawed - whatever you would "need" the HWND for, you should be able to do through the class.)
Regarding the initial question, my take is that the interface includes all public and protected members, whether data or functions - because these are what can be accessed by another class.  In Java, I'd add "package" access-level members, too.  Also, if there are friend classes or functions, private data and methods also become part of the interface.

When it comes to actually documenting an interface, different levels are appropriate - in most cases, you would ignore friends and package-level access.  I'd offer only public members in an interface specification that will end up external to my project, and both public and protected in a specification that is internal to my project.
> Also, if there are friend classes or functions,
> private data and methods also become part of the interface.

It looks a little doubtful as for external interface. Friend's name is usually the name of some existing ( at least known ) class or function at the moment of the class declaration.
If A includes B as a friend, then any programmer who needs to maintain B must be able to rely on A's implementation (private members).  If A's privates change, B may break.  If someone needs to maintain B, they need to know what A has to offer - that's its interface.

In actual use, A and B are typically so tied together that modifying one when the other changes is as natural as modifying different members of the same class together.  At least, that's how it should be.  (friend operators are an example)

But the point remains, if a class has friends, then there is code outside of the class that can use its private members directly - therefore, code outside the class may depend on that "private" interface, and those details are important external to the class.

That's why I consider private members of classes with friends to be part of their "complete" interface.  In practice I would hardly ever include them in a formal interface specification document, unless that document was specifically for the use of developers working on the friend code.
You are right, of course. My remark was about external interface as it's observed from the outstanding from the module point of view. I just meant A & B usually are ( should be ) in the same boat.
The word INTERFACE is used in a new way in the past few years, since Java and Component Technology (COM, CORBA, Beans etc.)

If you are talking about THIS type of "interface" (it is even a reserved word in Java and in C++) then the answer to your question is NO.

And here is what "interface" means in Component technology:

An "Interface" is a pure virtual class, "exposing" everything the "binary implementation" can do.
These are all actually methods, and consist of three categories:
1. Events: Methods that the implementation will call using some kind of "FireEvent()" API.
2. Methods: Plain old methods, including the parameter information.
3. Properties: 2 methods for each "property". get_MyProperty() and put_MyProperty(). Along with each list of parameter definitions.

In java you "implement" a class using the "implements" keyword.
In C++ you inherit the Interface, and somewhere down the line of inheritance, you implement all the methods.

In COM, AFTER you compile the object (implementation) it is registered with a unique number in the Windows Registry, and used IN YOUR PROGRAMS as if it was code. You call this application (usually called a component) inside your code, ask it what it knows how to do (what interfaces it supports) and then with a "pointer to the interface" set and get it's properties and run it's methods.

Back to OO: If it's only C++ and OOP you are asking: the interface is anything that can be accessed outside the class.
ie. public and protected data and methods. Usually if the data (even private) has a set or get function, you would say the data is part of the interface as read-only, write-only, or read-write data.


I see no-one is commenting further, so I'll offer the last comment as the answer...


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
kgreddyAuthor Commented:
Thanks all of you for participating and offering your views.
mflam :
The explanation you offered is elaborate and covers
all the aspects I was not aware of.
Thank you.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.