And with that, all SOLID principles are done.If anyone has any doubts, or even any criticism, either on the principles themselves or how I explained them, or any mistakes I may have made, please do not be afraid, just go ahead and ask or tell whichever is in your mind.

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.

Jet v4.3.5 wrote: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.

Yeah, those patterns sound close to this, but like you said, they're still quite different, so they don't really fit in the end.

When I came up with it, my first thought and action was to search for it since I was fully convinced it had already some kind of name (more often than not, an original idea is not original at all ), and I wanted to use the correct names for the classes and such, because it was just too obvious and useful, moreso than most design patterns out there I would say, and I was stumped when I was unable to find an actual pattern which described it.

On the other hand, I don't really see anyone using this sort of thing, at least in PHP from which I looked at the most, and which tends to have a wider variety of design patterns used due to its own flexibility. It feels like that, since it's not perhaps recognized as a pattern (yet at least), no one knows it so no one uses it, because it's not a "common pattern" yet perhaps.

Or maybe it has some kind of huge flaw to it to make it an anti-pattern instead? Although this is unlikely since I am using it to build a private (for now) REST framework which, thanks to this "pattern", it became exceedingly powerful and very easy to change anything, and to implement anything (and which is already being used to implement new APIs at where I work).

Either way, it's something that can be used in UnrealScript directly, which if coupled with "interface packages" (something I may also talk about in the future, but from the name I think it's clear what I mean), makes any new mod or addon something stupidly easy to make and update, and even refactor, without breaking anything else for anyone.