Further specify class behavior with C# interfaces.

Interfaces

Now we have a `Sedan` class and `Truck` class that implement the `IAutomobile` interface. Though they have some different behaviors, they both have the properties and method defined in the interface:
* `double Speed`
* `string LicensePlate`
* `int Wheels`
* `void Honk()`

At this point we can be confident that we won't cause any errors if we try to access these members in either the `Sedan` or `Truck` class.


Testing Interfaces

For this lesson we will be designing a new set of transportation machines that satisfy the requirements of BOTH car designers and the highway patrol.
First the highway patrol tells us: "Every automobile on the road must have these properties and methods accessible to us:"
* speed
* license plate number
* number of wheels
* ability to honk

The patrol needs this information to write speeding tickets and prevent bad behavior on the highway. 

In other words, the patrol makes these requirements so that it can interact with automobiles in a certain way. In C#, this group of interactions is called an _interface_. The interface is a set of properties, methods, and other members. They are declared with a signature but their behaviors are not defined. A class _implements_ an interface if it defines those properties, methods, and other members. 

For example, if the patrol requires automobiles to have a license plate, then the `IAutomobile` interface contains a `LicensePlate` property. A class implements this interface if it defines a `LicensePlate` property.

The skeleton of an interface looks a bit like a class:
```cs
interface IAutomobile
{
}
```

Every interface should have a name starting with "I". This is a useful reminder to other developers and our future selves that this is an interface, not a class.
We can add members, like properties and methods, to the interface. Here's an example of a fake property and method:
```cs
interface IAutomobile
{
  string Id { get; }
  void Vroom();
}
```

Notice that the property and method bodies are not defined. An interface is a set of actions and values, but it doesn't specify how they work. 

In our highway example, the highway patrol doesn't care HOW the license plate property and honk method work, they just care whether every automobile has it.


Build an Interface

Well done! In this lesson, you:
* Learned that interfaces are useful to guarantee certain functionality across multiple classes
* Built an interface using the `interface` keyword
* Defined properties and methods (but not constructors or fields) in the interface
* Built classes that implemented the interface
* Added members to the classes that weren't specified in the interface

As a last note: a class can implement multiple interfaces. For example, `Sedan` could implement `IAutomobile` and a new `IRecyclable` interface. It would be useful to separate interfaces if they aren't related, i.e. not all automobiles are recyclable.
 
With this lesson you completed, you might be asking yourself this question:


We have duplicated code, like `SpeedUp()` and `SlowDown()`, in two classes, and we know that duplicated code is hard to maintain. Is there a way to avoid duplication?
 
The answer has to do with _inheritance_. The concept won't be covered in this lesson, but now you have one good reason to learn it.


Your C# skills are growing. Keep up the good work!


Review

We've completed a `Sedan` class that satisfies both car designers and highway patrol: it can be constructed and change speed, and it implements the `IAutomobile` interface. 

But sedans aren't the only automobile on the road. There can be multiple classes that implement an interface. 

For example, we can create a `Truck` class that also implements the interface.

This is where we start to see the power of interfaces. Even though `Sedan` and `Truck` are different types, we can assume that they behave similarly because they share an interface. Car designers can build different vehicle classes, but the highway patrol can treat them all the same.


Implementing an Interface Again

The car designers have asked that trucks act a bit differently from sedans. Trucks need a new property called `Weight`. Whenever a truck is constructed, its number of wheels will depend on its weight. For example, a heavier truck might need 12 instead of 8 wheels to support itself.

Just like sedans, trucks will also `SpeedUp()` and `SlowDown()`.


Finish Truck Class

The `Sedan` needs to satisfy more than the highway patrol's rules (the `IAutomobile` interface). The car designers have asked that sedans are built and move in certain ways &mdash; it must have constructors and methods that aren't required by the `IAutomobile` interface. This is okay in C#! The interface says what a class MUST have. It does not say what a class MUST NOT have.

In fact, interfaces cannot specify two types of members that are commonly found in classes:
* Constructors
* Fields


What Interfaces Cannot Do

Our interface is complete! Pretty easy, right?

As we design our automobile-like classes, we'll need to implement this `IAutomobile` interface. In C#, we must first clearly announce that a class implements an interface using the colon syntax:

```cs
class Sedan : IAutomobile
{
}
```

This empty `Sedan` class "promises" to implement the `IAutomobile` interface. In other words, it must have the properties and methods the highway patrol asked for (`Speed`, `LicensePlate`, `Wheels`, and `Honk()`).

If we don't, we get a type error like this:

```
error CS0535: Sedan does not implement interface member 'IAutomobile.LicensePlate'
```

To fix this we'll need to define the members in the interface:

```cs
class Sedan : IAutomobile
{
  public string LicensePlate
  { get; }
  
  // and so on...
}
```

Remember that these members must be `public`. How else will the highway patrol be able to access them?


Implementing an Interface

Since programming is complex, it's easy to make mistakes. For example, maybe we try to use an `int` like a `string`. This would cause a type error. C# has rules built-in that check for those mistakes before we use that code in the real world. 

The diagram below estimates the number of bugs in our code at each stage of development. We discover and fix some of those bugs at each stage, so the number decreases from left to right. Sadly we can't fix every bug. But if we can catch bugs earlier, then we save ourselves work and we save users frustration. 

We say that C# is "type-safe" because it helps us catch bugs at one of the earliest stages: the type checking stage.

![Stages of Product Lifecycle are Planning, Type Checking, Running Code, Peer Review, and User Feedback](https://content.codecademy.com/courses/learn-c-sharp/interfaces-and-inheritance/ErrorFunnelDiagram_3.svg)

The difference between an `int` and a `string` is clear, but what about custom-defined classes? Say we made `Fruit` and `Vegetable` types. Can we use `PlantSeed()` on both? Do they both have a `Seed` property? The computer running the program needs more information.

In this lesson we'll dive into _interfaces_, which are sets of actions and values that describe how a class can be used. This lets the computer check that we are using each type legally, thus preventing a whole group of type errors!

In this lesson you'll learn how to:
* build your own interface
* write classes that implement an interface
