Truckin’ Through ActionScript 3.0 MVC: Part II—Reality Sui Generis or Collection of Spare Parts?

Truckin' thru MVC

Straws and Stacks: MVC as a Reality sui generis

Years ago in an introductory sociology course, I became acquainted with the concept of a reality sui generis. Some of you may have come across the term elsewhere with different meanings in different contexts. Biology, law and political science have their contextual uses of the term, but the one we’re using here is the one from sociology. Emile Durkheim employed the term in his work, Suicide, to describe a social fact. For Durkheim, a social fact is a phenomenon of social behavior not reducible to its component parts. A bureaucracy is an organizational arrangement that we think of independent of those who actually make up the bureaucracy. It is a reality sui generis—a reality in and of itself. So, we can study phenomenon like families, groups, and organizations as being separate from the people who make them up. Each has characteristics that cannot be seen in the individuals.

To help us understand the concept, we were given the example of a stack and the individual straws that make up the stack. Straws and stacks have wholly different features even though one exists because of the other. By the same token, the MVC, while made up of objects, has characteristics independent of those objects. So, we might envision the MVC as a reality sui generis.

Having noted the different characteristics of straws and stacks, the characteristics of the straws can alter the stack. A stack made of shards of glass is certainly going to be different than one made of wheat or alfalfa straws. So, yes, the components do make a difference. An MVC can be made of different component objects, resulting in different capabilities, is still an MVC.

Comfort Level of Abstraction

For too long I remained in a stultifying comfort level in programming. After tip-toeing into OOP, I was quite content with my algorithms and syntaxes, but other than thinking this was cooler than procedural programming, I never really left the entry level of OOP. Therefore, I never saw the advantages of design patterns or architectures outside of procedural steps. I could always learn a new algorithm or dig deeper into the syntax giving myself the illusion of making progress.

The MVC can be a way to step up and out of the statement level of abstraction. Once we realize that a class can be a reality sui generis—an object—the next level of abstraction asks us to think of design patterns as a reality sui generis. Ironically, the MVC begins by breaking up a single entity that combines the model, view and controller and restructures them for better use. You can think of this as breaking up a great big class and creating smaller objects to add flexibility to programming. (Imagine a giant straw being chopped up to make a stack—the straw can never be a stack by itself.)

In that process, the MVC clearly defines the relationships between the objects. That’s why the first chapter of GoF spends so much time on relationships. It is not about algorithms and syntaxes for a reason. The MVC is initially used as a heuristic* device to show readers how objects relate to each other. GoF describe relationships in the MVC in terms of the general problem:

…decoupling objects so that changes to one can affect any number of others without requiring the changed object to know details of the others.

That means that you can introduce new elements to a program by attending to the relationships between objects. Because the objects are decoupled, a change in one will not break the other or even require that you do anything to the related objects. However, you do need to think of the relationships between the objects.

*By heuristic, I’m referring to a strategy to help the reader understand design patterns—not the way the term is used in computer engineering or computer programming.

The Model and View Relationship

For the time being, forget about the Controller. We’ll just look at the Model and View. On Page 5 of their book, GoF show a simple example of three variables with different assigned values labeling it as the model. Three different images display the values in the form of a table, bar chart and pie chart. These are the views of the data in the model. So all that the view is doing is presenting the values generated in the model. It doesn’t matter how much data there is in the model or its data values, it just models the values that the view uses to present it in any way it wants.

The relationship between the model and view is a two-way one. The model tells the view to update itself, and the view reads the data in the model. That’s it! The MV relationship is simple. We’ll get to the role of the controller, but for now, what you need to know is that the MVC first identifies and then separates the three elements that makes up the model, view, and controller.

Programming a Compass

Now that we have an idea of the MVC, the best place to start is with an UnMVC. That is, we’ll start with a program that is in a single class and then break it up into an MVC. For the example, we’ll use a compass. The compass is made up of two movie clip classes. One is a compass rose that serves as a background, and the other is a compass red and gray needle. The needle is positioned in the middle of the compass rose using its center as a pivot point. The compass rose center point is the center of the rose and not the upper-left hand corner. One MovieClip has the Class name, CompassRose and the other Pointer. The following program displays the compass with one of four selected directions:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

