Examples Available On GitHub

-



So, I've opened a GitHub repository. 

The idea is to provide some real code to back up my claims about building larger applications. I put a lot of thought into the platform, language, etc., that I wanted to use. 

I finally settled on:

I chose C# because, despite a few flaws, it's an excellent language, particularly for learning. Microsoft did a great job with it. I then chose Windows 11 because, although I appreciate OSX, developing in C# on OSX can be cumbersome. Instead of Visual Studio Code (VSC), I opted for Visual Studio 2022. Microsoft seems to have finally hit the mark with it. While VSC has matured significantly, it was initially less than ideal for my needs. I'm not interested in building skyscrapers with just a shovel. I hear the masses growling. 

Lastly, I chose UWP and Win2D for their performance and ease of use. While they're primarily for Windows and Xbox, some clever wrapping can extend their reach.

Update:

Project was changed to regular WinForms and SkiaSharp graphics.



The first example code is a small clock.



I incorporated a bit of Data Driven Programming, as I'll discuss that in my next post. This approach makes it easy to customize the clock. I've also added the ability to simulate quartz, mechanical, and spring-driven watches, complete with a jumping minute hand for those with a hefty budget.


But the most crucial takeaway for now is probably the Lego Principle Pyramid.



The yellow classes are UWP and Win2D wrappers. These classes completely encapsulate any platform-specific functionality, allowing the rest of the application to remain blissfully unaware of it. The blue class is the actual game, which will expand to include future classes for game functionality. Importantly, as this is a basic render engine, the game class only knows about the RSNode class and its descendants, which provide visual representations on the screen. This design means you can change any yellow (platform-dependent) class with very little risk of breaking the actual game. The only yellow class that could potentially disrupt the game class is RSBaseCanvas, but as it's a simple wrapper for Win2D render functionality, the likelihood of it causing issues is minimal. Moreover, there are ways to mitigate this risk entirely, which I'll cover in another post.


The only minor flaw so far is the RSBaseGame accessing the RSNode class. While not strictly prohibited, the RSNode will likely undergo significant changes and expansions. It's critical to avoid any modifications that could impact a yellow class. Therefore, this interaction should be addressed and corrected.


Finally, the green class functions more like a value type and can be utilized anywhere. Unlike "normal" classes, these allow for writable data, circumventing the principle that all data should be readonly. Shocking, I know. 

But hear me out.

These "classes" are essentially structs, designed to avoid the pitfalls of working on copies - a common issue with structs since they are copied when passed around. Modern compilers help mitigate this problem, making it less of a concern today. However, I still prefer classes for reasons that might be more sentimental than logical.


Takeaway


The GitHub repository is live, showcasing the first real-life example of the Lego Principle in action. The plan is to continue updating the repository with hands-on examples from my posts. It also demonstrates the importance of having a clear view of the class hierarchy as a crucial design tool in writing large applications.


/Lars


Comments

Post a Comment