Ok, we’ve already talked about the fact that Designs have a name and a collection of Rules. They also have another very important feature called Mixins. For those of you who are programmers, Mixins are our way of implementing multiple inheritance.
For those who are not generally familiar with inheritance, and for those who may know about other forms of inheritance and want to know how kBridge inheritance work s,we’ll provide some additional explanation, but first, let’s talk about why we have inheritance at all.
Inheritance
Remember we mentioned that a Design is generally a collection of Rules that represent a coherent grouping that work together or make sense together – a single conceptual entity. Our Table Top, for example has all of the information about being a table top collected into one place:
•Length
•Width
•Height
•Thickness
•Location
•Orientation
•Material Type
•Modulus of Elasticity
•Density
•Hardness
But whoa, wait a minute. Those last four things: Material Type, Modulus of Elasticity, Density, and Hardness are all properties of the material being used in the Table Top. Other parts that have a material might need to share those same Rules. There is, in fact, a conceptual grouping of Rules for the material that is independent of the grouping for the table top. If we define them all together as part of the table top, then we’ll also have to define those material Rules for other parts made of the same material, like the leg, even though the Rules may be the same.
Avoiding Duplication with Mixins
As a general practice, in kBridge we strive to avoid any duplication. If we write a Rule once, then we should use that Rule everywhere without duplicating it. Elimination of duplication ensures that future maintenance of the Rule will be easy – we only need to change it or update it in one place. It also ensures that the Rule will be used consistently, and maybe most importantly, it enables us to share it with others.
So, another way to approach our table top Design is to separate out the Rules that are associated with the material into another Design and then Mixin that Design to table and inherit all the material Rules.
This process of identifying common elements that can be removed to a single entity that can be shared via inheritance is called abstraction and it is a very powerful concept to keep in mind as you create Designs and Rules.
So, when our Table Top Design mixes in the Material Design, it acquires (or inherits) all the Rules that were defined in the Material Design.
Note that if Table Top Design, for example, has its own Rule for Modulus of Elasticity, then that Rule from Material will not be inherited; it is overridden by the Rule in Table Top.
Multiple Inheritance
In fact, a Design can have a whole list of other Designs that are mixed into it. This is called multiple inheritance and the sequence of the inheritance list determines which Rule, ultimately, is the one that gets used in the Design. The Rules from Designs higher in the Mixin list take precedence over, or override, Rules of the same name from Designs later in the list. This gives us a powerful way to reuse Rules from other Designs, but also to selectively override them if desired.
