Consider the following code:
interface IPerson
{
void Talk();
void Walk();
}
class Person : IPerson
{
public void Talk()
{
///Do talk behavior
}
public void Walk()
{
///Do walk behavior
}
}
Intuitively, to me, the above code doesn't seem to describe my personal definition of an interface at all.
But, as time went on, I just accepted the terminology, and disregarded my preconceived notion of what an interface was, and ended up finding Interfaces to be quite useful in my programming endeavors.
The reason that I'm revisiting that part in my journey to learn more about object oriented design is because I find myself constantly relearning things, or looking at things in different ways, because the code I'm writing requires I do so.
I've recently been making an effort to plan my code before I actually write it, to make a clean break from "cowboy" programming. My planning includes a high-level design, where I first write down what classes will be required to perform the functionality of the features I'm trying to build. After I've written down the class names, I figure out what public methods I will need to have in each of the classes.
In one of my recent high-level design sessions, I was struggling to build the right incantation of classes/methods, etc, and when I was talking about it with a colleague, I inadvertently referred to my collection of public methods in one of my classes as its "public interface." And in that moment, the terminology that once seemed like such a misnomer to me became a spot-on description of what an interface does.
Even though the class I was referencing did not actually implement an interface, its public methods represent its interface that other classes have to it. And so, looking at what a user interface does, which is provide a means for an end-user to interact with a system, it is quite analagous to what an interface does, and that is, provide a means for outside classes to interact with a class that implements the interface. Yay interfaces!
No comments:
Post a Comment