1. OO Design, Usage and Implementation Inheritance and Pluggin Based Patterns and Roxy

2. Reference This talk is loosely based on the following
My code project articles Software Design Principles and Patterns in Pictures and Separation of Concerns and Smart Mixins with the help of Roxy IoC Container and Code Generator
Roxy IoC container and Code Generator available on GITHUB
Some, yet unpublished material

3. Engineering – the art of putting building blocks together

4. Object Oriented Programming and Design
Object oriented building blocks are classes.
Each programming unit – package or class has two sides to it – the usage and implementation side.
Usage side is determined by the public interface of the programming unit (package or class) which specifies how the it can be used by other.
Implementation side determines how that programming unit is implemented.
In OO languages Usage Side is provided by interfaces.

5. Concerns
Each Interface and Class have multiple concerns depending on how the object is being used: oncernsTest/MultiConcernsTest/ViewModels/PersonVM.cs. PersonVM (view model) class has selectable, removable, notifiable and data concerns to it.
Java, C# are very good at merging usage concerns– similar named events, properties and methods with same signatures will be merged into the same entities within the sub-interface. However there is no way to merge implementations. Even C++ multi-inheritance not adequate
There is no merging
You cannot replace implementation at run time

6. Swiss Cheese Diagram
The holes are unimplemented functionality determined by interfaces or abstract members. Semi-holes are virtual functionality.
Filling out the holes (merging the implementations) should be almost as easy as merging interfaces.

7. Plugin Pattern
Plugin the functionality into the “holes” within the Swiss Cheese diagram. Each plugin is represented by an object contained within the whole class. Each plugin – plugs in one or several holes within the swiss cheese diagram. The interface functionality is implemented by wrapping methods, properties and events of the plugin. Sometimes the wrapper has the same name as the plugin and sometimes it is different. In GangOf4 book Plugin called Strategy.

8. Patterns Implemented Using Plugin (on top of Strategy)
Wrapper/Adapter
Proxy

9. Bridge

10. Composite Reuse Pattern
Composite Reuse Pattern is synonymous to Plugin – wraps objects and calls methods on that object.

11. Main Problems with Implementation Concerns Merging using Plugins (Composite Reuse Pattern)
Perfectly implementable but requires a lot of extra repetitious code for wrapping the functionality.

12. How Multiple (Plugin Based) Implementation Inheritance Should Work
public class PersonVM :
implements ISelectableItem<PersonVM> by SelectableItem<PersonVM> as TheSelectableItem,
Implements IRemovable by Removable as TheRemovable
Implements IPersonData by PersonData { }
or, perhaps the following:
implements ISelectableItem<PersonVM>, IRemovable, IPersonData
by Selectable<PersonVM> as TheSelectableItem,
Removable as TheRemovable,
PersonData
Second way is, perhaps preferable, since it does not require the implementations to match the interfaces.

13. The “as <name>” parts are optional and only serve to allow the multiple super-plugins of the same type.
The plugins can be accessed within the class implementation either by “as” name or (if they do not have “as” name – then by “base.<type>”:
public class PersonVM :
implements ISelectableItem<PersonVM>, IRemovable, IPersonData
by Selectable<PersonVM> as TheSelectableItem,
Removable as TheRemovable,
PersonData {
public void ToggleSelection() =>
TheSelectableItem.IsItemSelected = !TheSelectableItem.IsItemSelected;
public void FullName =>
base.PersonData.FirstName + “ “ + base.PersonData.LastName }
IsItemSelected within ToggleSelection() method is accessed via “as” name and FirstName and LastName properties within FullName implementation are accessed via base.PersonData (PersonData is the base type).

14. Merging Rules
What if events or properties of the same name or methods of the same signature exist in several super-plugin. There are special merging rules that need to be implemented and for the lack of space within this presentation, they’ll be described in the full article to be published this month on the code project.

15. Roxy Mixins Implementation
I had doubts that the language changes will be spread fast within the developer community (even though I can modify Roslyn to add those changes to both the language and the VisualStudio IDE). The reason is that the language changes is a very serious matter and probably not many teams will be happy to try it.
Because of that, as a first step, I implemented the ideas presented above as an IoC container and generator Roxy. IoC container take care of creating objects (because of that the actual types of the objects can be spoofed and modified). This allowed creating the plugin mixins similar to those described above.

16. Small Roxy Example
As we remember, our class PersonVM contains the following concerns:
Selectable
Removable
PersonData

17. Here is the explanation of the generic type arguments to this method:
Here is an example of how these concerns can be mixed together using Roxy:
The most important method that creates the type configuration is Core.FindOrCreateTypeConfig<…>()
Here is the explanation of the generic type arguments to this method:
ISelectableRemovablePerson is the interface that merges all the Usage concerns for our PersonVM object.
PersonDataVM – is the C# super class that contains the Data concern
ISelectableRemovablePersonWrapper determines the merging of the Implementation concerns for PersonVM object.

18. ISelectableRemovablePersonWrapper In Detail
ISelectableRemovablePersonWrapper corresponds to the implementation (highlighted in bold) part of the multiple plugin inheritance statement:
public class PersonVM :
implements ISelectableItem<PersonVM>, IRemovable, IPersonData
by Selectable<PersonVM> as TheSelectableItem,
Removable as TheRemovable,
PersonData

19. Here is the interface with explanations:
Note that PersonDataVM part does not have to be part of the interface – we implement it using C# inheritance.

20. Full Article Coming
In near future I plan to publish a codeproject article detailing all the concepts described in this presentation.