Exploring SFML Graphics in C++ – Refactoring Wave 4

The application framework that we have embarked upon has seen a few modifications on the way to a solid basis upon which to build a program. Abstractions were introduced in the last article, Exploring SFML Graphics in C++ – Refactoring Wave 3, that focused on cleaner and clearer ways to represent certain concepts such as windows and views. I have refined this framework to better express the idea of a view. A view is where graphic elements are arranged and contained and there needs to be an approach for defining, introducing and transitioning views. I do not describe that latter objective here but defining and introducing views or, in this case, a single view, is necessary. The information that follows show the progress that has been made in reaching this goal.

This is the final article on this particular series of refinements to the application framework and test program that I have been exploring. First, let’s start with some code.

Application Framework

The primary element added is a class named MVCViewBase. It is a base class that effects the means for referring to different views in a polymorphic way. Classes that are views derived from MVCViewBase are expected to implement operations implied by the interface defined by MVCViewBase.

The chief goal with views at this stage using this approach is as follows:

  1. Express a set of common operations, common to all views within the scope of the application framework.
  2. Implement processes unique to each view underneath a common interface.
  3. Produce a common output for the visualization system to process independent of the view’s logic.

The application framework has does achieve all of these goals. As it stands now, the application framework is largely complete in terms of fundamental capabilities and processing stages related to views. The following screenshot shows some of the classes introduced in this wave of refactoring as represented in the Code::Blocks development tool.

pic001 SFML Based App Framework 2014-09-18

Test Program

The structural improvements by way of the RAII technique discussed in the previous article on this topic has aided me in further cleaning up the test program to present functionality in a more cleaner and clearer way. Besides the improvements in C++ code legibility, I have introduced a test view as a class called ProgramViewFirstView. This view derives from MVCViewBase and is processed through a ViewStandardController for the purposes of producing a ViewModel in a standard way. The ViewModel is the product of the controller handed to the visualization engine.

Today that visualization engine is SFML. The intent is not focus on SFML but to have a reasonable upper level design that is flexible enough to use whichever engine makes sense. The visualization engine used here is SFML but it could be Allegro, OpenGL or DirectX or any number of visualization helper systems. The test program has been shaped to productively use the application framework that incorporates the SFML to exercise visualization capabilities in a robust and reliable manner.

The screenshot below shows the current state of the test program as represented in the Code::Blocks IDE.

pic002 SFML Based App Framework - Test Program 2014-09-18

Answering Questions Already Answered

I am seeking to learn about some of the issues in defining views and application frameworks that are system agnostic using C++. I have done this before for several years using web development frameworks and server-side technologies that output standard HTML. Yet there are things that C and C++ with appropriate code libraries and programming methods allow and do better than HTML with JavaScript. I have used Microsoft Windows Forms and WPF in C#, VB6 Forms, and Java Swing all of which have tools to define views in a very straightforward way. It would be a great development to have a framework in which I define a class, set some data properties to relevant values and implement functionality that results in output in a straightforward way using C++. The flexibility in terms of the number and types of devices that could run the code I write would be liberating. The key is the productive definition and exercise of views into visual output and the mapping of device input to views in a consistent and reliable way.

Mainstream frameworks such as Microsoft C# WPF, Java Swing, C++ Qt have defined solutions that does this. Microsoft C# WPF only runs on Microsoft Windows; Java Swing may have deterministic code issues; and C++ Qt may lack deployment certainty. In an office setting in environments organized around Microsoft Windows, Microsoft C# WPF is perfect. Companies looking for exceedingly long-term software may opt for Java Swing and C++ Qt is obviously a useful tool for companies seeking to build desktop and native mobile software for sale.

Those tools have the qualities for defining views in an exceedingly easier way than I have arrived at this point. The question is why consider the approach I have laid out in these series of articles about an SFML based application framework in C++? The answer stems from my insights into cross platform software development. The answer is that sometimes you have to go in a different direction to achieve a certain result. The result I am aiming for is a narrower application framework that I can better calibrate to the quality and code design and deployment criteria of a varying nature. Building your own frameworks can enable you to achieve such goals but doing so costs more in terms of time and diminished initial certainty. As someone, like myself, pursuing this for purely exploratory reasons, the costs are mildly acceptable. Pursuing these goals when the stakes are higher or the time requirements are more austere means that you often defer to the more productive solutions from Microsoft, Apple, or Oracle which I am fond of in terms of their value in those cases where they are a benefit. Privately, however, I am pleased to explore a sliver of the process of what may constitute the definition of those tools for defining views.

Test Program Output

The ProcessEvent method of the ProgramViewFirstView class defines a sequence of actions in which a list of shapes are created. This list is eventually transferred from the view to the WindowViewManager to draw the visual data provided from the view through the controller.

The effort of structuring the test program and the application framework has been to abstract and organize operations and data in such a ways as to allow me to add views in a standard and clean way. Ideally, this means that a new view consists of nothing more than a class that has a list of visual data and methods that implement functionality in a manner that minimizes the extent to which that view class has to be concerned with the mechanics of presenting information.

Below is a screenshot of the test program when launched. The magenta square originates out of the ProcessEvent method of the ProgramViewFirstView class. As the program loops, it clears the display to a blue background and then draws the magenta square. It does this many times per second at such a rate that you do not notice that the square is removed and re-added on each turn of the cycle. Despite the more refined structure of the program, the code is still organized, at its core the same as it was originally defined in the first article titled, Exploring SFML Graphics in C++. This design may be inherently broad enough to allow more advanced expressions of views concurrent with interactive events such as keyboard input. If that is not the case, then the design may have to evolve to incorporate threads and callback functions unless my research and contemplation sees me to a different outcome. At this point, I have been satisfied to pursue a course that has seen the expression of the design in terms of abstractions in C++ in a certain direction. The culmination of this exploration is seen below and is largely unchanged across refactoring processes (Waves 14). This is good in that refactoring should maintain output while allowing you to decisively improve structure and code definition.

pic003 SFML Based App Framework 2014-09-18 - Test Program Output

Code File Listing

All code files are available for viewing. You can find the final version for this series on SFML on GitHub. Just follow the path to building_cpp_with_sfml_wave_04 from michaelgautier/codeexpo. The next sub sections provide a few more details.

Application Framework Files

All of the files for the application framework are listed below. The major changes include the classes named ColorSpec; MVCViewBase; ProgramWindow; VisualWindow; VisualSettings; ViewStandardController; and ViewStandardModel.

Test Program Files

All of the files for the test program are listed below. Most of these files are the same files but the Program class has been rewritten and reorganized internally. The WindowViewManager contains and accomplishes a larger share of the functionality once exercised in the Program class. The ProgramViewFirstView is analogous to a visual screen, in this case, a magenta square. Or, at least, that is what this view produces.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.