In my previous post, I said that there are three major parts to any computer program: Structure, Action, and Results. Also, a program has Input, which could be considered a fourth part of the program, although usually it’s not the programmer who’s creating the input, but the user. So we can either abbreviate this as SAR or ISAR, depending on whether or not we want to include “Input.”
Now, some people misunderstood me and said, “Oh, SAR is just another name for MVC.” No, I used MVC as an example of SAR, but SAR is a much, much broader concept than MVC–they are not comparable theories. MVC is a pattern for designing software, whereas SAR (or ISAR) is a statement of the three (or four) components that are present in all software.
The fascinating thing about SAR is that it applies not only to a whole program, but also to any piece of that program. A whole program has a Structure, just as a function or single line of code has a Structure. Same for Action and Results.
Here’s a little more about each of the pieces, and some examples to help explain:
Here are some examples of things that would be considered “Structure” for the whole program:
- The directory layout of your code.
- All of the classes and how they relate to each other.
- The structure (schema) of the database, if your program uses a database.
Note here that the actual data in the database isn’t part of the Structure, though. If your program is producing the data and then sticking it into the database, then that’s part of the Result. If the data is sitting in the database and your program is supposed to process it, then that data is part of the Input.
Then an individual class (and I mean a “class” in the object-oriented sense) would also have a Structure:
- The names of methods in the class and the types/names of parameters that they take.
- The names and types of variables (member variables) in the class.
Whether or not a function (or variable) is private or public would also be part of the Structure, because Structure describes what something is (as opposed to what it does or produces), and “private” or “public” are words that describe what something is.
A Structure is sort of “the components of the program” or “the pieces you make the program out of.” Function names and types, variable names and types, classes–these things are all Structure.
Structure just “sits there.” It doesn’t do anything unless there’s some part of your program that uses it. For example, a method doesn’t call itself, it just sits there waiting to be called. A variable doesn’t put data into itself, it just sits there waiting for you to do something with it.
The Action of a whole program is very easy to understand. A tax program “does taxes.” A calculator program “does math.”
An Action is always a verb of some sort. “Calculates.” “Fixes.” “Adds.” “Removes.” Those are actions. Usually they’re a little more descriptive and specific, though, like, “Calculates how much rainfall there will be in Africa next year,” or “Fixes broken hard drives.”
Inside of a class, the Action is the code inside of the methods. That’s all some sort of action–something going on, something happening. In many programming languages, you can also have code outside of any class or function–code that just runs when you start the program. That’s Action.
Every program, every function, and every line of code has some effect. It produces some result.
A Result can always be talked about in the past tense–it’s something that has been done or created. “Calculated rainfall,” or “Fixed hard drives.” In a tax program, we’d call the Result either filed taxes or filled-out tax forms. As you can see, it sounds a lot like the Action, just completed.
You don’t have to describe a Result in the past tense, though. I’m just saying it always can be described that way. For example, in a calculator program, normally we’d call the Result of addition “the sum,” (not past-tense, just a noun) but you could also say that the Result is “added numbers” (which is past-tense). Same thing, just a different way of describing it.
Individual pieces of your program have Results, too. When you call a method or function, it has a very specific Result. It gives you back some data, or it causes some data to be changed.
Whatever your program (or any part of your program) produces, that’s the Result.
ISAR in a Single Line of Code
So, I said that SAR applies to a single line of code, but I didn’t give you any examples. So here’s a single line of code:
x = y + z
z in that line are part of the Structure. They’re variables that hold some data. To make an analogy: A jug is a structure that holds water. A variable is a structure that holds data.
The numbers that are stored inside
z are the Input. That’s the data that we’re doing something with.
+ is an Action: “Add these two numbers.”
= is also an Action: “Store the result in
And, of course, the Result is the sum of
z that gets stored in
y is 1 and
z is 2, then the Result is the number 3, which gets stored in
x. (Also note that
x is a itself variable and thus also part of the Structure, but that’s getting pretty technical.)
Wrapping It Up
So anyhow, I hope that explains SAR a bit better. It’s a concept that applies to any kind of programming, whether you’re building a big application or just writing a single-line script. And it’s not something that you have to think about in-depth every time you write a piece of code, but it’s something that can help us analyze and understand a program, particularly when we’re looking at how we can improve its design.
Wouldn’t the input to a smaller part of the program be given by the programmer rather than the user? Eg. input to utility functions and so on?
Yes, indeed it would. 🙂 For example, if I’d made my single line example “z = y + 1”, then “1” would be an input provided by the programmer.
You wrote: “The numbers that are stored inside x and y are the Input”. I think it should be “… inside y and z …”. The number stored in x is irrelevant for this line of code.
Oh, you’re right! That was a typo, I’ve fixed it. Thanks. 🙂