Given that interfaces are also used to help hide information, giving the user only a subset of the possible methods they are allowed to use, and, let's say, I have a Person
class and interface IPerson
.
Now in main, I'm allowed to do
IPerson testy = new开发者_开发技巧 Person();
or
Person testy = new Person();
So really I'm not restricted from using Person still. So how does the interface truly hide data?
Interfaces are not used to "hide" anything per se. It is used to establish a contract between the caller and the implementation. This contract promises that "these methods and properties will be here, and they will not change".
Interfaces also opens up the nice possibility of varying implementation without the caller having to deal with it. This is essential in decoupled designs.
Your question implies that your main
wants to know everything about the Person
class. What you actually get then is coupled code, which is harder to test. To "fix" this you have to change your mindset and think: main
do not want to know everything about Person
, it is only interested in IPerson
and requires only the interface. No more, no less.
Your misunderstanding comes from what's meant by "hide information". What whoever you heard this from meant was that implementing an interface allows a class to separate its forward-facing methods from its internal implementations.
This is also called "encapsulation", and the benefit of it is to allow the designer to change an object's internal mechanisms without disrupting existing code that was written around it's public interface, making it easier to change things. Thus, you'll frequently hear interfaces described as a "contract" because it creates an implicit agreement between the users and the implementers of a class that its forward-facing methods will remain consistent. And because multiple classes can implement a single interface, one component can be easily replaced with a different one, as long as it implements the same public interface. Grady Booch, the author of a well-respected book on object-oriented design, defines encapsulation as follows:
the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation.
It isn't necessary that the consumer of an object know or be exposed to how the designer of that object implemented its functionality under the covers. Think of your microwave: all you have to do to use a microwave to make a snack is push a few buttons on the front. That's the public interface of your microwave. It isn't necessary to understand the scientific principles that are behind its design just to make a bag of popcorn. The benefit to interfaces here is that they reduce complexity and make it easier for other developers to make use of your classes.
So, referring back to the example given in your question, you aren't supposed to be restricted from using the Person
class, but you might be limited in the methods exposed by that class that you are able to access. For example, the Person
class might store a person's names internally in separate FirstName
and LastName
fields, but only publically expose one Name
property that returns the concatenation of both of those private name fields.
But object-oriented design and terminology is fairly complicated. I strongly recommend that you search out a good book on the concepts and read it carefully. You'll be a better programmer because of it.
What if You dont have that Person
class.
Object obj = loadObject();
if(obj is IPerson) {
IPerson person = (IPerson) obj;
}
or
IPerson person = loadPerson();
The fundamental can't-do-any-other-way purpose of interfaces in .net is to provide a limited form of multiple inheritance. Having a class inherit from another class serves two orthogonal purposes:
- It means that fields, methods, and properties of the base class which will adequately serve the needs of the derived class can be used by the derived class without having to be respecified.
- It means that code which expects methods of the base class can automatically work with methods of the derived class.
It is not possible for a class in .net to implicitly make use of the members of more than base class, but it is possible for a class to implement many interfaces, and be substitutable for any of them. For example, a Dictionary and a linked list don't have much in common, but they can both be enumerated. A serial port and a ListBox don't have much in common, but they can both be Disposed.
Almost everything interfaces can do, can be done just as well or better with abstract base classes. The one thing interfaces can do which base classes cannot is allow for a limited form of multiple inheritance.
精彩评论