package 
{
	import flash.display.Sprite;
 
	public class UnMVC extends Sprite
	{
		//Model
		private const NORTH:uint=360;
		private const NORTHEAST:uint=45;
		private const EAST:uint=90;
		private const SOUTHEAST:uint=135;
		private const SOUTH:uint=180;
		private const SOUTHWEST:uint=225;
		private const WEST:uint=270;
		private const NORTHWESTT:uint=315;
		private var currentDirection:uint;
		//View
		private var compassRose:Sprite=new CompassRose();
		private var pointer:Sprite=new Pointer();
 
		public function UnMVC()
		{
			compassRose.x=200,compassRose.y=200;
			addChild(compassRose);
			pointer.x=(compassRose.x),pointer.y=(compassRose.y);
			//Controller
			pointer.rotation=SOUTHWEST;
			addChild(pointer);
		}
	}
}

Figure 1 shows what you can expect to see when you test the program:

Figure 1: Compass needle points to value in Model

Now, you may be thinking that the little program is too tiny to be an MVC. Of course, it’s not an MVC because it’s all in a single class, and that’s why it’s named UnMVC. However, you can see all of the elements of the MVC in the comments.

Breaking Up Is Hard to Do: From UnMVC to MVC

The first step is to break up the UnMVC class into Model and View classes. We’ll also pick up a Client class to launch the whole thing. Before we do that, though, take a look at page 429 [Figure 12-1] of our book. Chandima has made a very clear illustration of the relationships between all three elements of the MVC. Further, he shows their flow sequence. For now, though, we’ll just be focusing on a single relationship—how the Model provides data to the View. The manner in which this can be done can take many forms, but in the example, the View simply requests the Model for data with the Model deciding which direction to provide. The Client acts something like a Controller, but just treat it as a Client for now. The following three scripts are the first steps in breaking up the UnMVC into a MVC.

First, the Model just has the data to be used.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

package 
{
	import flash.display.Sprite;
 
	public class Model extends Sprite
	{
		private const NORTH:uint=360;
		private const NORTHEAST:uint=45;
		private const EAST:uint=90;
		private const SOUTHEAST:uint=135;
		private const SOUTH:uint=180;
		private const SOUTHWEST:uint=225;
		private const WEST:uint=270;
		private const NORTHWESTT:uint=315;
		private var currentDirection:uint;
		private var currentDirection:uint;
 
		public function Model()
		{
			setDir(NORTHEAST);
		}
 
		public function setDir(currentDirection:uint):void
		{
			this.currentDirection=currentDirection;
		}
 
		public function getDir():uint
		{
			return currentDirection;
		}
	}
}

Whenever the Model is instantiated, it fires a function to set the current value. This value is picked up by the View using a getter function in the Model. So the request comes from the View as illustrated in Figure 2.

Figure 2: View requests data from Model

In the following View listing, the constructor function has been omitted, and all of the work is done by calling methods from within the View or by calls to the Model.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

package 
{
	import flash.display.Sprite;
 
	public class View extends Sprite
	{
		private var model:Model=new Model();
		private var compassRose:Sprite=new CompassRose();
		private var pointer:Sprite=new Pointer();
 
		public function setView()
		{
			compassRose.x=200,compassRose.y=200;
			addChild(compassRose);
			pointer.x=compassRose.x,pointer.y=compassRose.y;
			pointer.rotation=model.getDir();
			addChild(pointer);
		}
	}
}

Before going on, I want to quickly mention Miško Hevery’s post on not having the constructor function doing any real work. Anything more than field assignments in constructor functions is considered a flaw in writing testable code. I believe that this rule is suspended for the Client class, but as I’ve been cautiously removing any real work from constructors, I’ve found my code far easier to debug and reuse. We need to have a separate post on the issue of constructors using ActionScript 3.0 examples, but in the meantime take a look at Miško’s post on constructors.

Finally, We’ll use a Client class that launches the Model and View classes and places the compass on the stage pointing East this time.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

package
{
	import flash.display.Sprite;
 
	public class Client extends Sprite
	{
		private var view:View=new View();
		private var model:Model=new Model();
 
		public function Client()
		{
			view.setView();
			addChild(view);
		}
	}
}

As a start in understanding the MVC, we began with a single class that contained the elements of an MVC. It was broken apart to reveal the Model and View by placing them in separate classes. However, the important information to take away from this is the relationship between the Model and View classes. Because we have no Controller object, we have no way to change the View independent of the Model. In cases where the Controller can add data directly to the View, the View needs to inform the Model so that it can change its data. For now, though, we just have the View class requesting data from the Model and using it to change the direction of the compass pointer.

In the next and last post of Truckin’ Through ActionScript 3.0 MVC, we’ll finish up the MVC by adding a Controller module and consider replacing the class objects with design pattern objects.

The Truckin’ Through ActionScript 3.0 MVC: Part II—Reality Sui Generis or Collection of Spare Parts? by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.