DEV Community: Raviola

A case against the MVI architecture pattern

Raviola — Mon, 12 Apr 2021 16:56:02 +0000

The opinions in this article are based on my own experience working with different implementations of MVI in both personal projects and at my day job.

To begin with, let me say I recognise how appealing MVI looks at first sight. It combines battle tested patterns like Command and Observer and makes good use of functional reactive programming techniques. In short, MVI sort of defines a meta-architecture favouring classes instead of functions and where every action the user can take is defined by an Input class and every state a view can be in must also be defined by a subclass of the State class.

I'm assuming you already know how this works, there are more classes like these in MVI including Actions, Results; among others, depending on each specific implementation.

The problem with MVI

My biggest pet peeve with this architecture is NOT how boiler-platy it can get, or how opinionated certain implementations can be.

My biggest problem with this architecture is how much it hurts overall code readability and in turn, developer happiness.

In my opinion, traditional MVI implementations artificially group ‘unrelated code’ together and encourages ‘related code’ to be spread out among as many different classes as possible (low coupling, high cohesion)
That's a big claim, let me explain what I mean.

When writing a new piece of code, you only care about the feature you are writing/reading and not much else. If you are fixing a bug, you are usually focused on a specific flow where the bug is happening, trying as hard as you can to reproduce it. The faster you can build a mental model of how this feature works the faster you'll fix the bug. So it helps if the code for the feature grouped together and isolated from any other feature.

Unfortunately, this is usually how code ends up looking in MVI:

    fun intentToAction(intent: HomeIntent): HomeAction {
        return when (intent) {
            is HomeIntent.LoadAllCharacters -> HomeAction.AllCharacters
            is HomeIntent.ClearSearch -> HomeAction.AllCharacters
            is HomeIntent.SearchCharacter -> HomeAction.SearchCharacters(intent.name)
            is ...
        }
    }

See how all features are intertwined among other completely unrelated features in that snippet? You probably only care about one single line in that method at a time.

In other words, you are never, ever, going to read that snippet of code from top to bottom (you know, like we usually read things). So why are we writing it like that? It's hard to write, it's hard to read.

You might be thinking "well, that doesn't looks so bad". Now imagine 10 or 20 more lines in the when statement, which basically only perform a trivial mapping from two very similar sounding classes FooInput -> FooAction.

It doesn't stop there though, in many implementations actions get mapped to results, and then results get mapped to states:

fun Result<List<Persona>>.reduce(isSearchMode: Boolean = false): HomeState {
    return when (this) {
        is Result.Success -> if (isSearchMode) HomeState.ResultSearch(data) else HomeState.ResultAllPersona(data)
        is Result.Error -> HomeState.Exception(exception)
        is Result.Loading -> HomeState.Loading
    }
}

Take a moment to think how you would follow the code in your head while trying to find that nasty bug. You start from the View, jump to the ViewModel, and see the first mapper (inputs -> actions). From there there's not clear path to take (or IDE shortcut to use) to jump to where the flow continues (since the architecture usually hides the wiring from the clients). You basically need to do a cmd+f of the action name (or cmd+b to get a list of places where it's used/declared) to try and find where that action is being processed, that's usually in the VM as well, some implementations define a UseCase class and place the mapper there, it really could be anywhere.
Ok, you found the Actions -> Results mapper, you found the one line you care about in that mapper, what now? Well now you jump yet again! this time to the Reducer and you find... another mapper! At this point you forgot what you where doing entirely.

MVI makes reading code a very awkward experience. It’s analogous to reading a book where each next word is on a new page. You need to keep flipping pages (going to a different class) to know what comes next. You end up spending more time finding code, than reading code.

All this added overhead makes it easy for bugs to hide in plain sight. This gets more tricky when you take into consideration Threading, RxJava/Coroutines, Asynchronous events, Lifecycle scopes, etc.

I understand where MVI is coming from here though, if multiple Inputs produce the same Action then we can simplify things a bit. Unfortunately, in practice this is almost never the case. Your flows won't share Inputs, Actions, or Results`. It's more likely that for every "flow/usecase" in your app, you'll have one of each.

