Feralidragon wrote:A "prototype" however actually configures and "implements" that "component", meaning that all the methods for implementation are defined in that prototype.
Then, upon a "component" instantiation, you just provide the "prototype" you want it to use (as an instance or the class itself), and that "prototype" then shapes up the "component" from within, without the "component" itself looking any different from outside when used in any given context.
I've done this before in my own code, based off the Strategy Pattern. The only real difference seems to be that instead of implementing a single method, you provide implementation to a set of multiple methods. State and Command patterns are also considerably similar to what you describe, but still technically different. It's almost a shock the Gang of Four never formalized it as its own pattern.
Buff Skeleton wrote:I have to wonder about the SRP vs. Actor god-class architecture now. Why do you think Actor was written this way? Inexperience? Or was there maybe a legit reason for it?
To expand a bit on what Feralidragon said: the fundamental principles and assumptions of OOP as they were clarified in the 80s and 90s were later found to be limited in certain ways after many years of practical application, especially in gameplay programming.
One of the observed tendencies in some large OO projects, before alternative strategies (like SOLID) became ubiquitous, was that common behavior and data members would "float" into classes higher in single-inheritance hierarchies over time in order to give a wider pool of derived classes access to them; Unreal's Object->Actor->...->etc. configuration is a good example of this. You'll also see this in subsections of the hierarchy, such as the bCanSwim flag in pawns to which the concept of 'swimming' doesn't apply. Whether "SwimmingPawns" should be a thing quickly becomes an obvious "no", considering flying, climbing, hanging, etc. creatures might be added to the game at a later date.
Multiple-inheritance is a (flawed IMHO) move towards being able to mix new interfaces and behavior into classes, but there are performance and abstraction costs that go along with it, which largely make it inadequate in the eyes of serious system programmers concerned with performance and robustness.
As touched on already, there is a quasi-theoretical paradigm,
Entity-Component architecture, which has been attempted several times in games, showing up as early as
Thief: The Dark Project, and which is today approximated in both UE4 and Unity. The general consensus is that a "perfected" or definitive implementation hasn't yet been achieved, the major shortcomings cited being performance- and implementation-related. But it's an interesting topic, and has gotten a lot of praise from game development houses who've given it a modest shot, and found it to have a considerable payoff for design flexibility and convenience in contrast to OOP.
That being said, techniques like SOLID have been helpful in making the more established OOP approach more palatable for long-term game projects.