#begin

It’s just a view

Next we will dive into a section called “It’s just a view”. In this section they mainly focus on creating architectural boundaries between presentation and business code. One, if not, the most well known pattern to achieve this is the model-view-controller (MVC) pattern, which they will also describe in the book. David and Andrew mention that from the moment you start your software engineering education or career you are thought not to write code as a single big chuck. We aught to separate code into modules which each have their own well-defined responsibility.

David and Andrew then mention something interesting and I’ll quote it: “But once you separate a program into different modules based on responsibility, you have a new problem. At runtime, how do the objects talk to each other? How do you manage the logical dependencies between them?” I think it’s cool that they describe this as being a problem. This problem is what software design and architecture is all about. How to properly create an architecture, with minimal coupling.

They want to start of with this section by explaining what the concept of an event is. I think that every Unity3D developer is accustomed to using events. Maybe not directly in code, but in their design and implementation through the use of UnityEvents in the inspector. These are just events after all.

They describe events as “something interesting just happened” and “interesting” lies in the eye of the beholder. So we can use events to signal changes in one object that some other object may be interested in. The benefit of using events is that you can minimize coupling this way. You rely on the event, not the sender. What’s even more interesting is that there can be objects listening to such events. The sender is utterly unaware of who is listening, which is a good thing. This way you can truly write decoupled modules. I use event driven architecture a lot in a Unity3D context. Especially when it concerns UI or GameObjects. But I’ve also used it as triggers in repository patterns for example. So the repository would trigger events when an entity got updated or deleted from the database. This way it was simple to update a cache for example. But there are many more applications for event driven architecture, not to mention when you orient your entire architecture around some event bus. This can be very powerful, yet create a massive bottleneck when it comes to coupling or performance.

Publish/Subscribe

Then they mention another well known strategy in event driven architectures and that’s the publish/subscribe, or PubSub model. This is also used by default in Unity3D with the UnityEvents like the ones you drag and drop in the inspector. But what’s so powerful about the PubSub model you might ask. Well, David and Andrew describe it as follows: if the sender would know about all of it’s subscribers, it violates coupling and encapsulation because it knows about the other objects. They mention an event driven implementation in early version Java where all events needed to go through one routine, and inside this routine you had to distribute the events to the correct objects. This sounds a lot like old broker technology, which can be useful sometimes but definitely not always.

Objects should be able to just listen for the events they need, and nothing more. They shouldn’t receive events they don’t need. It will drop your performance and might lead to accidental coupling. The PubSub model allows you to just subscribe to the events you need. Sometimes there might be additional filters like topics etc. On an MVC scale for example you simply listen for a click event on a specific button in the View for example. This way you can exercise a lot of very controlled, fine-grained, control. But on a greater scale there might be this event or service bus where the centralized object dispatches these events and may maintain state and maybe even a database.

Model-View-Controller

The Model-View-Controller truly is a flavor of event-driven architecture that dominates our industry. It’s often still the goto pattern for UI development. With the advent of single page application (SPA) frameworks like react, Veu or Angular it might appear that MVC is on a way down, but as a matter of fact these architectures are just different flavors of MVC. I mean there is MVVM, MVP and MVU and god knows how many others. Some design that implements the observer design pattern is often the perfect way to decouple things.

One of the benefits I like the most about these kinds of patterns is that they are generally pretty testable. You don’t need a view, to test the model or controller. So you can decouple let’s say, your MonoBehaviours from your testcases. I’ve taken this strategy so many times. It creates a really nice, code first system. It might however not really work when you work in a team where most of the members are designers. Although you could lean more towards building some flavor of a Scriptable Object (SO) architecture, which in some way is very similar to MVC. It’s just that the model is an actual SO. There are also many example on how to model events as SO and all sorts of behaviour. It’s really cool so check out the videos below for more information on this topic:

But, to get back to the book; David and Andrew give use a very important tip when it comes to MVC, and I’ll quote: “Separate Views from Models”. Haha yeees yees yes. How often have you seen view-like code in models, just to prepare the data in such a way it fits nicely in the view? This way you might create some accidental coupling or complexity in the models without knowing it. And then you run into the issue that the model knows “something” implicitly about the view.

Yet MVC also provides us with the option to not just switch views, but controllers as well. This way you could reuse a model for a different usecase. Yet, I think you should be very careful if you do this because changing the actual usecase might create information leakage Prof. Ousterhout warned us for in A Philosophy of Software Design.

David and Andrew refer to the ‘Java Tree View’ as a very good example of MVC in the wild. I’m not really familiar with the specific component, yet unexpectedly, it’s a component to model tree structures like a file system. They also specifically mention the fact that MVC is not just a UI pattern. It can be used for different kinds of patterns as well. They speak about how you can link multiple models and views together to create like a mesh or network.

How, god darn amazing is this!? I mean, they basically describe modern event-driven or micro-service architecture here. They just evaporated the sauce of the spaghetti monster tentacles. I’ve read lot’s of Neil Ford’s stuff and he says that back in the day people had these ideas already, yet the ecosystem did not exist. Back in the early 2000’s database and operating system costs where sky high. But with the immense victory of open source software, micro-service architecture became a reality. If you don’t know Neil Ford; He’s just really an amazing software architect, and probably a great human being as well. He works for thoughtworks and has written multiple really great books like fundamentals of software architecture, software architecture the hard parts and evolutionary architecture. If you don’t know this guy, you should dig into his stuff. Truly amazing!

But I don’t want to spend to much more time talking about MVC. This architecture is such a household name in our industry by now that I think most of you have heard about it and if not there are probably a million billion tutorials about this on youtube. So search for a bit if you want an in depth explanation. However, if any of you would like me to write a blog about how to implement MVC, MVVM, MVP, MVU or wathever in Unity3d, let me know by dropping a comment below. Thx!

#end

01010010 01110101 01100010 01100101 01101110