Reducer is a leaky abstraction

Don't get me wrong. There are valid reasons for extracting code into other classes.
A good example of this are ViewModels. A ViewModel exists not because a particular architecture requires it, it exists because it has a clear purpose. It serves as an interface from the view to the business logic, separates the rendering view code from non-rendering related code, it signals a larger scope (at least in android the lifecycle-scope of the VM is slightly larger than the scope of the views), facilitates testing, etc. In other words, it has a propose that's beyond the chosen architecture agenda.
In the same way, UseCase classes exist because UseCases are a reusable component that might be used from different VMs. Same goes for Repositories, a repository can stand on its own and serve multiple clients. All these classes exist with a clear goal, scope and purpose. Here, the logic is split sensibly.

On the other hand, let's look at MVI's Reducer. A Reducer is very specific to a particular VM (not reusable). Moreover, the scope of the reducer is the same as the scope of the VM. Why extracting it out out into its own class?
"For testing purposes" I hear you say. That's not a good enough of a reason IMO.
Ask yourself this: "Should I really be extracting private methods into a separate classes solely to be able to test them?" I personally don't think so, those methods are private for a reason, they are implementation details, they are not meant to be unit tested directly. Otherwise, what's stopping you from extracting every single private method from every single class in your project and testing those too?.

**It's perfectly normal to want to simplify your classes when the get too big and complex. But in my opinion, extracting things into different classes needs to be done in a sensible way.

What I'm trying to say here is, you can come up with all sort of ways of splitting code, but not all of them will be good.

Splitting your VMs based on functionality/use-case/features is usually better and makes more sense than splitting it by some arbitrary architecture convention. As an example, consider these two classes:
MediaCache: This class handles caching for images and video
Reducer: This class reduces results to states (huh?).

Here, the Reducer could potentially grow infinitely since it could host logic for any new feature you add to the View/VM. The purpose of the class is very abstract and tied to the architecture.
On the other hand, there are few operations that you can put into MediaCache, it has a well defined scope based on functionality (what the class does). Sure, you can get very fancy and design a very complex cache mechanism but all your code will be within scope of caching things. It's not the case with Reducers, the scope will grow and grow and as you add more and more new features.

Extracting implementation logic into trivial classes only for testing proposes also results into simplistic tests that become increasingly meaningless and add a ton of friction to your codebase. If you want to read more about why testing private methods is bad I highly recommend this read: Unit testing private methods by Vladimir Khorikov

When you have a class with a single function reduce and no state, you should ask yourself "why is this a class to begin with?". Just move the function inside your VM, no need to extract it into artificial classes. Then go a step further and get rid of this function altogether, because again, reducing should happen contextually within the feature and it should not be artificially grouped together in a function.

Ending thoughts

There are many other reasons I dislike this architecture, It's very intrusive, it adds a ton of boilerplate, it can be ambiguous, etc. Those are not exclusive to MVI and I could live with some of those drawbacks. I'm sure MVI might fit some applications better than other, but in all cases, readability suffers.

All in all, MVI looks elegant from a theoretical standpoint but I have yet to see an implementation that actually works and scales well for big projects.

I'm very happy that Jetpack compose is just around the corner! Up until now I've been using a hierarchy of custom views + view models in my apps (something that kind of resembles the composable approach that Google is taking with Jetpack Compose). It's nice to know that his approach will soon become more mainstream.

Website

Twitter

EDIT:

I've been told not all implementations extract the reducer into its own class. I think that's a good thing! Still, most MVI implementations unnecessarily force you to reduce ALL your features in the same function/class (resulting in giant when statements, mixing unrelated features, grouping unrelated code, and making things hard to read overall).

I was also told that big when statements/mappers can be prevented by using composable "sub-view-models". IMO, splitting this when statements into smaller ones does not fix the underlying problem, it only adds more boilerplate. More classes that just redirect you somewhere else. You are still reading code in a perpendicular way as to what you write (one line at a time before jumping somewhere else). And again, you end up spending more time trying to find code than actually reading it.

