Interfaces Not Required — RubyHACK 2018

Editor's Notes

• #4: Interfaces are the intended means of interaction between different parts of a software system. Sometimes Interfaces are expressed formally, and enforced via compile-time checks. But, there are lots of places where Interfaces are much less formal. In Ruby we have no formal interfaces. There’s no language-level mechanism to tell us that some class will expose certain methods or attributes. And, while advocates of stronger typing think this is a detriment, I’m not convinced.
• #5: Formal Interfaces provide a level of safety. They allow a for level of assurance to be given that classes that implement the same Interface are somewhat similar. But, in every formal Interface the guarantees are around type safety. Let’s take a look at two examples of such formal Interface definitions.
• #6: So, looking at these we can ask what do we gain from either of these interfaces? We know that whatever implements these Interfaces will have to provide a set of three methods with specific signatures. They’ll be expected to take certain types of arguments and return certain types. And, that’s what we get. We get some type safety. So, that’s cool. But, there’s a lot more to most software than strict type safety. Type safety only protects against erroneous behavior arising from issues involving incorrect types. But, that constitutes potentially only the most basic facet of erroneous behavior within a software system. So, at least in my estimation, I don’t see the type of safety afforded by formal Interfaces to be that valuable.
• #7: In more strongly typed languages, Interfaces act to extend the protections of the type system. In Ruby we can approximate these kinds of protections. But, if we want to enforce types our code can quickly become dense and unfriendly. When I think about Interfaces I don’t want just type safety, I want behavioral safety. I want to be able to specify that two classes behave the same way, and that goes beyond what formal interfaces afford. What I want from interfaces is to be able to describe what I think my duck should be able to do. So, let’s consider an example case.
• #8: So, for our example case, let’s specify some behavior. I want to define a basic Repository interface that can be applied to any number of Repositories for different Entities. For those unfamiliar with the Repository Pattern, it is a way to abstract data access in a way such that your application works with simpler objects representing your business concerns, rather than more complex objects that know how to store and retrieve themselves via built-in understanding of the data access layer. The Repository Pattern is often used as an alternative to the Active Record, and Data Mapper patterns, which are all defined more thoroughly in the book Patterns of Enterprise Application Architecture. So, getting back to our example. The first thing we want is to define that a Repository in our system provides three methods. [CLICK] Find by ID, Create and Update. These are essentially the same three methods we were essentially working with in our earlier examples, except because we are in Ruby we can loosen up our Interface in ways that hopefully will demonstrates the benefits of our less formal approach. Second, [CLICK] we want Find By ID to return either nil or the Entity that our Repository is responsible for. Now we’re specifying some more flexible notions of behavior. We’re only going a little further than what our formal Interfaces afforded us, but the lack of their rigidity is going to show up again in how we specify the behavior of our other two methods. Third, [CLICK] we want the Create method to return either an integer ID for the created Entity, or false. And, finally [CLICK] we want the Update method to return either an integer ID for the updated Entity, or false. In these last two cases we are able to leverage Ruby’s flexible notion of truthiness to our advantage. But, our specification really only restates what the formal Interfaces provided but with Ruby’s flexibility brought into the picture. But, this is not the end of what behavior I want to specify for a Repository.
• #9: I also want to specify that if I create an Entity via the Repository [CLICK] I can then use the returned Integer in Find By ID to get back the object with matching attributes to what I put in. And, [CLICK] I want essentially the same behavior to work with the Repository’s Update method. Now we have a mental model for our Interface, but how do we define such a thing? We’ve now gone well beyond what any formal Interface is going to provide us. So, how can we make our specification a reality? — That question’s not rhetorical… TESTS. We need to write tests. We can achieve the assurances of both formal Interfaces and our behavioral desires by converting these specifications into tests. Now, I am going to use RSpec to demonstrate this, you can do all this with MiniTest.
• #10: So, here is the start of our Interface specification in RSpec. [CLICK] We’ve got three basic examples where we say that we expect the three methods to exist that we talked about earlier. We’re defining Subject for convenience since we want to call methods directly on the Repository class, rather than instantiating an instance. And, the Invalid Entity we setup will come up later. At this point we have a really rudimentary specification for our Interface. And we could use it like the following. [CLICK] We don’t have the same level of protection as afforded by a formal interface, but we can get there.
• #11: Let’s add some additional safety for the Create method first. [CLICK] Now you can see where we are making use of the Invalid Entity we defined before. We expect that if we pass that to our Create method we will get back nil. Our implementation will now have to handle being given objects that are not the type they expect and to do something, in this case return nil. The internals could be more complicated, but for our example this will suffice. Additionally, we expect to get back an integer for the entity we just created when a Valid Entity is supplied. But, where does this Valid Entity come from? We haven’t defined it anywhere yet, and this is where I think RSpec’s shared examples demonstrate some particular elegance. We can update our Business Repository spec to supply what the shared examples need.
• #12: [CLICK] We can nest a Let call that defines the additional context our shared examples need, in this case a valid instance of the Business class. We’ll leverage more of this capability in a bit. But, now we have some more safety in our specification. We can now trust that when Business Repository receives a Valid Entity to the Create method it will return an integer value, and if it receives an Invalid Entity it will return nil. We could even define a repository specific Invalid Entity alongside our Valid Entity to better describe what being Invalid means in context.
• #13: Now we can add similar safety checks to our Update method. [CLICK] Again, we’re relying on our definitions of a Valid and Invalid Entity to specify how we want our repositories to behave. For update we want to ensure that the returned integer value from our Update method matches the ID value already set on the Entity that is being updated. Now, we’re reaching inside the Entity to set the ID in a way that is not desirable, but for our example it keeps things simple. The last bit of safety checks we need is around Find By ID.
• #14: [CLICK] This example does not address type constraints, but we certainly could. In cases like this I would tend to go with an implementation that relies on type coercion so that anything that can have TO_I called on it is acceptable. But, this covers the behavior we want. So, now we have roughly equivalent safety checks to what a formal Interface gives us, and we’re ready to address what Interfaces can not. So, let’s review the behavioral specifications we have not covered.
• #15: We want to be sure that the integer values that come back from the Create and Update methods can be used with Find By ID to properly retrieve the expected Entity. So, our next sets of tests are going to address the interaction between the Create and Update methods and how Find By ID is expected to work.
• #16: First, we will address Find By ID’s behavior after entity creation. [CLICK] We invoke the Create method with our Valid Entity and capture the returned ID for that entity. Then we call Find By ID with that ID and store off the returned entity. Then we assert that the ID of the entity we found matches the ID that was returned by the Create method. We can’t compare the Found Entity to the Valid Entity because we are not assuming that the Valid Entity will be modified. This gives us assurance that formal Interfaces can not. We now have behavioral characteristics that are important to what our interface does and means, not just what the defined methods accept and return. This is why I don’t think formal interfaces are a necessary language feature for Ruby. We can achieve more robust results through good testing. We don’t need to embrace the rigidity of a stronger type system to be safe, and through robust testing we can weave the concerns over type into our behavioral specifications, which are richer and more expressive anyways. But, let’s finish up the example by looking at the relationship between Find By ID and the Update method.
• #17: In our final example [CLICK] we go through the dance of creating an entity, calling a lambda our more specific context will have to provide, updating our entity in the repository and then performing a check against what Find By ID returns and the entity we modified. The change entity lambda can be supplied to the shared example in the same manned as the valid entity, so we won’t look at it. But, again, we are able to encapsulate a robust test of our interfaces important behavior. We could also add more granular checks to ensure stricter typing for what the Find By ID method returns. But, given the interplay between the context the shared example is used in and the tests in the shared example the value would come from only from verbosity, not from additional assurances. With that I want to return to a question I posed earlier.
• #18: What do we want from interfaces? If all we want is type safety, we can get that from tests. And, if we focus our tests around behavior, we can actually achieve a richer model and more meaningful specifications around our informal interfaces than any formal interface is able to provide. This is some of why I still love Ruby after over 12 years of using it. I don’t need to craft my code for the ease of the compiler. I can achieve as much safety as I need, and define as much flexibility as I want through specifying behavior as tests. I don’t need the strictures of a strongly typed language, or the formality of interfaces to ensure interoperability. I can ensure more than what those mechanisms afford by writing what amounts to executable documentation.
• #19: Thank you for being here at RubyHACK and for coming to my talk. Here are details on me. And, I’m happy to take any questions.