Multi-Dimensional Separation of Concerns is more useful and can easily be modelled in standard oo without tools.
In a game for example you can have three dimensions, data, features and system dimensions. Where each is a folder hierarchy in your solution. Here you use the standard oo cross dimension with interfaces. Like system dimension export interface IGUI which exposes return actions and info functions that features and the data dimension classes can implement.
But you can also make a feature cross dimensional by using partial classes. So if you want to add a new feature, let's say Move you add a behaviour class in the feature dimension, in a new folder, which implements interfaces from the system dimension like Igui and Igamestate and uses a TroopDataClass from the data dimension.
Then you make a new folder in the data dimension and make a partial class for TroopDataClass where you add move based data like petrol. Now that whole feature is isolated, you can easily remove both Move folders and nothing will break everything will compile just as before.
The advantage is that you get rid of the spiderweb dependencies you get if Move where a standard class with combined data and behaviour.
For data that still is feature crosscutting like ActionPoint or Position on the map, you can still use inheritance and standard oo techniques within the Data dimension, so TroopDataClass inherits from MapObjectClass or something similar, then all features will have access to them.
Or you could use mixin layers or virtual classes, or open class patterns. There is literally a million ways to do this. Today, I use partial classes and approximated mixins (C# doesn't have real mixins).
Comments
Multi-Dimensional Separation of Concerns is more useful and can easily be modelled in standard oo without tools. In a game for example you can have three dimensions, data, features and system dimensions. Where each is a folder hierarchy in your solution. Here you use the standard oo cross dimension with interfaces. Like system dimension export interface IGUI which exposes return actions and info functions that features and the data dimension classes can implement.
But you can also make a feature cross dimensional by using partial classes. So if you want to add a new feature, let's say Move you add a behaviour class in the feature dimension, in a new folder, which implements interfaces from the system dimension like Igui and Igamestate and uses a TroopDataClass from the data dimension. Then you make a new folder in the data dimension and make a partial class for TroopDataClass where you add move based data like petrol. Now that whole feature is isolated, you can easily remove both Move folders and nothing will break everything will compile just as before.
The advantage is that you get rid of the spiderweb dependencies you get if Move where a standard class with combined data and behaviour. For data that still is feature crosscutting like ActionPoint or Position on the map, you can still use inheritance and standard oo techniques within the Data dimension, so TroopDataClass inherits from MapObjectClass or something similar, then all features will have access to them.
http://www.cs.bilkent.edu.tr/~bedir/CS586-AOSD/Syllabus/NDeg...
Or you could use mixin layers or virtual classes, or open class patterns. There is literally a million ways to do this. Today, I use partial classes and approximated mixins (C# doesn't have real mixins).