Lastly, I've been presented with this architecture: https://github.com/orbit-mvi/orbit-mvi
Which I haven't tried but I like what I see, it throws away many MVI made up restrictions while keeping the ones that make sense. Feature flows read linearly and the state reduction happens contextually (as opposed to grouped into one big "reducer" function/class).

Writing Super Mario Bros in C++

Raviola — Sat, 30 May 2020 18:36:53 +0000

I decided to learn C++ as step towards understanding more about the fundamentals of computer science, programming languages and graphics programming in general.

Game development has been a hobby of mine for a long time. writing a game seemed like a fun project to start with. After reading some books on C++ I decided to clone the Italian plumber platformer. Find the source code here

In this post, I want to talk about aspects I found interesting about learning C++ coming from the JVM world. I also want to shed some light into the process of building a “simple” game using the Entity Component System Architecture. If you are not a game developer I hope my article serves as a general introduction to how simple games like this are put together.

Starting out

I love JetBrains IDE’s so the first step for me was downloading CLion. CLion uses CMAKE to build C++ projects by default. CMake is a build system that builds build systems. It’s cross platform and incredibly unintuitive but it’s your best bet if you want your software to run in multiple platforms. It came as a surprise that a language with this much history doesn’t have a more sophisticated solution in place. Coming from the Java (Kotlin) world, I have a newfound appreciation for Gradle.

I decided to use Simple Direct Media Layer 2 (SDL2) to get access to audio, keyboard, mouse, and graphics hardware. I considered using OpenGL directly, but I think the scope of the project was quickly getting out of hand as it was.

Next, I set off to define an architecture for the game. Plain Object Oriented design seems like a perfect fit for games. You have a bunch of objects in your game interacting with each other. You can map those objects to classes and take advantage of inheritance to avoid repeating code. Unfortunately, this naive approach brings with it some problems when building games of relative complexity. I don’t want to get too deep into what those problems are but here’s a quick summary:

Using inheritance usually results in inflexible architectures that sooner or later will lead into the Deadly diamond problem.
Efficiency. Objects often are scattered around memory and make poor use of CPU cache both in terms of cache coherency and prefetching. (this might not be a huge deal depending on the kind of games you’re trying to make)
Encapsulation. It’s hard to define where logic should live and what has access to what, resulting in spaghetti code.

I might expand on these points on a following article. For now I want to show you how the architecture I picked works and how it overcomes these problems.

The ECS Architecture

I struggled in the past trying to architect my games in a way that they would scale. When I first learned about the Entity-Component-System architecture I immediately wanted to try it out. Let’s start by defining each term on its name.

Entity

Everything in your game world is represented by an entity. This includes the player, the enemies, sounds, music and and even the camera. An entity is just a bag of components and contains no logic:

Component

Components are plain old structs that also contain no logic. They are just data holders. Common components you’ll find in most games are PositionComponent, PlayerComponent and TextureComponent.

Notice that some components don’t even hold data (see PlayerComponent for example) they just serve as “labels” that help identify certain entities in the game world.

Components can be assigned-to and removed from entities at run-time.

The components above are pretty general, but you will most likely be creating components specific to your game. As an example, a SuperMarioComponent is assigned to the mario entity whenever he eats a mushroom.

System

Lastly, systems are where the action happens. They are very domain specific. They hold logic and keep it encapsulated. I think this will make more sense with some examples of the types of system I defined in my game:

- The render system
- The camera system
- The physics system
- The animation system
- etc.

The system class is not much complicated than the rest of the classes in the architecture. On it most basic form it overrides an update(world* world) function that takes in a game world as a parameter. We’ll talk about the World class next.

Take a look at the AnimationSystem in my game for a simple real example of the logic illustrated above.

Putting things together

As hinted above, Systems, Entities and Components interact with each other using the World class.

As you might have guessed, the world class models our gameworld, and as such, contains all our game Entities. We can define what happens to those entities by registering systems to the gameworld. Both entities and systems can be added/removed at run time.

The world class is as straightforward as the rest of the classes in the architecture:

