Unite Austin 2017 - S.O.L.I.D. Unity
ฝัง
- เผยแพร่เมื่อ 29 ก.ย. 2024
- S.O.L.I.D. is a collection of 5 programming principles that allow you to build larger applications, while keeping the code maintainable, flexible and, in general, with fewer bugs. The business world has enjoyed this in many languages for many years, but may seem impossible in Unity. Productive Edge explains what each of the five principles mean, along with examples, and most importantly, how to apply them in your own Unity coding.
This talk also covers two great features as part of S.O.L.I.D. First, the use of DLL's instead of Scripts (optional), which allow you to add Unit Tests via MSTest or NUnit. Normally, this is impossible because of Unity's object duality (.NET/C++) throwing errors outside of Unity, but this talk teaches you how to get around that. Second, how to implement a Dependency Injection system, similar to Ninject, but designed for Unity, without requiring the designers to understand DI programming.
Dan Sagmiller (Senior VR Solutions Architect, Productive Edge)
Can't thank you enough for this video. I've been practicing a lot of these principles, but didn't realize they had a name. Also can't emphasize easily testable code enough. Especially for complex systems like combat, inventory, quests, maps, ect.
//SOLID PRINCIPLES
7:14 - (D) Dependency Inversion Principle
12:58 - (I) Interface Segregation Principle
17:08 - (S) Single Responsibility Principle
20:45 - (O) Open Closed Principle
26:51 - (L) Liskov Substitution Principle
//OTHER STUFF
31:47 - Dependency Injection
48:00 - Unit Testing
1:00:27 - Q&A
I enjoyed the talk until the DI part. Unity already has dependency injection, which wasn't mentioned, so this sort of comes off as an ad for your system. We are using DI every time we access service locators like Find, GetComponent, or simply drag and drop something into a serialized field. Generally, when objects create objects, most DI systems use factories, and there's nothing stopping you from simply coding one up in Unity or just using instantiate, which is already mostly the same thing, and follows solid principals as it doesn't care what you are instantiating.
With a third party DI framework, not only are you adding redundant features, but you usually find yourself stuck maintaining a long master list of objects to inject, and that maintenance requires constant updating with every new feature, (which goes against solid), and because games are dynamic, you often end up filling this list with logic to get the appropriate object, which can end up centralizing weird responsibility that shouldn't be there. From a designer point of view, opening up and editing the list is less intuitive than dragging and dropping what they need into an editor slot on the same component that needs something. Sure, you can at least avoid logic in your master list by generating everything through factories, but that brings us back to ruining designer friendliness as we quickly slide down the rabbit hole of generating everything.
DI frameworks are great outside of Unity, and I like them for unit testing, but IMHO in Unity they ultimately cause more issues than they solve.
It sort of was an ad as I was hoping to gain some popularity for pushing DI, but more so, it was intended as a demonstration of a type of system someone could apply. I provided the full source code to it, so people could take what they wanted. I don't even use that specific system any more. I still use pieces of it, but presently find my self with a service locator as well. :)
As mentioned on another talk on this channel, ScriptableObjects actually kind of do the job of Dependency Injection and can work well within Unity. Not a silver bullet, but something to consider.
SOLID makes everything sound easier and more organized and feels like something I can do. But every time dependency injection comes up, it has the complete opposite feeling. Unity doesn't support it? I must download some package of the asset store? I have to go through this complex setup? It just feels like the most unnatural solution to a problem which still isn't clear to me.
The pen clicks are strong with this one.
Great talk, though!
its a stylus. I have spoken.
Would be nicer if the sound's louder, kinda hard to be heard using the max volume on my MacBook.
That's a pretty nice presentation! Even if you know most of the stuff already, it was still really interesting. He mentioned also nice examples.
This is absolutely fantastic. I was creating a MonoBehaviour mock in order to get my code tested in VS. This example helps me a lot. This is what software architecture is all about ! Thanks Dan !
I found this talk really good until the dependacy injection I found it extremely confusing and mostly inapplicable, does anyone know of any detailed tutorials on dependacy injection maybe then I will understand what he was talking about and how it can be used practically
I just finished a 3 months-long game as a first year project. This was my first serious experience with programming a game from start to finish, and I ended up with a CharacterController script that had more than 3500 lines of code. But the worst of it was that I told myself "this is ok, my script only does one thing : handling the player's logic"... I wish I had watched this video sooner, it would have saved me hours of pain. Actually, I watched some of them (like "Game Architecture with ScriptableObjects" or "Writing High Performance C# Scripts") but was not able to understand them at all, whereas now it feels all clear and what they says instantly clicks in my head. So I guess that those months of intensive game programming, even though they ended up with such a huge fail, were not all for nothing !
I wish I had seen this talk a year ago, it's one of the best on the topic I have seen. Some of the principles I already knew about, some of them I had reached on my own, but I hadn't heard the acronym in a while. Last time I heard of it was years ago and I wasn't really complete enough in my knowledge and experience to appreciate all of it. Putting names to some of these principles really helps keep them in mind...
nice! very important knowledge! just that the volume is a bit soft
Finally, someone who explains it with simple examples, instead of trying to make an entire game out of it.
This talks are just gold, pure gold, thank you people who permit all of this to exist!
Does his ocp example violates lsp right there is two variable float width that he is not even using in his circle class he could have used other oops principle right just my thought?
Awesome speech and even better presentation. The way the material is presented is just great. The structure, visuals. Everything is clear and on point. You can see the amount of work, that was put in preparation for this. Thank you!
Ah, 2017... Back when things weren't fkd up....... sigh
This was infuriating to watch. I hate Bob. He has given me anxiety.
Hi,
Currently i'm working only on a little-mid size projects in Unity but i'm really interested on how use your SOLID pattern in my works... but the end on the panel i think is too fast for me to understand how to implement the DI in Unity (im a DI noob) and online i cannot find a good starting point for me.
I think that a tutorial about that will be great... there aren't many good tutorials about design patterns in Unity3D.
I'm trying to apply those principles in Unity and C# regarding my background with Java and I was struggling with some points. Your presentantion made a lot of things clear for me. The programming world should thank you for this nice presentation! Congratulations Dan!
MonoBehaviour class'ına ait herhangi bir metod ya da field kullanırsan abstract class kullanarak abstraction yap. Eğer MonoBehavior'a ait hiçbir şey yoksa interface kullan.
Clearly something out of 2017
Great job with these practical examples, fantastic presentation, it helped a lot!
This is why I think Unity should try to change the language of how they talk about their engine. Calling it "scripting" is a nice way to lure people in if you're afraid of them seeing the word "programming" or "code" and running away to Unreal, but...people also need to understand that they are PROGRAMMING when they are "scripting" in Unity. These are classes inheriting from the Unity library. They need to be treated as such.
And now in 2021 Unity introduced visual scripting out of the box. That makes things even more complicated (despite their intentions to make them feel easier)
I only have one question, how can anyone consider solid is good if ANYONE working on it takes 5 times more than doing it without it and later they use may be one or 2? they will take less time to rewrite it fully each time.
As of today there are DI frameworks that work inside Unity like Zenject and VContainer (the latter used in the Boss Room sample project)
Best video i've ever seen.
Very well and clean explaining.
what is the difference between DIP and OCP?
I find it hard to understand about their difference too
honestly, they are SO CLOSE that I think its ridiculous to include both. Their purposes are arguably different but finding an example of problem and solution for one, in pretty much every case I could find, the other principal also solved (as mentioned)
I think SOLID should probably be updated. these principals for "simplicity" are marred with complexity in explanation.
@@dvsdev yeah i think the acronym is a bit bloated because multiple people talked about the same thing in different words, and they put them all together (and they probably wanted a logical word as the acronym lol)
Zenject is nice DI Framework for unity.
I agree. I've used that before, but it does have the limitation of working inside Unity only. I.e. if you are developing unit tests in Visual Studio, it doesn't help. (I could be wrong, and if I am, please let me know. I'd love to find out there are more systems for this.)
there is a version of Zenject designed to work with pure c# projects outside of unity
It's better than StrangeIoC, I had a problem with that can't recall what it was.
But overall it would be great if the guys at Unity developed their own solution.
I originally used StrangeIoC before switching to Zenject. The simplicity of injecting into monobehaviours, plus it has a handy feature of loading child context by scene contract name (something I had to build myself in Strange) led me to make the switch.
I've learned a decent amount more about Zenject since creating this. I spent at least 16 hours trying out Zenject, but everything I was finding at the time was based on UI setups in Unity. Zenject is great. I have a few disagreements with some of its design, but in general I think it is excellent. The majority of this presentation still works. Everything on SOLID in specific.
He summarizes every principle in a single sentence. Amazing. I didn't expect that, seeing the length of the video. Great work. Thank you
am i right, when i think, that the recently released new Unity ECS is following these principles in a pretty good way? At least i can spot the SRP, OCP, and DIP in these new way of writing code....
Wow. To the point. Very helpful. Exactly what I need.
Thanks Dan.
Everything this guy has described, Java's JDK follows adamantly, which is why I'm a fan of the language.
Vol is xtremelly low
Hopefully this will help Unity developers figure out the basics of programming.
This video is so quiet for some reason. Even with my bluetooth ear piece in as opposed to speakers on my laptop, with everything on max its still hard to hear.
Recomendations for talks like this? Anyone, please
Compiler interpretation
Great presentation! I pulled the SOLID git project, and it looks like something is missing when I open "Chain Reaction Solid.sln"? The project is completely empty. When I open "ChainReaction.sln" in the VS subfolder it seems fine, but the project can't compile as it cannot find the UnityEngine type or namespace. I reimported everything in Unity but without any success. Could it be that the project won't work with current Unity version 2017.3?
You need to open the solution in the same disk you installed Unity on. If you really want to store it on another disk, just modify the .csproj files and change the filepath to the Unity DLLs.
The Single Responsiblity Principle (SRP) defines not "a single reason for failure" but a "single reason to change" and that has a completly different implication. While this is an extremly basic oop-talk it might not matter for most viewers, but especially when you read Uncle Bob's books about SOLID it makes a difference. A single reason for failure would also be almost impossible to implement - even when following clean code practices as extreme as Bob advocates it in some of his clean code books.
OOP creates more troubles than it solves.
Great talk
thank you
awsome!
17:08
when are you ever going to use width and height for a circle though?
I've only used something like that in C#/XNA. In Unity, I use the collision detection systems provided, so it is automatically detecting between a circular collider and a rectangle for me. But in XNA I faced almost this exact issue. While I feel my intent was clear, I completely agree with you: This example is not a common one. I was trying to find a good example to use for this, and that was the best I could come up with at the time. I'm very open to other suggestions. Perhaps NPC's and then extending that, except this new type of NPC would violate the nature of how a feature works. But I'm having trouble thinking up a specific problem right now. :( Any suggestions?
i kinda hate these oversimplified examples, in the case of shapes and areas, there is no reason not to just make an entirely new script without inheritance. i think oversimplifying it to this degree makes the lesson almost worthless.
Way too basic OOP principles.
Why is the way he holds the tablet and plays with the pen so annoying?
Because reminds you of Steve Jobs?