PART IV<\/p>\n
Advanced C# Programming<\/p>\n
CHAPTER 8<\/p>\n
Working with Interfaces<\/p>\n
This chapter builds upon your current understanding of object-oriented development by examining the topic of interface-based programming. Here, you will learn how to define and implement interfaces and come to understand the benefits of building types that support multiple behaviors. Along the way, you will look at several related topics, such as obtaining interface references, implementing explicit interfaces, and constructing interface hierarchies. You will also examine several standard interfaces defined within the
\n.NET Core base class libraries. Also covered are the new features introduced in C# 8 regarding interfaces, including default interface methods, static members, and access modifiers. As you will see, your custom classes and structures are free to implement these predefined interfaces to support several useful behaviors, such as object cloning, object enumeration, and object sorting.<\/p>\n
Understanding Interface Types
\nTo begin this chapter, allow me to provide a formal definition of the interface type, which has changed with the introduction of C# 8.0. Prior to C# 8.0, an interface is nothing more than a named set of abstract members. Recall from Chapter 6 that abstract methods are pure protocol, in that they do not provide a default implementation. The specific members defined by an interface depend on the exact behavior it is
\nmodeling. Said another way, an interface expresses a behavior that a given class or structure may choose to support. Furthermore, as you will see in this chapter, a class or structure can support as many interfaces as necessary, thereby supporting (in essence) multiple behaviors.
\nThe default interface methods feature, introduced in C# 8.0, allows for interface methods to contain an implementation that may or may not be overridden by the implementing class. More on this later in this chapter.
\nAs you might guess, the .NET Core base class libraries ship with numerous predefined interface types that are implemented by various classes and structures. For example, as you will see in Chapter 20, ADO.NET ships with multiple data providers that allow you to communicate with a particular database management system. Thus, under ADO.NET, you have numerous connection objects to choose from (SqlConnection, OleDbConnection, OdbcConnection, etc.). In addition, third-party database vendors (as
\nwell as numerous open source projects) provide .NET libraries to communicate with a wide number of other databases (MySQL, Oracle, etc.), all of which contain objects implementing these interfaces.
\nAlthough each connection class has a unique name, is defined within a different namespace, and (in some cases) is bundled within a different assembly, all connection classes implement a common interface named IDbConnection.<\/p>\n
\/\/ The IDbConnection interface defines a common
\n\/\/ set of members supported by all connection objects. public interface IDbConnection : IDisposable
\n{<\/p>\n
\u00a9 Andrew Troelsen, Phil Japikse 2022 315<\/p>\n \/\/ Methods \u25a0Note By convention, .NET interface names are prefixed with a capital letter I. When you are creating your own custom interfaces, it is considered a best practice to do the same.<\/p>\n Do not concern yourself with the details of what these members do at this point. Simply understand that the IDbConnection interface defines a set of members that are common to all ADO.NET connection classes. Given this, you are guaranteed that every connection object supports members such as Open(), Close(), CreateCommand(), and so forth. Furthermore, given that interface members are always abstract, each connection object is free to implement these methods in its own unique manner. Interface Types vs. Abstract Base Classes namespace CustomInterfaces; \/\/ hierarchies have no access to this abstract Given this definition, only members that extend CloneableType can support the Clone() method. If you create a new set of classes that do not extend this base class, you cannot gain this polymorphic interface. Also, recall that C# does not support multiple inheritance for classes. Therefore, if you wanted to create a MiniVan that \u201cis-a\u201d Car and \u201cis-a\u201d CloneableType, you are unable to do so.<\/p>\n \/\/ Nope! Multiple inheritance is not possible in C# As you might guess, interface types come to the rescue. After an interface has been defined, it can be implemented by any class or structure, in any hierarchy, and within any namespace or any assembly (written in any .NET Core programming language). As you can see, interfaces are highly polymorphic. Consider the standard .NET Core interface named ICloneable, defined in the System namespace. This interface defines a single method named Clone().<\/p>\n public interface ICloneable If you examine the .NET Core base class libraries, you will find that many seemingly unrelated types (System.Array, System.Data.SqlClient.SqlConnection, System.OperatingSystem, System.String, etc.) all implement this interface. Although these types have no common parent (other than System.Object), you can treat them polymorphically via the ICloneable interface type. using CustomInterfaces;<\/p>\n Console.WriteLine(" A First Look at Interfaces <\/em><\/strong><\/strong>\\n"); CloneableExample();<\/p>\n Next, add the following local function named CloneMe() to your top-level statements. This function takes an ICloneable interface parameter, which accepts any object that implements this interface. Here is the function code:<\/p>\n static void CloneableExample() CloneMe(unixOS); When you run this application, the class name of each class prints to the console via the GetType() method you inherit from System.Object. As will be explained in detail in Chapter 17, this method allows you to understand the composition of any type at runtime. In any case, the output of the previous program is shown next:<\/p>\n A First Look at Interfaces <\/em><\/strong><\/strong> Your clone is a: String Another limitation of abstract base classes is that each derived type must contend with the set of abstract members and provide an implementation. To see this problem, recall the shapes hierarchy you defined in Chapter 6. Assume you defined a new abstract method in the Shape base class named GetNumberOfPoints(), which allows derived types to return the number of points required to render the shape.<\/p>\n namespace CustomInterfaces; abstract class Shape Clearly, the only class that has any points in the first place is Hexagon. However, with this update, every derived class (Circle, Hexagon, and ThreeDCircle) must now provide a concrete implementation of this function, even if it makes no sense to do so. Again, the interface type provides a solution. If you define an interface that represents the behavior of \u201chaving points,\u201d you can simply plug it into the Hexagon type, leaving Circle and ThreeDCircle untouched.<\/p>\n \u25a0Note The changes to interfaces in C# 8 are probably the most significant changes to an existing language feature that i can recall. as described earlier, the new interface capabilities move them significantly closer to the functionality of abstract classes, with the added ability for a class to implement multiple interfaces. My advice is to tread carefully in these waters and use common sense. Just because you can do something does not mean that you should.<\/p>\n Defining Custom Interfaces namespace CustomInterfaces; Interfaces in C# 8 cannot define data fields or nonstatic constructors. Hence, the following version of \/\/ Ack! Errors abound! In any case, this initial IPointy interface defines a single method. Interface types are also able to define any number of property prototypes. For example, we could update the IPointy interface to use a read-write property (commented out) and a read-only property. The Points property replaces the GetNumberOfPoints() method.<\/p>\n \/\/ The pointy behavior as a read-only property. public interface IPointy \/\/ A read-write property in an interface would look like: \/\/ while a read-only property in an interface would be: byte Points { get; } \u25a0Note interface types can also contain event (see Chapter 12) and indexer (see Chapter 11) definitions.<\/p>\n Interface types are quite useless on their own, as you cannot allocate interface types as you would a class or structure.<\/p>\n \/\/ Ack! Illegal to allocate interface types. IPointy p = new IPointy(); \/\/ Compiler error!<\/p>\n Interfaces do not bring much to the table until they are implemented by a class or structure. Here, IPointy is an interface that expresses the behavior of \u201chaving points.\u201d The idea is simple: some classes in the shapes hierarchy have points (such as the Hexagon), while others (such as the Circle) do not.<\/p>\n Implementing an Interface \/\/ This class derives from System.Object and \/\/ This class also derives from System.Object \/\/ This class derives from a custom base class \/\/ This struct implicitly derives from System.ValueType and Understand that implementing an interface is an all-or-nothing proposition for interface items that do not include a default implementation. The supporting type is not able to selectively choose which members it will implement. Given that the IPointy interface defines a single read-only property, this is not too much of a burden. However, if you are implementing an interface that defines ten members (such as For this example, insert a new class type named Triangle that \u201cis-a\u201d Shape and supports IPointy. namespace CustomInterfaces; \/\/ IPointy implementation. Now, update your existing Hexagon type to also support the IPointy interface type.<\/p>\n namespace CustomInterfaces; \/\/ IPointy implementation. To sum up the story so far, the Visual Studio class diagram shown in Figure 8-1 illustrates IPointy- compatible classes using the popular \u201clollipop\u201d notation. Notice again that Circle and ThreeDCircle do not implement IPointy, as this behavior makes no sense for these classes.<\/p>\n Figure 8-1. The shapes hierarchy, now with interfaces<\/p>\n \u25a0Note To display or hide interface names in the class designer, right-click the interface icon and select the Collapse or Expand option.<\/p>\n Invoking Interface Members at the Object Level using CustomInterfaces;<\/p>\n Console.WriteLine(" Fun with Interfaces <\/em><\/strong><\/strong>\\n"); This approach works fine in this case, given that you understand the Hexagon type has implemented the interface in question and, therefore, has a Points property. Other times, however, you might not be able to determine which interfaces are supported by a given type. For example, suppose you have an array containing 50 Shape-compatible types, only some of which support IPointy. Obviously, if you attempt to invoke the Points property on a type that has not implemented IPointy, you will receive an error. So, how can you dynamically determine whether a class or structure supports the correct interface? ... While you could use try\/catch logic and hope for the best, it would be ideal to determine which interfaces are supported before invoking the interface members in the first place. Let\u2019s see two ways of doing so.<\/p>\n Obtaining Interface References: The as Keyword ... Notice that when you use the as keyword, you have no need to use try\/catch logic; if the reference is not null, you know you are calling on a valid interface reference.<\/p>\n Obtaining Interface References: The is Keyword (Updated 7.0) Console.WriteLine(" Fun with Interfaces <\/em><\/strong><\/strong>\\n"); Default Implementations (New 8.0) namespace CustomInterfaces; interface IRegularPointy : IPointy Add a new class named Square.cs to the project, inherit the Shape base class, and implement the namespace CustomInterfaces; \/\/This comes from the IPointy interface public byte Points => 4;<\/p>\n \/\/These come from the IRegularPointy interface public int SideLength { get; set; } Here we have unwittingly introduced the first \u201ccatch\u201d of using default implementations in interfaces. Console.WriteLine("\\n Fun with Interfaces <\/em><\/strong><\/strong>\\n"); Instead, the Square instance must be explicitly cast to the IRegularPointy interface (since that is where the implementation lives), and then the Perimeter property can be accessed. Update the code to the following:<\/p>\n Console.WriteLine($"{sq.PetName} has {sq.NumberOfSides} of length {sq.SideLength} and a perimeter of {((IRegularPointy)sq).Perimeter}");<\/p>\n One option to get around this problem is to always code to the interface of a type. Change the definition of the Square instance to IRegularPointy instead of Square, like this:<\/p>\n IRegularPointy sq = new Square("Boxy") {NumberOfSides = 4, SideLength = 4};<\/p>\n The problem with this approach (in our case) is that the Draw() method and PetName property are not defined on the interface, causing compilation errors. Static Constructors and Members (New 8.0) interface IRegularPointy : IPointy \/\/Static members are also allowed in C# 8 static string ExampleProperty { get; set; }<\/p>\n static IRegularPointy() => ExampleProperty = "Foo"; Static constructors must be parameterless and can only access static properties and methods. To access the interface static property, add the following code to the top-level statements:<\/p>\n Console.WriteLine($"Example property: {IRegularPointy.ExampleProperty}"); IRegularPointy.ExampleProperty = "Updated"; Notice how the static property must be invoked from the interface and not an instance variable.<\/p>\n Interfaces as Parameters namespace CustomInterfaces; Next, assume that two of your three shapes (ThreeDCircle and Hexagon) have been configured to support this new behavior.<\/p>\n \/\/ Circle supports IDraw3D. \/\/ Hexagon supports IPointy and IDraw3D. class Hexagon : Shape, IPointy, IDraw3D Figure 8-2 presents the updated Visual Studio class diagram.<\/p>\n Figure 8-2. The updated shapes hierarchy<\/p>\n If you now define a method taking an IDraw3D interface as a parameter, you can effectively send in any object implementing IDraw3D. If you attempt to pass in a type not supporting the necessary interface, you receive a compile-time error. Consider the following method defined within your Program.cs file:<\/p>\n \/\/ I'll draw anyone supporting IDraw3D. static void DrawIn3D(IDraw3D itf3d) You could now test whether an item in the Shape array supports this new interface and, if so, pass it into the DrawIn3D() method for processing.<\/p>\n Console.WriteLine(" Fun with Interfaces <\/em><\/strong><\/strong>\\n"); Here is the output of the updated application. Notice that only the Hexagon object prints out in 3D, as the other members of the Shape array do not implement the IDraw3D interface.<\/p>\n Fun with Interfaces <\/em><\/strong><\/strong> Interfaces as Return Values \/\/ This method returns the first object in the You could interact with this method as follows:<\/p>\n Console.WriteLine(" Fun with Interfaces <\/em><\/strong><\/strong>\\n"); \/\/ Get first pointy item. Arrays of Interface Types within your current project that model kitchen utensils (via Knife and Fork classes) and another modeling gardening equipment (\u00e0 la PitchFork). The relevant code for the classes is shown here, and the updated class diagram is shown in Figure 8-3:<\/p>\n \/\/Fork.cs Figure 8-3. Recall that interfaces can be \u201cplugged into\u201d any type in any part of a class hierarchy.<\/p>\n If you defined the PitchFork, Fork, and Knife types, you could now define an array of IPointy- compatible objects. Given that these members all support the same interface, you can iterate through the array and treat each item as an IPointy-compatible object, regardless of the overall diversity of the class hierarchies.<\/p>\n ... foreach(IPointy i in myPointyObjects) Just to highlight the importance of this example, remember this: when you have an array of a given interface, the array can contain any class or structure that implements that interface.<\/p>\n Implementing Interfaces Using Visual Studio or Visual Studio Code Figure 8-4. Implementing interfaces automatically using Visual Studio Code<\/p>\n Figure 8-5. Implementing interfaces automatically using Visual Studio<\/p>\n Notice you are presented with two options, the second of which (explicit interface implementation) will be examined in the next section. For the time being, select the first option, and you will see that Visual namespace CustomInterfaces; class PointyTestClass : IPointy \u25a0Note Visual studio \/Visual studio Code also supports extract interface refactoring, available from the Extract interface option of the Quick actions menu. This allows you to pull out a new interface definition from an existing class definition. for example, you might be halfway through writing a class when it dawns on you that you can generalize the behavior into an interface (and thereby open the possibility of alternative implementations).<\/p>\n Explicit Interface Implementation namespace InterfaceNameClash; namespace InterfaceNameClash; { namespace InterfaceNameClash; Notice that each interface defines a method named Draw(), with the identical signature. If you now want to support each of these interfaces on a single class type named Octagon, the compiler will allow the following definition:<\/p>\n namespace InterfaceNameClash; Although the code compiles cleanly, you do have a possible problem. Simply put, providing a single implementation of the Draw() method does not allow you to take unique courses of action based on which interface is obtained from an Octagon object. For example, the following code will invoke the same Draw() method, regardless of which interface you obtain:<\/p>\n using InterfaceNameClash;<\/p>\n Console.WriteLine(" Fun with Interface Name Clashes <\/em><\/strong><\/strong>\\n"); Octagon oct = new Octagon();<\/p>\n \/\/ Both of these invocations call the \/\/ Shorthand notation if you don't need \/\/ Could also use the "is" keyword. Console.ReadLine();<\/p>\n Clearly, the sort of code required to render the image to a window is quite different from the code needed to render the image to a networked printer or a region of memory. When you implement several interfaces that have identical members, you can resolve this sort of name clash using explicit interface implementation syntax. Consider the following update to the Octagon type:<\/p>\n class Octagon : IDrawToForm, IDrawToMemory, IDrawToPrinter As you can see, when explicitly implementing an interface member, the general pattern breaks down to this:<\/p>\n returnType InterfaceName.MethodName(params){}<\/p>\n Note that when using this syntax, you do not supply an access modifier; explicitly implemented members are automatically private. For example, the following is illegal syntax:<\/p>\n \/\/ Error! No access modifier! public void IDrawToForm.Draw() Because explicitly implemented members are always implicitly private, these members are no longer available from the object level. In fact, if you were to apply the dot operator to an Octagon type, you would find that IntelliSense does not show you any of the Draw() members. As expected, you must use explicit casting to access the required functionality. The previous code in the top-level statements is already using explicit casting, so it works with explicit interfaces.<\/p>\n Console.WriteLine(" Fun with Interface Name Clashes <\/em><\/strong><\/strong>\\n"); Octagon oct = new Octagon();<\/p>\n \/\/ We now must use casting to access the Draw() \/\/ Shorthand notation if you don't need \/\/ Could also use the "is" keyword. While this syntax is quite helpful when you need to resolve name clashes, you can use explicit interface implementation simply to hide more \u201cadvanced\u201d members from the object level. In this way, when the object user applies the dot operator, the user will see only a subset of the type\u2019s overall functionality. Designing Interface Hierarchies namespace InterfaceHierarchy; public interface IDrawable Given that IDrawable defines a basic drawing behavior, you could now create a derived interface that extends this interface with the ability to render in modified formats. Here is an example:<\/p>\n namespace InterfaceHierarchy; Given this design, if a class were to implement IAdvancedDraw, it would now be required to implement every member defined up the chain of inheritance (specifically, the Draw(), DrawInBoundingBox(), and DrawUpsideDown() methods).<\/p>\n namespace InterfaceHierarchy; Now, when you use the BitmapImage, you can invoke each method at the object level (as they are all using InterfaceHierarchy; \/\/ Get IAdvancedDraw explicitly. Interface Hierarchies with Default Implementations (New 8.0) public interface IDrawable Next, update the top-level statements to the following:<\/p>\n Console.WriteLine(" Simple Interface Hierarchy <\/em><\/strong><\/strong>"); Not only does this code compile, but it outputs a value of 5 for the TimeToDraw() method. This is because default implementations automatically carry forward to descendant interfaces. Casting the BitMapImage to the IAdvancedDraw interface provides access to the TimeToDraw() method, even though the BitMapImage instance does not have access to the default implementation. To prove this, enter the following code and see the compile error:<\/p>\n \/\/This does not compile myBitmap.TimeToDraw();<\/p>\n If a downstream interface wants to provide its own default implementation, it must hide the upstream implementation. For example, if the IAdvancedDraw TimeToDraw() method takes 15 units to draw, update the interface to the following definition:<\/p>\n public interface IAdvancedDraw : IDrawable Of course, the BitMapImage class is also free to implement the TimeToDraw() method. Unlike the public class BitmapImage : IAdvancedDraw When casting the BitmapImage instance to either the IAdvancedDraw or IDrawable interface, the method on the instance still is executed. Add this code to the top-level statements:<\/p>\n \/\/Always calls method on instance: Here are the results:<\/p>\n Simple Interface Hierarchy <\/em><\/strong><\/strong> Multiple Inheritance with Interface Types \/\/IDrawable.cs \/\/IPrintable.cs \/\/IShape.cs Figure 8-6 illustrates the current interface hierarchy.<\/p>\n Figure 8-6. Unlike classes, interfaces can extend multiple interface types<\/p>\n At this point, the million-dollar question is \u201cIf you have a class supporting IShape, how many methods will it be required to implement?\u201d The answer: it depends. If you want to provide a simple implementation of the Draw() method, you need to provide only three members, as shown in the following Rectangle type:<\/p>\n namespace MiInterfaceHierarchy; class Rectangle : IShape If you would rather have specific implementations for each Draw() method (which in this case would make the most sense), you can resolve the name clash using explicit interface implementation, as shown in the following Square type:<\/p>\n namespace MiInterfaceHierarchy; class Square : IShape public int GetNumberOfSides() => 4; Ideally, at this point you feel more comfortable with the process of defining and implementing custom interfaces using the C# syntax. To be honest, interface-based programming can take a while to get comfortable with, so if you are in fact still scratching your head just a bit, this is a perfectly normal reaction. The IEnumerable and IEnumerator Interfaces \/\/ Iterate over an array of items. int[] myArrayOfInts = {10, 20, 30, 40};<\/p>\n foreach(int i in myArrayOfInts) While it might seem that only array types can use this construct, the truth of the matter is any type supporting a method named GetEnumerator() can be evaluated by the foreach construct. To illustrate, begin by creating a new Console Application project named CustomEnumerator. Next, copy the Car.cs and Radio.cs files defined in the SimpleException example of Chapter 7 into the new project. Make sure to update the namespaces for the classes to CustomEnumerator. \/\/ Fill with some Car objects upon startup. public Garage() carArray[1] = new Car("Clunker", 55); carArray[2] = new Car("Zippy", 30); carArray[3] = new Car("Fred", 30); Ideally, it would be convenient to iterate over the Garage object\u2019s subitems using the foreach construct, just like an array of data values. Update the Program.cs file to the following:<\/p>\n using System.Collections; using CustomEnumerator;<\/p>\n \/\/ This seems reasonable ... \/\/ Hand over each car in the collection? foreach (Car c in carLot) Sadly, the compiler informs you that the Garage class does not implement a method named GetEnumerator(). This method is formalized by the IEnumerable interface, which is found lurking within the System.Collections namespace.<\/p>\n \u25a0Note in Chapter 10, you will learn about the role of generics and the System.Collections.Generic namespace. as you will see, this namespace contains generic versions of IEnumerable\/IEnumerator that provide a more type-safe way to iterate over items.<\/p>\n Classes or structures that support this behavior advertise that they can expose contained items to the caller (in this example, the foreach keyword itself). Here is the definition of this standard interface:<\/p>\n \/\/ This interface informs the caller As you can see, the GetEnumerator() method returns a reference to yet another interface named System.Collections.IEnumerator. This interface provides the infrastructure to allow the caller to traverse the internal objects contained by the IEnumerable-compatible container.<\/p>\n \/\/ This interface allows the caller to { If you want to update the Garage type to support these interfaces, you could take the long road and implement each method manually. While you are certainly free to provide customized versions of using System.Collections; namespace CustomEnumerator; public class Garage : IEnumerable public Garage() \/\/ Return the array object's IEnumerator. public IEnumerator GetEnumerator() After you have updated your Garage type, you can safely use the type within the C# foreach construct. Furthermore, given that the GetEnumerator() method has been defined publicly, the object user could also interact with the IEnumerator type.<\/p>\n \/\/ Manually work with IEnumerator. However, if you prefer to hide the functionality of IEnumerable from the object level, simply make use of explicit interface implementation.<\/p>\n \/\/ Return the array object's IEnumerator. IEnumerator IEnumerable.GetEnumerator() By doing so, the casual object user will not find the Garage\u2019s GetEnumerator() method, while the Building Iterator Methods with the yield Keyword public class Garage : IEnumerable public IEnumerator GetEnumerator() Notice that this implementation of GetEnumerator() iterates over the subitems using internal foreach logic and returns each Car to the caller using the yield return syntax. The yield keyword is used to specify the value (or values) to be returned to the caller\u2019s foreach construct. When the yield return statement is reached, the current location in the container is stored, and execution is restarted from this location the next time the iterator is called. public IEnumerator GetEnumerator() In this implementation, notice that the GetEnumerator() method is explicitly returning a new value to the caller with each pass through. Doing so for this example makes little sense, given that if you were to add more objects to the carArray member variable, your GetEnumerator() method would now be out of sync. Nevertheless, this syntax can be useful when you want to return local data from a method for processing by the foreach syntax.<\/p>\n Guard Clauses with Local Functions (New 7.0) To test this, update the GetEnumerator method to this:<\/p>\n public IEnumerator GetEnumerator() If you were to call the function like this and do nothing else, the exception will never be thrown:<\/p>\n using System.Collections; public IEnumerator GetEnumerator() Test this by updating the calling code to this:<\/p>\n Console.WriteLine(" Fun with the Yield Keyword <\/em><\/strong><\/strong>\\n"); Garage carLot = new Garage(); With the update to the GetEnumerator() method, the exception is thrown immediately instead of when Building a Named Iterator public IEnumerable GetTheCars(bool returnReversed) IEnumerable ActualImplementation() Notice that the new method allows the caller to obtain the subitems in sequential order, as well as in reverse order, if the incoming parameter has the value true. You could now interact with your new method as follows (be sure to comment out the throw new exception statement in the GetEnumerator() method):<\/p>\n Console.WriteLine(" Fun with the Yield Keyword <\/em><\/strong><\/strong>\\n"); Garage carLot = new Garage();<\/p>\n \/\/ Get items using GetEnumerator(). foreach (Car c in carLot) Console.WriteLine();<\/p>\n \/\/ Get items (in reverse!) using named iterator. As you might agree, named iterators are helpful constructs, in that a single custom container can define multiple ways to request the returned set. The ICloneable Interface namespace CloneablePoint; public Point(int xPos, int yPos) { X = xPos; Y = yPos;} public Point(){}<\/p>\n \/\/ Override Object.ToString(). Given what you already know about reference types and value types (see Chapter 4), you are aware that if you assign one reference variable to another, you have two references pointing to the same object in using CloneablePoint; When you want to give your custom type the ability to return an identical copy of itself to the caller, you may implement the standard ICloneable interface. As shown at the start of this chapter, this type defines a single method named Clone().<\/p>\n public interface ICloneable Obviously, the implementation of the Clone() method varies among your classes. However, the basic functionality tends to be the same: copy the values of your member variables into a new object instance of the same type and return it to the user. To illustrate, ponder the following update to the Point class:<\/p>\n \/\/ The Point now supports "clone-ability." public class Point : ICloneable public Point(int xPos, int yPos) { X = xPos; Y = yPos; } public Point() { }<\/p>\n \/\/ Override Object.ToString(). \/\/ Return a copy of the current object. In this way, you can create exact stand-alone copies of the Point type, as illustrated by the following code:<\/p>\n Console.WriteLine(" Fun with Object Cloning <\/em><\/strong><\/strong>\\n"); \/\/ Change p4.X (which will not change p3.X). p4.X = 0;<\/p>\n \/\/ Print each object. While the current implementation of Point fits the bill, you can streamline things just a bit. Because the Point type does not contain any internal reference type variables, you could simplify the implementation of the Clone() method as follows:<\/p>\n \/\/ Copy each field of the Point member by member. public object Clone() => this.MemberwiseClone();<\/p>\n Be aware, however, that if the Point did contain any reference type member variables, MemberwiseClone() would copy the references to those objects (i.e., a shallow copy). If you want to support a true deep copy, you will need to create a new instance of any reference type variables during the cloning process. Let\u2019s see an example next.<\/p>\n A More Elaborate Cloning Example namespace CloneablePoint; public PointDescription() The initial updates to the Point class itself included modifying ToString() to account for these new bits of state data, as well as defining and creating the PointDescription reference type. To allow the outside world to establish a pet name for the Point, you also update the arguments passed into the overloaded constructor.<\/p>\n public class Point : ICloneable public Point(int xPos, int yPos, string petName) \/\/ Override Object.ToString(). public override string ToString() \/\/ Return a copy of the current object. Notice that you did not yet update your Clone() method. Therefore, when the object user asks for a clone using the current implementation, a shallow (member-by-member) copy is achieved. To illustrate, assume you have updated the calling code as follows:<\/p>\n Console.WriteLine(" Fun with Object Cloning <\/em><\/strong><\/strong>\\n"); Console.WriteLine("Before modification:"); Console.WriteLine("p3: {0}", p3); Console.WriteLine("\\nChanged p4.desc.petName and p4.X"); Console.WriteLine("After modification:"); Console.WriteLine("p3: {0}", p3); Notice in the following output that while the value types have indeed been changed, the internal reference types maintain the same values, as they are \u201cpointing\u201d to the same objects in memory (specifically, note that the pet name for both objects is now \u201cMy new Point\u201d).<\/p>\n Fun with Object Cloning <\/em><\/strong><\/strong> Cloned p3 and stored new Point in p4 Before modification: p4: X = 100; Y = 100; Name = Jane; Changed p4.desc.petName and p4.X After modification: p4: X = 9; Y = 100; Name = My new Point; ID = 133d66a7-0837-4bd7-95c6-b22ab0434509<\/p>\n To have your Clone() method make a complete deep copy of the internal reference types, you need to configure the object returned by MemberwiseClone() to account for the current point\u2019s name (the System.Guid type is in fact a structure, so the numerical data is indeed copied). Here is one possible implementation:<\/p>\n \/\/ Now we need to adjust for the PointDescription member. public object Clone() \/\/ Then fill in the gaps. If you rerun the application once again and view the output (shown next), you see that the Point returned from Clone() does copy its internal reference type member variables (note the pet name is now unique for both p3 and p4).<\/p>\n Fun with Object Cloning <\/em><\/strong><\/strong> Cloned p3 and stored new Point in p4 Before modification: p4: X = 100; Y = 100; Name = Jane; Changed p4.desc.petName and p4.X After modification: p4: X = 9; Y = 100; Name = My new Point; ID = 0d3776b3-b159-490d-b022-7f3f60788e8a<\/p>\n To summarize the cloning process, if you have a class or structure that contains nothing but value types, implement your Clone() method using MemberwiseClone(). However, if you have a custom type that maintains other reference types, you might want to create a new object that considers each reference type member variable to get a \u201cdeep copy.\u201d<\/p>\n The IComparable Interface \/\/ This interface allows an object to specify its \u25a0Note The generic version of this interface (IComparable Create a new Console Application project named ComparableCar, copy the Car and Radio classes from the SimpleException example in Chapter 7, and rename the namespace for each file to ComparableCar. using System.Collections;<\/p>\n namespace ComparableCar; public class Car } CurrentSpeed = currSp; Now assume you have an array of Car objects as follows in your top-level statements: \/\/ Make an array of Car objects. Car[] myAutos = new Car[5]; myAutos[0] = new Car("Rusty", 80, 1); \/\/ Sort my cars? Not yet! Array.Sort(myAutos);<\/p>\n If you run this test, you would get a runtime exception, as the Car class does not support the necessary interface. When you build custom types, you can implement IComparable to allow arrays of your types to be sorted. When you flesh out the details of CompareTo(), it will be up to you to decide what the baseline of the ordering operation will be. For the Car type, the internal CarID seems to be the logical candidate.<\/p>\n \/\/ The iteration of the Car can be ordered As you can see, the logic behind CompareTo() is to test the incoming object against the current instance based on a specific point of data. The return value of CompareTo() is used to discover whether this type is less than, greater than, or equal to the object it is being compared with (see Table 8-1).<\/p>\n Table 8-1. CompareTo Return Values<\/p>\n Return Value Description You can streamline the previous implementation of CompareTo() given that the C# int data type (which is just a shorthand notation for System.Int32) implements IComparable. You could implement the Car\u2019s CompareTo() as follows:<\/p>\n int IComparable.CompareTo(object obj) In either case, so that your Car type understands how to compare itself to like objects, you can write the following user code:<\/p>\n \/\/ Exercise the IComparable interface. \/\/ Now, sort them using IComparable! Array.Sort(myAutos); Console.WriteLine();<\/p>\n \/\/ Display sorted array. Here is the output from the previous code listing:<\/p>\n Fun with Object Sorting <\/em><\/strong><\/strong> Here is the unordered set of cars: Here is the ordered set of cars: Specifying Multiple Sort Orders with IComparer \/\/ A general way to compare two objects. interface IComparer \u25a0Note The generic version of this interface (IComparer Unlike the IComparable interface, IComparer is typically not implemented on the type you are trying to sort (i.e., the Car). Rather, you implement this interface on any number of helper classes, one for each sort order (pet name, car ID, etc.). Currently, the Car type already knows how to compare itself against other cars based on the internal car ID. Therefore, allowing the object user to sort an array of Car objects by pet name will require an additional helper class that implements IComparer. Here is the code:<\/p>\n namespace ComparableCar; if (o1 is Car t1 && o2 is Car t2) The object user code can use this helper class. System.Array has several overloaded Sort() methods, one that just happens to take an object implementing IComparer.<\/p>\n ... \/\/ Dump sorted array. Console.WriteLine("Ordering by pet name:"); foreach(Car c in myAutos) Custom Properties and Custom Sort Types \/\/ We now support a custom property to return The object user code can now sort by pet name using a strongly associated property, rather than just \u201chaving to know\u201d to use the stand-alone PetNameComparer class type.<\/p>\n \/\/ Sorting by pet name made a bit cleaner. Array.Sort(myAutos, Car.SortByPetName);<\/p>\n Ideally, at this point you not only understand how to define and implement your own interfaces but also understand their usefulness. To be sure, interfaces are found within every major .NET Core namespace, and you will continue working with various standard interfaces in the remainder of this book.<\/p>\n Summary PART IV Advanced C# Programming CHAPTER 8 Working with Interfaces This chapter builds upon your current understanding of object-oriented development by examining the topic of interface-based programming. Here, you will learn how to define and implement interfaces and come to understand the benefits of building types that support multiple behaviors. Along the way, you will […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[22],"class_list":["post-304","post","type-post","status-publish","format-standard","hentry","category-csharp","tag-pro-csharp10-with-net6"],"_links":{"self":[{"href":"https:\/\/diji.net\/index.php?rest_route=\/wp\/v2\/posts\/304","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/diji.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/diji.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/diji.net\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/diji.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=304"}],"version-history":[{"count":0,"href":"https:\/\/diji.net\/index.php?rest_route=\/wp\/v2\/posts\/304\/revisions"}],"wp:attachment":[{"href":"https:\/\/diji.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=304"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/diji.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=304"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/diji.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=304"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nA. Troelsen and P. Japikse, Pro C# 10 with .NET 6, https:\/\/doi.org\/10.1007\/978-1-4842-7869-7_8<\/a><\/a><\/a><\/p>\n
\nIDbTransaction BeginTransaction();
\nIDbTransaction BeginTransaction(IsolationLevel il); void ChangeDatabase(string databaseName);
\nvoid Close();
\nIDbCommand CreateCommand(); void Open();
\n\/\/ Properties
\nstring ConnectionString { get; set;} int ConnectionTimeout { get; } string Database { get; } ConnectionState State { get; }
\n}<\/p>\n
\nAs you work through the remainder of this book, you will be exposed to dozens of interfaces that ship with the .NET Core base class libraries. As you will see, these interfaces can be implemented on your own custom classes and structures to define types that integrate tightly within the framework. As well, once you understand the usefulness of the interface type, you will certainly find reasons to build your own.<\/p>\n
\nGiven your work in Chapter 6, the interface type might seem somewhat like an abstract base class. Recall that when a class is marked as abstract, it may define any number of abstract members to provide a polymorphic interface to all derived types. However, even when a class does define a set of abstract members, it is also free to define any number of constructors, field data, nonabstract members (with
\nimplementation), and so on. Interfaces (prior to C# 8.0) contain only member definitions. Now, with C# 8, interfaces can contain member definitions (like abstract members), members with default implementations (like virtual methods), and static members. There are only two real differences: interfaces cannot have nonstatic constructors, and a class can implement multiple interfaces. More on this second point next.
\nThe polymorphic interface established by an abstract parent class suffers from one major limitation, in that only derived types support the members defined by the abstract parent. However, in larger software systems, it is common to develop multiple class hierarchies that have no common parent beyond System.
\nObject. Given that abstract members in an abstract base class apply only to derived types, you have no way
\nto configure types in different hierarchies to support the same polymorphic interface. To begin, create a new Console Application project named CustomInterfaces. Add the following abstract class to the project:<\/p>\n
\npublic abstract class CloneableType
\n{
\n\/\/ Only derived types can support this
\n\/\/ "polymorphic interface." Classes in other<\/p>\n
\n\/\/ member.
\npublic abstract object Clone();
\n}<\/p>\n
\n\/\/ for classes.
\npublic class MiniVan : Car, CloneableType
\n{
\n}<\/p>\n
\n{
\nobject Clone();
\n}<\/p>\n
\nTo get started, clear out the Program.cs code and add the following:<\/p>\n
\n{
\n\/\/ All of these classes support the ICloneable interface. string myStr = "Hello";
\nOperatingSystem unixOS = new OperatingSystem(PlatformID.Unix, new Version());
\n\/\/ Therefore, they can all be passed into a method taking ICloneable. CloneMe(myStr);<\/p>\n
\nstatic void CloneMe(ICloneable c)
\n{
\n\/\/ Clone whatever we get and print out the name. object theClone = c.Clone();
\nConsole.WriteLine("Your clone is a: {0}", theClone.GetType().Name);
\n}
\n}<\/p>\n
\nYour clone is a: OperatingSystem<\/p>\n
\n{
\n...
\n\/\/ Every derived class must now support this method! public abstract byte GetNumberOfPoints();
\n}<\/p>\n
\nNow that you better understand the overall role of interface types, let\u2019s see an example of defining and implementing custom interfaces. Copy the Shape.cs, Hexagon.cs, Circle.cs, and ThreeDCircle.cs files from the Shapes solution you created in Chapter 6. After you have done so, rename the namespace that defines your shape-centric types to CustomInterfaces (simply to avoid having to import namespace definitions in your new project). Now, insert a new file into your project named IPointy.cs.
\nAt a syntactic level, an interface is defined using the C# interface keyword. Unlike a class, interfaces never specify a base class (not even System.Object; however, as you will see later in this chapter, an interface can specify base interfaces). Prior to C# 8.0, the members of an interface never specify an access modifier (as all interface members are implicitly public and abstract). New in C# 8.0, private, internal, protected, and even static members can also be defined. More on this later. To get the ball rolling, here is a custom interface defined in C#:<\/p>\n
\n\/\/ This interface defines the behavior of "having points." public interface IPointy
\n{
\n\/\/ Implicitly public and abstract. byte GetNumberOfPoints();
\n}<\/p>\n
\nIPointy will result in various compiler errors:<\/p>\n
\npublic interface IPointy
\n{
\n\/\/ Error! Interfaces cannot have data fields! public int numbOfPoints;
\n\/\/ Error! Interfaces do not have nonstatic constructors! public IPointy() { numbOfPoints = 0;}
\n}<\/p>\n
\n{
\n\/\/ Implicitly public and abstract.
\n\/\/byte GetNumberOfPoints();<\/p>\n
\n\/\/string PropName { get; set; }<\/p>\n
\n}<\/p>\n
\nWhen a class (or structure) chooses to extend its functionality by supporting interfaces, it does so using a comma-delimited list in the type definition. Be aware that the direct base class must be the first item listed after the colon operator. When your class type derives directly from System.Object, you are free to simply list the interface (or interfaces) supported by the class, as the C# compiler will extend your types
\nfrom System.Object if you do not say otherwise. On a related note, given that structures always derive from System.ValueType (see Chapter 4), simply list each interface directly after the structure definition. Ponder the following examples:<\/p>\n
\n\/\/ implements a single interface. public class Pencil : IPointy
\n{...}<\/p>\n
\n\/\/ and implements a single interface. public class SwitchBlade : object, IPointy
\n{...}<\/p>\n
\n\/\/ and implements a single interface. public class Fork : Utensil, IPointy
\n{...}<\/p>\n
\n\/\/ implements two interfaces.
\npublic struct PitchFork : ICloneable, IPointy
\n{...}<\/p>\n
\nthe IDbConnection interface shown earlier), the type is now responsible for fleshing out the details of all ten abstract members.<\/p>\n
\nNote that the implementation of the read-only Points property (implemented using the expression-bodied member syntax) simply returns the correct number of points (three).<\/p>\n
\n\/\/ New Shape derived class named Triangle. class Triangle : Shape, IPointy
\n{
\npublic Triangle() { }
\npublic Triangle(string name) : base(name) { } public override void Draw()
\n{
\nConsole.WriteLine("Drawing {0} the Triangle", PetName);
\n}<\/p>\n
\n\/\/public byte Points
\n\/\/{
\n\/\/ get { return 3; }
\n\/\/}
\npublic byte Points => 3;
\n}<\/p>\n
\n\/\/ Hexagon now implements IPointy. class Hexagon : Shape, IPointy
\n{
\npublic Hexagon(){ }
\npublic Hexagon(string name) : base(name){ } public override void Draw()
\n{
\nConsole.WriteLine("Drawing {0} the Hexagon", PetName);
\n}<\/p>\n
\npublic byte Points => 6;
\n}<\/p>\n
\nNow that you have some classes that support the IPointy interface, the next question is how you interact with the new functionality. The most straightforward way to interact with functionality supplied by a given interface is to invoke the members directly from the object level (provided the interface members are not implemented explicitly; you can find more details later in the section \u201cExplicit Interface Implementation\u201d). For example, consider the following code:<\/p>\n
\n\/\/ Call Points property defined by IPointy. Hexagon hex = new Hexagon(); Console.WriteLine("Points: {0}", hex.Points); Console.ReadLine();<\/p>\n
\nOne way to determine at runtime whether a type supports a specific interface is to use an explicit cast. If the type does not support the requested interface, you receive an InvalidCastException. To handle this possibility gracefully, use structured exception handling as in the following example:<\/p>\n
\n\/\/ Catch a possible InvalidCastException. Circle c = new Circle("Lisa");
\nIPointy itfPt = null; try
\n{
\nitfPt = (IPointy)c; Console.WriteLine(itfPt.Points);
\n}
\ncatch (InvalidCastException e)
\n{
\nConsole.WriteLine(e.Message);
\n}
\nConsole.ReadLine();<\/p>\n
\nYou can determine whether a given type supports an interface by using the as keyword, introduced in Chapter 6. If the object can be treated as the specified interface, you are returned a reference to the interface in question. If not, you receive a null reference. Therefore, be sure to check against a null value before proceeding.<\/p>\n
\n\/\/ Can we treat hex2 as IPointy? Hexagon hex2 = new Hexagon("Peter"); IPointy itfPt2 = hex2 as IPointy; if(itfPt2 != null)
\n{
\nConsole.WriteLine("Points: {0}", itfPt2.Points);
\n}
\nelse
\n{
\nConsole.WriteLine("OOPS! Not pointy...");
\n}
\nConsole.ReadLine();<\/p>\n
\nYou may also check for an implemented interface using the is keyword (also first discussed in Chapter 6). If the object in question is not compatible with the specified interface, you are returned the value false. If you supply a variable name in the statement, the type is assigned into the variable, eliminating the need to do the type check and perform a cast. The previous example is updated here:<\/p>\n
\n...
\nif(hex2 is IPointy itfPt3)
\n{
\nConsole.WriteLine("Points: {0}", itfPt3.Points);
\n}
\nelse
\n{
\nConsole.WriteLine("OOPS! Not pointy...");
\n}
\nConsole.ReadLine();<\/p>\n
\nAs mentioned earlier, C# 8.0 added the ability for interface methods and properties to have a default implementation. Add a new interface named IRegularPointy to represent a regularly shaped polygon. The code is shown here:<\/p>\n
\n{
\nint SideLength { get; set; } int NumberOfSides { get; set; }
\nint Perimeter => SideLength * NumberOfSides;
\n}<\/p>\n
\nIRegularPointy interface, as follows:<\/p>\n
\nclass Square: Shape,IRegularPointy
\n{
\npublic Square() { }
\npublic Square(string name) : base(name) { }
\n\/\/Draw comes from the Shape base class public override void Draw()
\n{
\nConsole.WriteLine("Drawing a square");
\n}<\/p>\n
\npublic int NumberOfSides { get; set; }
\n\/\/Note that the Perimeter property is not implemented
\n}<\/p>\n
\nThe Perimeter property, defined on the IRegularPointy interface, is not defined in the Square class, making it inaccessible from an instance of Square. To see this in action, create a new instance of a Square class and output the relevant values to the console, like this:<\/p>\n
\n...
\nvar sq = new Square("Boxy")
\n{NumberOfSides = 4, SideLength = 4}; sq.Draw();
\n\/\/This won't compile
\n\/\/Console.WriteLine($"{sq.PetName} has {sq.NumberOfSides} of length {sq.SideLength} and a perimeter of {sq.Perimeter}");<\/p>\n
\nWhile this is a trivial example, it does demonstrate one of the problems with default interfaces. Before using this feature in your code, make sure you measure the implications of the calling code having to know where the implementation exists.<\/p>\n
\nAnother addition to interfaces in C# 8.0 is the ability to have static constructors and members, which function the same as static members on class definitions but are defined on interfaces. Update the IRegularPointy interface with an example static property and a static constructor.<\/p>\n
\n{
\nint SideLength { get; set; } int NumberOfSides { get; set; }
\nint Perimeter => SideLength * NumberOfSides;<\/p>\n
\n}<\/p>\n
\nConsole.WriteLine($"Example property: {IRegularPointy.ExampleProperty}");<\/p>\n
\nGiven that interfaces are valid types, you may construct methods that take interfaces as parameters, as illustrated by the CloneMe() method earlier in this chapter. For the current example, assume you have defined another interface named IDraw3D.<\/p>\n
\n\/\/ Models the ability to render a type in stunning 3D. public interface IDraw3D
\n{
\nvoid Draw3D();
\n}<\/p>\n
\nclass ThreeDCircle : Circle, IDraw3D
\n{
\n...
\npublic void Draw3D()
\n=> Console.WriteLine("Drawing Circle in 3D!"); }
\n}<\/p>\n
\n{
\n...
\npublic void Draw3D()
\n=> Console.WriteLine("Drawing Hexagon in 3D!");
\n}<\/p>\n
\n{
\nConsole.WriteLine("-> Drawing IDraw3D compatible type"); itf3d.Draw3D();
\n}<\/p>\n
\n...
\nShape[] myShapes = { new Hexagon(), new Circle(), new Triangle("Joe"), new Circle("JoJo") } ;
\nfor(int i = 0; i < myShapes.Length; i++)
\n{
\n\/\/ Can I draw you in 3D?
\nif (myShapes[i] is IDraw3D s)
\n{
\nDrawIn3D(s);
\n}
\n}<\/p>\n
\n...
\n-> Drawing IDraw3D compatible type Drawing Hexagon in 3D!<\/p>\n
\nInterfaces can also be used as method return values. For example, you could write a method that takes an array of Shape objects and returns a reference to the first item that supports IPointy.<\/p>\n
\n\/\/ array that implements IPointy.
\nstatic IPointy FindFirstPointyShape(Shape[] shapes)
\n{
\nforeach (Shape s in shapes)
\n{
\nif (s is IPointy ip)
\n{
\nreturn ip;
\n}
\n}
\nreturn null;
\n}<\/p>\n
\n...
\n\/\/ Make an array of Shapes.
\nShape[] myShapes = { new Hexagon(), new Circle(),
\nnew Triangle("Joe"), new Circle("JoJo")};<\/p>\n
\nIPointy firstPointyItem = FindFirstPointyShape(myShapes);
\n\/\/ To be safe, use the null conditional operator. Console.WriteLine("The item has {0} points", firstPointyItem?.Points);<\/p>\n
\nRecall that the same interface can be implemented by numerous types, even if they are not within the same class hierarchy and do not have a common parent class beyond System.Object. This can yield some powerful programming constructs. For example, assume you have developed three new class types<\/p>\n
\nnamespace CustomInterfaces; class Fork : IPointy
\n{
\npublic byte Points => 4;
\n}
\n\/\/PitchFork.cs
\nnamespace CustomInterfaces; class PitchFork : IPointy
\n{
\npublic byte Points => 3;
\n}
\n\/\/Knife.cs.cs
\nnamespace CustomInterfaces; class Knife : IPointy
\n{
\npublic byte Points => 1;
\n}<\/p>\n
\n\/\/ This array can only contain types that
\n\/\/ implement the IPointy interface.
\nIPointy[] myPointyObjects = {new Hexagon(), new Knife(), new Triangle(), new Fork(), new PitchFork()};<\/p>\n
\n{
\nConsole.WriteLine("Object has {0} points.", i.Points);
\n}
\nConsole.ReadLine();<\/p>\n
\nAlthough interface-based programming is a powerful technique, implementing interfaces may entail a healthy amount of typing. Given that interfaces are a named set of abstract members, you are required to type in the definition and implementation for each interface method on each type that supports the behavior. Therefore, if you want to support an interface that defines a total of five methods and three properties, you need to account for all eight members (or else you will receive compiler errors).
\nAs you would hope, Visual Studio and Visual Studio Code both support various tools that make the task of implementing interfaces less burdensome. By way of a simple test, insert a final class into your current project named PointyTestClass. When you add an interface such as IPointy (or any interface for that matter) to a class type, you might have noticed that when you complete typing the interface\u2019s name (or when you position the mouse cursor on the interface name in the code window), Visual Studio and Visual Studio Code both add a lightbulb, which can also be invoked with the Ctrl+period (.) key combination. When you click the lightbulb, you will be presented with a drop-down list that allows you to implement the interface (see Figures 8-4 and 8-5).<\/p>\n
\nStudio\/Visual Studio Code has generated stub code for you to update. (Note that the default implementation throws a System.NotImplementedException, which can obviously be deleted.)<\/p>\n
\n{
\npublic byte Points => throw new NotImplementedException();
\n}<\/p>\n
\nAs shown earlier in this chapter, a class or structure can implement any number of interfaces. Given this, there is always the possibility you might implement interfaces that contain identical members and,
\ntherefore, have a name clash to contend with. To illustrate various manners in which you can resolve this issue, create a new Console Application project named InterfaceNameClash. Now design three interfaces that represent various locations to which an implementing type could render its output.<\/p>\n
\n\/\/ Draw image to a form. public interface IDrawToForm
\n{
\nvoid Draw();
\n}<\/p>\n
\n\/\/ Draw to buffer in memory. public interface IDrawToMemory<\/p>\n
\nvoid Draw();
\n}<\/p>\n
\n\/\/ Render to the printer. public interface IDrawToPrinter
\n{
\nvoid Draw();
\n}<\/p>\n
\nclass Octagon : IDrawToForm, IDrawToMemory, IDrawToPrinter
\n{
\npublic void Draw()
\n{
\n\/\/ Shared drawing logic. Console.WriteLine("Drawing the Octagon...");
\n}
\n}<\/p>\n
\n\/\/ same Draw() method!<\/p>\n
\n\/\/ the interface variable for later use.
\n((IDrawToPrinter)oct).Draw();<\/p>\n
\nif (oct is IDrawToMemory dtm)
\n{
\ndtm.Draw();
\n}<\/p>\n
\n{
\n\/\/ Explicitly bind Draw() implementations
\n\/\/ to a given interface.
\nvoid IDrawToForm.Draw()
\n{
\nConsole.WriteLine("Drawing to form...");
\n}
\nvoid IDrawToMemory.Draw()
\n{
\nConsole.WriteLine("Drawing to memory...");
\n}
\nvoid IDrawToPrinter.Draw()
\n{
\nConsole.WriteLine("Drawing to a printer...");
\n}
\n}<\/p>\n
\n{
\nConsole.WriteLine("Drawing to form...");
\n}<\/p>\n
\n\/\/ members.
\nIDrawToForm itfForm = (IDrawToForm)oct; itfForm.Draw();<\/p>\n
\n\/\/ the interface variable for later use.
\n((IDrawToPrinter)oct).Draw();<\/p>\n
\nif (oct is IDrawToMemory dtm)
\n{
\ndtm.Draw();
\n}
\nConsole.ReadLine();<\/p>\n
\nHowever, those who require the more advanced behaviors can extract the desired interface via an explicit cast.<\/p>\n
\nInterfaces can be arranged in an interface hierarchy. Like a class hierarchy, when an interface extends an existing interface, it inherits the abstract members defined by the parent (or parents). Prior to C# 8, derived interfaces never inherit true implementation. Rather, a derived interface simply extends its own definition with additional abstract members. In C# 8, derived interfaces inherit the default implementations as well as extend the definition and potentially add new default implementations.
\nInterface hierarchies can be useful when you want to extend the functionality of an existing interface without breaking existing code bases. To illustrate, create a new Console Application project named InterfaceHierarchy. Now, let\u2019s design a new set of rendering-centric interfaces such that IDrawable is the root of the family tree.<\/p>\n
\n{
\nvoid Draw();
\n}<\/p>\n
\npublic interface IAdvancedDraw : IDrawable
\n{
\nvoid DrawInBoundingBox(int top, int left, int bottom, int right); void DrawUpsideDown();
\n}<\/p>\n
\npublic class BitmapImage : IAdvancedDraw
\n{
\npublic void Draw()
\n{
\nConsole.WriteLine("Drawing...");
\n}
\npublic void DrawInBoundingBox(int top, int left, int bottom, int right)
\n{
\nConsole.WriteLine("Drawing in a box...");
\n}
\npublic void DrawUpsideDown()
\n{
\nConsole.WriteLine("Drawing upside down!");
\n}
\n}<\/p>\n
\npublic), as well as extract a reference to each supported interface explicitly via casting.<\/p>\n
\nConsole.WriteLine(" Simple Interface Hierarchy <\/em><\/strong><\/strong>");
\n\/\/ Call from object level.
\nBitmapImage myBitmap = new BitmapImage(); myBitmap.Draw(); myBitmap.DrawInBoundingBox(10, 10, 100, 150); myBitmap.DrawUpsideDown();<\/p>\n
\nif (myBitmap is IAdvancedDraw iAdvDraw)
\n{
\niAdvDraw.DrawUpsideDown();
\n}
\nConsole.ReadLine();<\/p>\n
\nWhen interface hierarchies also include default implementations, downstream interfaces can choose to carry the implementation from the base interface or create a new default implementation. Update the IDrawable interface to the following:<\/p>\n
\n{
\nvoid Draw();
\nint TimeToDraw() => 5;
\n}<\/p>\n
\n...
\nif (myBitmap is IAdvancedDraw iAdvDraw)
\n{
\niAdvDraw.DrawUpsideDown();
\nConsole.WriteLine($"Time to draw: {iAdvDraw.TimeToDraw()}");
\n}
\nConsole.ReadLine();<\/p>\n
\n{
\nvoid DrawInBoundingBox(
\nint top, int left, int bottom, int right); void DrawUpsideDown();
\nnew int TimeToDraw() => 15;
\n}<\/p>\n
\nIAdvancedDraw TimeToDraw() method, the class only needs to implement the method, not hide it.<\/p>\n
\n{
\n...
\npublic int TimeToDraw() => 12;
\n}<\/p>\n
\nConsole.WriteLine(" Calling Implemented TimeToDraw <\/em><\/strong><\/strong>"); Console.WriteLine($"Time to draw: {myBitmap.TimeToDraw()}"); Console.WriteLine($"Time to draw: {((IDrawable) myBitmap).TimeToDraw()}"); Console.WriteLine($"Time to draw: {((IAdvancedDraw) myBitmap).TimeToDraw()}");<\/p>\n
\n...
\n Calling Implemented TimeToDraw <\/em><\/strong><\/strong> Time to draw: 12
\nTime to draw: 12 Time to draw: 12<\/p>\n
\nUnlike class types, an interface can extend multiple base interfaces, allowing you to design some powerful and flexible abstractions. Create a new Console Application project named MiInterfaceHierarchy. Here is another collection of interfaces that model various rendering and shape abstractions. Notice that the IShape interface is extending both IDrawable and IPrintable.<\/p>\n
\nnamespace MiInterfaceHierarchy;
\n\/\/ Multiple inheritance for interface types is A-okay. interface IDrawable
\n{
\nvoid Draw();
\n}<\/p>\n
\nnamespace MiInterfaceHierarchy; interface IPrintable
\n{
\nvoid Print();
\nvoid Draw(); \/\/ <-- Note possible name clash here!
\n}<\/p>\n
\nnamespace MiInterfaceHierarchy;
\n\/\/ Multiple interface inheritance. OK! interface IShape : IDrawable, IPrintable
\n{
\nint GetNumberOfSides();
\n}<\/p>\n
\n{
\npublic int GetNumberOfSides() => 4;
\npublic void Draw() => Console.WriteLine("Drawing..."); public void Print() => Console.WriteLine("Printing...");
\n}<\/p>\n
\n{
\n\/\/ Using explicit implementation to handle member name clash. void IPrintable.Draw()
\n{
\n\/\/ Draw to printer ...
\n}
\nvoid IDrawable.Draw()
\n{
\n\/\/ Draw to screen ...
\n}
\npublic void Print()
\n{
\n\/\/ Print ...
\n}<\/p>\n
\n}<\/p>\n
\nDo be aware, however, that interfaces are a fundamental aspect of the .NET Core Framework.
\nRegardless of the type of application you are developing (web-based, desktop GUIs, data access libraries, etc.), working with interfaces will be part of the process. To summarize the story thus far, remember that interfaces can be extremely useful in the following cases:
\n\u2022You have a single hierarchy where only a subset of the derived types supports a common behavior.
\n\u2022You need to model a common behavior that is found across multiple hierarchies with no common parent class beyond System.Object.
\nNow that you have drilled into the specifics of building and implementing custom interfaces, the remainder of this chapter examines several predefined interfaces contained within the .NET Core base class libraries. As you will see, you can implement standard .NET Core interfaces on your custom types to ensure they integrate into the framework seamlessly.<\/p>\n
\nTo begin examining the process of implementing existing .NET Core interfaces, let\u2019s first look at the role of IEnumerable and IEnumerator. Recall that C# supports a keyword named foreach that allows you to iterate over the contents of any array type.<\/p>\n
\n{
\nConsole.WriteLine(i);
\n}<\/p>\n
\nNow, insert a new class named Garage that stores a set of Car objects within a System.Array. using System.Collections;
\nnamespace CustomEnumerator;
\n\/\/ Garage contains a set of Car objects. public class Garage
\n{
\nprivate Car[] carArray = new Car[4];<\/p>\n
\n{
\ncarArray[0] = new Car("Rusty", 30);<\/p>\n
\n}
\n}<\/p>\n
\nConsole.WriteLine(" Fun with IEnumerable \/ IEnumerator <\/em><\/strong><\/strong>\\n"); Garage carLot = new Garage();<\/p>\n
\n{
\nConsole.WriteLine("{0} is going {1} MPH", c.PetName, c.CurrentSpeed);
\n}
\nConsole.ReadLine();<\/p>\n
\n\/\/ that the object's items can be enumerated. public interface IEnumerable
\n{
\nIEnumerator GetEnumerator();
\n}<\/p>\n
\n\/\/ obtain a container's items. public interface IEnumerator<\/p>\n
\nbool MoveNext (); \/\/ Advance the internal position of the cursor. object Current { get;} \/\/ Get the current item (read-only property). void Reset (); \/\/ Reset the cursor before the first member.
\n}<\/p>\n
\nGetEnumerator(), MoveNext(), Current, and Reset(), there is a simpler way. As the System.Array type (as well as many other collection classes) already implements IEnumerable and IEnumerator, you can simply delegate the request to the System.Array as follows (note you will need to import the System.Collections namespace into your code file):<\/p>\n
\n{
\n\/\/ System.Array already implements IEnumerator! private Car[] carArray = new Car[4];<\/p>\n
\n{
\ncarArray[0] = new Car("FeeFee", 200); carArray[1] = new Car("Clunker", 90); carArray[2] = new Car("Zippy", 30); carArray[3] = new Car("Fred", 30);
\n}<\/p>\n
\n=> carArray.GetEnumerator();
\n}<\/p>\n
\nIEnumerator carEnumerator = carLot.GetEnumerator(); carEnumerator.MoveNext();
\nCar myCar = (Car)i.Current;
\nConsole.WriteLine("{0} is going {1} MPH", myCar.PetName, myCar.CurrentSpeed);<\/p>\n
\n=> return carArray.GetEnumerator();<\/p>\n
\nforeach construct will obtain the interface in the background when necessary.<\/p>\n
\nThere is an alternative way to build types that work with the foreach loop via iterators. Simply put, an iterator is a member that specifies how a container\u2019s internal items should be returned when processed by foreach. To illustrate, create a new Console Application project named CustomEnumeratorWithYield and insert the Car, Radio, and Garage types from the previous example (again, renaming your namespace definitions to the current project). Now, retrofit the current Garage type as follows:<\/p>\n
\n{
\n...
\n\/\/ Iterator method.<\/p>\n
\n{
\nforeach (Car c in carArray)
\n{
\nyield return c;
\n}
\n}
\n}<\/p>\n
\nIterator methods are not required to use the foreach keyword to return its contents. It is also permissible to define this iterator method as follows:<\/p>\n
\n{
\nyield return carArray[0]; yield return carArray[1]; yield return carArray[2]; yield return carArray[3];
\n}<\/p>\n
\nNone of the code in the GetEnumerator() method is executed until the first time that the items are iterated over (or any element is accessed). That means if there is an exception prior to the yield statement, it will not get thrown when the method is first called, but only when the first MoveNext() is called.<\/p>\n
\n{
\n\/\/This will not get thrown until MoveNext() is called throw new Exception("This won't get called");
\nforeach (Car c in carArray)
\n{
\nyield return c;
\n}
\n}<\/p>\n
\n...
\nConsole.WriteLine(" Fun with the Yield Keyword <\/em><\/strong><\/strong>\\n"); Garage carLot = new Garage();
\nIEnumerator carEnumerator = carLot.GetEnumerator(); Console.ReadLine();
\nIt is not until MoveNext() is called that the code will execute, and the exception is thrown. Depending on the needs of your program, that might be perfectly fine. But it might not. Your GetEnumerator method might have a guard clause that needs to execute when the method is first called. For example, suppose that the list is gathered from a database. You might want to check that the database connection can be opened at the time the method is called, not when the list is iterated over. Or you might want to check the input parameters to the Iterator method (covered next) for validity.
\nRecall from Chapter 4 the C# 7 local function feature; local functions are private functions inside other functions. By moving the yield return into a local function that is returned from the main body of the method, the code in the top-level statements (before the local function is returned) is executed immediately. The local function is executed when MoveNext() is called.
\nUpdate the method to this:<\/p>\n
\n{
\n\/\/This will get thrown immediately
\nthrow new Exception("This will get called"); return ActualImplementation();
\n\/\/this is the local function and the actual IEnumerator implementation IEnumerator ActualImplementation()
\n{
\nforeach (Car c in carArray)
\n{
\nyield return c;
\n}
\n}
\n}<\/p>\n
\ntry
\n{
\n\/\/Error at this time
\nvar carEnumerator = carLot.GetEnumerator();
\n}
\ncatch (Exception e)
\n{
\nConsole.WriteLine($"Exception occurred on GetEnumerator");
\n}
\nConsole.ReadLine();<\/p>\n
\nMoveNext() is called.<\/p>\n
\nIt is also interesting to note that the yield keyword can technically be used within any method, regardless of its name. These methods (which are technically called named iterators) are also unique in that they can take any number of arguments. When building a named iterator, be aware that the method will return the IEnumerable interface, rather than the expected IEnumerator-compatible type. To illustrate, you could add the following method to the Garage type (using a local function to encapsulate the iteration functionality):<\/p>\n
\n{
\n\/\/do some error checking here return ActualImplementation();<\/p>\n
\n{
\n\/\/ Return the items in reverse. if (returnReversed)
\n{
\nfor (int i = carArray.Length; i != 0; i--)
\n{
\nyield return carArray[i - 1];
\n}
\n}
\nelse
\n{
\n\/\/ Return the items as placed in the array. foreach (Car c in carArray)
\n{
\nyield return c;
\n}
\n}
\n}
\n}<\/p>\n
\n{
\nConsole.WriteLine("{0} is going {1} MPH", c.PetName, c.CurrentSpeed);
\n}<\/p>\n
\nforeach (Car c in carLot.GetTheCars(true))
\n{
\nConsole.WriteLine("{0} is going {1} MPH", c.PetName, c.CurrentSpeed);
\n}
\nConsole.ReadLine();<\/p>\n
\nSo, to wrap up this look at building enumerable objects, remember that for your custom types to work with the C# foreach keyword, the container must define a method named GetEnumerator(), which has been formalized by the IEnumerable interface type. The implementation of this method is typically achieved by simply delegating it to the internal member that is holding onto the subobjects; however, it is also possible to use the yield return syntax to provide multiple \u201cnamed iterator\u201d methods.<\/p>\n
\nAs you might recall from Chapter 6, System.Object defines a method named MemberwiseClone(). This method is used to obtain a shallow copy of the current object. Object users do not call this method directly, as it is protected. However, a given object may call this method itself during the cloning process. To illustrate, create a new Console Application project named CloneablePoint that defines a class named Point.<\/p>\n
\n\/\/ A class named Point. public class Point
\n{
\npublic int X {get; set;} public int Y {get; set;}<\/p>\n
\npublic override string ToString() => $"X = {X}; Y = {Y}";
\n}<\/p>\n
\nmemory. Thus, the following assignment operation results in two references to the same Point object on the heap; modifications using either reference affect the same object on the heap:<\/p>\n
\nConsole.WriteLine(" Fun with Object Cloning <\/em><\/strong><\/strong>\\n");
\n\/\/ Two references to same object! Point p1 = new Point(50, 50); Point p2 = p1;
\np2.X = 0;
\nConsole.WriteLine(p1); Console.WriteLine(p2); Console.ReadLine();<\/p>\n
\n{
\nobject Clone();
\n}<\/p>\n
\n{
\npublic int X { get; set; } public int Y { get; set; }<\/p>\n
\npublic override string ToString() => $"X = {X}; Y = {Y}";<\/p>\n
\npublic object Clone() => new Point(this.X, this.Y);
\n}<\/p>\n
\n...
\n\/\/ Notice Clone() returns a plain object type.
\n\/\/ You must perform an explicit cast to obtain the derived type. Point p3 = new Point(100, 100);
\nPoint p4 = (Point)p3.Clone();<\/p>\n
\nConsole.WriteLine(p3);
\nConsole.WriteLine(p4);
\nConsole.ReadLine();<\/p>\n
\nNow assume the Point class contains a reference type member variable of type PointDescription. This class maintains a point\u2019s friendly name as well as an identification number expressed as a System.Guid (a globally unique identifier [GUID] is a statistically unique 128-bit number). Here is the implementation:<\/p>\n
\n\/\/ This class describes a point. public class PointDescription
\n{
\npublic string PetName {get; set;} public Guid PointID {get; set;}<\/p>\n
\n{
\nPetName = "No-name"; PointID = Guid.NewGuid();
\n}
\n}<\/p>\n
\n{
\npublic int X { get; set; } public int Y { get; set; }
\npublic PointDescription desc = new PointDescription();<\/p>\n
\n{
\nX = xPos; Y = yPos; desc.PetName = petName;
\n}
\npublic Point(int xPos, int yPos)
\n{
\nX = xPos; Y = yPos;
\n}
\npublic Point() { }<\/p>\n
\n=> $"X = {X}; Y = {Y}; Name = {desc.PetName};\\nID = {desc.PointID}\\n";<\/p>\n
\npublic object Clone() => this.MemberwiseClone();
\n}<\/p>\n
\n...
\nConsole.WriteLine("Cloned p3 and stored new Point in p4"); Point p3 = new Point(100, 100, "Jane");
\nPoint p4 = (Point)p3.Clone();<\/p>\n
\nConsole.WriteLine("p4: {0}", p4); p4.desc.PetName = "My new Point"; p4.X = 9;<\/p>\n
\nConsole.WriteLine("p4: {0}", p4); Console.ReadLine();<\/p>\n
\np3: X = 100; Y = 100; Name = Jane;
\nID = 133d66a7-0837-4bd7-95c6-b22ab0434509<\/p>\n
\nID = 133d66a7-0837-4bd7-95c6-b22ab0434509<\/p>\n
\np3: X = 100; Y = 100; Name = My new Point; ID = 133d66a7-0837-4bd7-95c6-b22ab0434509<\/p>\n
\n{
\n\/\/ First get a shallow copy.
\nPoint newPoint = (Point)this.MemberwiseClone();<\/p>\n
\nPointDescription currentDesc = new PointDescription(); currentDesc.PetName = this.desc.PetName;
\nnewPoint.desc = currentDesc; return newPoint;
\n}<\/p>\n
\np3: X = 100; Y = 100; Name = Jane;
\nID = 51f64f25-4b0e-47ac-ba35-37d263496406<\/p>\n
\nID = 0d3776b3-b159-490d-b022-7f3f60788e8a<\/p>\n
\np3: X = 100; Y = 100; Name = Jane;
\nID = 51f64f25-4b0e-47ac-ba35-37d263496406<\/p>\n
\nThe System.IComparable interface specifies a behavior that allows an object to be sorted based on some specified key. Here is the formal definition:<\/p>\n
\n\/\/ relationship between other like objects. public interface IComparable
\n{
\nint CompareTo(object o);
\n}<\/p>\n
\nUpdate the Car class by adding a new property to represent a unique ID for each car and a modified constructor:<\/p>\n
\n{
\n.
\npublic int CarID {get; set;}
\npublic Car(string name, int currSp, int id)
\n{<\/p>\n
\n...
\n}<\/p>\n
\nPetName = name;
\nCarID = id;<\/p>\n
\nglobal using System.Collections; using ComparableCar;
\nConsole.WriteLine(" Fun with Object Sorting <\/em><\/strong><\/strong>\\n");<\/p>\n
\nmyAutos[1] = new Car("Mary", 40, 234);
\nmyAutos[2] = new Car("Viper", 40, 34);
\nmyAutos[3] = new Car("Mel", 40, 4);
\nmyAutos[4] = new Car("Chucky", 40, 5); Console.ReadLine();
\nThe System.Array class defines a static method named Sort(). When you invoke this method on an array of intrinsic types (int, short, string, etc.), you can sort the items in the array in numeric\/alphabetic order, as these intrinsic data types implement IComparable. However, what if you were to send an array of Car types into the Sort() method as follows?<\/p>\n
\n\/\/ based on the CarID.
\npublic class Car : IComparable
\n{
\n...
\n\/\/ IComparable implementation.
\nint IComparable.CompareTo(object obj)
\n{
\nif (obj is Car temp)
\n{
\nif (this.CarID > temp.CarID)
\n{
\nreturn 1;
\n}
\nif (this.CarID < temp.CarID)
\n{
\nreturn -1;
\n}
\nreturn 0;
\n}
\nthrow new ArgumentException("Parameter is not a Car!");
\n}
\n}<\/p>\n
\nAny number less than zero This instance comes before the specified object in the sort order.
\nZero This instance is equal to the specified object.
\nAny number greater than zero This instance comes after the specified object in the sort order.<\/p>\n
\n{
\nif (obj is Car temp)
\n{
\nreturn this.CarID.CompareTo(temp.CarID);
\n}
\nthrow new ArgumentException("Parameter is not a Car!");
\n}<\/p>\n
\n\/\/ Make an array of Car objects.
\n...
\n\/\/ Display current array.
\nConsole.WriteLine("Here is the unordered set of cars:"); foreach(Car c in myAutos)
\n{
\nConsole.WriteLine("{0} {1}", c.CarID, c.PetName);
\n}<\/p>\n
\nConsole.WriteLine("Here is the ordered set of cars:"); foreach(Car c in myAutos)
\n{
\nConsole.WriteLine("{0} {1}", c.CarID, c.PetName);
\n}
\nConsole.ReadLine();<\/p>\n
\n1 Rusty
\n234 Mary
\n34 Viper
\n4Mel
\n5Chucky<\/p>\n
\n1 Rusty
\n4Mel
\n5Chucky
\n34 Viper
\n234 Mary<\/p>\n
\nIn this version of the Car type, you used the car\u2019s ID as the base for the sort order. Another design might have used the pet name of the car as the basis for the sorting algorithm (to list cars alphabetically). Now, what if you wanted to build a Car that could be sorted by ID as well as by pet name? If this is the type of behavior you are interested in, you need to make friends with another standard interface named IComparer, defined within the System.Collections namespace as follows:<\/p>\n
\n{
\nint Compare(object o1, object o2);
\n}<\/p>\n
\n\/\/ This helper class is used to sort an array of Cars by pet name. public class PetNameComparer : IComparer
\n{
\n\/\/ Test the pet name of each object.
\nint IComparer.Compare(object o1, object o2)
\n{<\/p>\n
\n{
\nreturn string.Compare(t1.PetName, t2.PetName, StringComparison.OrdinalIgnoreCase);
\n}
\nelse
\n{
\nthrow new ArgumentException("Parameter is not a Car!");
\n}
\n}
\n}<\/p>\n
\n\/\/ Now sort by pet name. Array.Sort(myAutos, new PetNameComparer());<\/p>\n
\n{
\nConsole.WriteLine("{0} {1}", c.CarID, c.PetName);
\n}
\n...<\/p>\n
\nIt is worth pointing out that you can use a custom static property to help the object user along when sorting your Car types by a specific data point. Assume the Car class has added a static read-only property named SortByPetName that returns an instance of an object implementing the IComparer interface (PetNameComparer, in this case; be sure to import System.Collections).<\/p>\n
\n\/\/ the correct IComparer interface. public class Car : IComparable
\n{
\n...
\n\/\/ Property to return the PetNameComparer. public static IComparer SortByPetName
\n=> (IComparer)new PetNameComparer();}<\/p>\n
\nAn interface can be defined as a named collection of abstract members. It is common to regard an interface as a behavior that may be supported by a given type. When two or more classes implement the same interface, you can treat each type the same way (interface-based polymorphism) even if the types are defined within unique class hierarchies.
\nC# provides the interface keyword to allow you to define a new interface. As you have seen, a type can support as many interfaces as necessary using a comma-delimited list. Furthermore, it is permissible to build interfaces that derive from multiple base interfaces.
\nIn addition to building your custom interfaces, the .NET Core libraries define several standard (i.e., framework-supplied) interfaces. As you have seen, you are free to build custom types that implement these predefined interfaces to gain several desirable traits such as cloning, sorting, and enumerating.<\/p>\n","protected":false},"excerpt":{"rendered":"