I think you can guess what most of these methods do. The first one is just the default constructor. The next two just add/remove Systems to to the world. The following two ones do something similar but for Entities.

The last method, find(), is perhaps the one that deserves more explanation. It takes care of finding all entities currently in the gameworld that match a specific criteria. That criteria is usually what type of components are assigned to them:



// Find all entities with Texture and Position data.
auto entities = world->find<TextureComponent, PositionComponent>();

Find takes advantage of function templates to define the search. In Java/Kotlin if you want a class or function to operate on a arbitrary class you can make use of generics. Function and class templates are a bit like generics only more powerful. Function templates are instructions to the compiler to write code for you, also known as metaprogramming. This allows us to create a function template whose functionality can be adapted to more than one type or class.

This is the definition of find in my code:

There’s a few interesting things going on here. The first one is the use of template<typename… Components> in the function signature. This is telling the compiler to generate a function called find at compile-time. The compiler will generate such function each time it encounters a distinct invocation of find:

For the code above, the compiler will automatically generate the following for us:




void find(const std::function<void(Entity*)>& callback) {
   for (auto entity : entities) {
      if (entity->has<AnimationComponent, TextureComponent>) {       
         callback(entity);
      }
   }
}

As I hinted before this happens at compile time, so there’s no run time penalty. I must admit I didn’t like this C++ feature when I first encounter it. I still don’t, but I understand the performance benefits they bring along. The reason I don’t like them is I think they result in hard to read code. I don’t like weak-typing systems and this looks awfully like it.

The rest of the function should be relatively easy to follow. Let me know in the comments if this is not the case.

Conclusion

You should now have a rough understanding ECS works. We no longer rely on inheritance to define behavior, we rely on composition instead. This means we got rid of potentially long and inflexible hierarchies in favor of lightweight reusable components that we can add and remove at runtime.

The efficiency problem I mentioned before is also mitigated. Our entities and components are now tightly packed in contiguous memory, so iterating over them makes much better use of CPU caches. There are techniques to improve this even further but I haven’t had the need to implement them for this game.

Our third problem, encapsulation, is also fixed. It is now very clear where the logic should live, how the different parts our architecture should communicate and what should have access to what. As an example, it makes sense for the RenderSystem to make use of classes such as renderer.cpp or window.cpp, but it would be immediately obvious something is off if those classes are required by systems like the PhysicsSystem.cpp or the SoundSystem.cpp.

You should know have an idea of how my code is structured. Feel free to poke around and create PR to improve any bug or mistake I might have made. I’m still very new with C++, so I’m sure my code has a lot of room for improvement.

Learning C++ was a fun experience but I believe I have still a long way to go to feel comfortable using it. Future steps for this project include re-writing it using Rust or Kotlin-native. I would also love to compile this project to WASM to get it to run in a browser, if you have any experience with any that I would love to chat with you!

Thank you for reading, and Happy coding!

Personal website
Twitter

Cascade static library link mechanism

Raviola — Wed, 22 Apr 2020 04:06:21 +0000

Hey C++ people, can anyone help answering this SO question?

cascade static library link mechanism

May 5 '18 Comments: 11 Answers: 0

sdl2-image was built and installed as a static library libSDL2_image.a, it dependons on another static librarys, like webp, libpng, etc. When I link it like:

add_executable(main main.cpp)
target_link_libraries(main
  SDL2::SDL2-static
  ${SDL2_IMAGE_LIBRARY}
)

It fails, showing error:

[ 50%] Linking CXX executable main
/usr/local/Cellar/cmake/3.11.1/bin/cmake -E cmake_link_script CMakeFiles/main.dir/link.txt --verbose=1
/Library/Developer/CommandLineTools/usr/bin/c++   -Wl,-search_paths_first -Wl,-headerpad_max_install_names

…

Open Full Question

Can you recommend a good operating System Fundamentals book?

Raviola — Fri, 21 Dec 2018 23:04:01 +0000

Hey can anyone recommend a good book on Operating system fundamentals?... Currently looking to buy this one: https://t.co/yZvN8WnukA

computersience #os #operating #system