I have slowly been chipping away at this article for a very long time now. I initially wanted to make a video tutorial out of it, but that became impractical due to my lack of video editing skills, a place to film it and a video camera. So an article it will stay. I am not sure that I am doing a good job conveying everything here, so I want it reviewed before I put it on the article system. Please give me any critique on things I do not explain well or otherwise did wrong.

--------------

The primary purpose of objects is to be a part of a multi-tiered architecture. While this is nearly never needed in smaller programs, designs like this are absolutely imperative to large systems. I will be talking about a very simple approach to multi-tiered architectures, there are far more complicated ones.

For purposes of analogy, we will look two stories about cars:

1. Bob needs to go to his friend’s house which is 1.2 miles down 4th street and 3 miles down main. To complete this task, he goes into his car and builds a car that is engineered to get out of his driveway, drive 1.2 miles down 4th, take a 90 degree turn then go 3 miles down Main. Bob did get to his friends house, but has to re-engineer his car to drive the way back. To Bob’s dismay, his mother gives him a call and wants him to visit. While Bob loves his mother, he does not remember the way to her house, he can not remember if he needs to take a right at Maple or a left at Maple. He will know once he gets there though because there is an ugly tree next to where he needs to turn. So Bob will have to re-engineer his entire car on the road when he knows which way to go.

2. Frank wants to his friend’s house. Frank, like bob, does not remember the exact way. To get around this solution frank builds a car with wheels that move forward when a pedal is hit, they can also turn when a wheel inside the car is turned. This way Frank can use the car to go exactly where he tells it to. And when he gets home, he can use it again!

Both Bob and Frank got to their destination, but Frank did it far more efficiently because he designed a module that did not complete a specific task, but completed a generic task. He then told his generic module exactly what to do in a way that would only be used once. This way, his module could be used over and over again to complete various specific tasks without redoing the same things over and over again.

Your programs should work in a similar way; there are two layers that complete similar tasks to the analogy above. Your core classes and functions are the car; they compute the core logic and do the core tasks but do not actually execute any of it in your program. The layer that executes it is what is often called the scripting layer (which in the story is you while driving). The scripting layer does not compute logic, but it uses the resources given to it to complete the task you want.

To put this in a practical example, I will use a project I recently completed at work (I can’t give you any actual code, its Visual Basic anyways). The purpose of the program was to query a certain feed, get the real estate data, download the photos off of their server and update our database with its information. The feed could also indicate that a listing has been taken off the market, so I would have to remove those listings from our server. Each real estate listing has a unique seven digit unique listing number (LN) associated with it. Each listing also has up to nine photos associated with it

I started by writing a set of functions that could download all the photos of a given LN to our server. I then wrote the functions that copied the necessary data to our database. I also wrote functions to delete anything I could create. I decided to place these in an object because they needed to use many of the same resources. So at the end what I had was an object who’s members could update or delete everything we needed in regards to the RETS data.

However, I did not have a working program yet; all those functions need something to use them. This is where the script layer came into the picture. In this part I queried the RETS database and compiled a list of new/deleted listings. I then ran though this list and executed the processes that needed to be done (add or delete).

You might be asking “why did I run the query and compile a list in the script layer?” The answer to that is because it was simply too specific to put in an object or function. The query was very narrow in use and relied off of a number of command line parameters, the list I compiled was equally narrow in use. It would have been inefficient to place it in the core since they were not in any way generic. There is no solid line to where to place code, some code obviously belongs to a certain layer, but you will often be confronted with code that can be in either layer and not be a significant breach of logic. This I where you come it, you are the only one who can say where to put it. Just do what makes the most sense to you and it will be fine. If you realize you made a mistake, learn from it and better your ability for next time.

Back to my story, about a week later the unexpected happened: I was asked to make a web application where staff could browse listings and manually administer them if needed. This required functions that could grab or delete data based off the LN of a particular listing. Sounds a lot like what our automatic updater does, except a person is calling the shots based off of website forms opposed to a generated list from a feed. Because I abstracted my generic action code, I was able to make it into a DLL* and share the functions between the program and the webpage. Instead of querying the RETS database, I had wrote a web interface where they could find listings and click buttons to do things to them. These buttons triggered off the exact same command from the exact same file for the exact same results. The best part is that I did not have to touch a single line of my original update/delete code.

Should I have programmed my entire application as a script, I would have had to dig though the entire program finding the specifics I needed, I would have also had rewrite a lot. But since I used a multi-tiered architecture I was able to cut my second project into a fraction of what it would otherwise have been. This is just one example of how multi-tiered architectures can help you. This program was rather small (<700 lines) so nothing too fancy was needed, I just needed to abstract my core functions from the code that runs them.
To give a visual diagram, this is the basic layout:


How do classes tie into this? The simple answer is that they make your live far easier. Class functions can share variables that are not available anywhere else; they also give you a straight forward way of knowing what is what. Another up is that when a class has been properly written it can simply be copied and pasted since all its dependencies are within it or clearly stated. If you use global scope variables to share with functions, it is far hard to find everything that it needs. Furthermore, defining loose things are bad when you are working with code that is supposed to be generic. Variables defined at the global scope can be readily modified by anyone at any layer of the programming, making your multi-tiring little more than fancy file naming.

*DLLs are files that contain pre-compiled classes and functions for other programs to read, they do not run by themselves. This means that one set of functions can be shared by as many programs as you want as long as they make a reference to it.

__________________

__________________
Codefreek's - News Letter, Tech, & some random ramblings

I will not be able to publish this article without critique, please do give me your thoughts on it. I am open to both critique about the lesson and the English in it.

__________________

It's good but I think perhaps you should go more into detail about how to properly plan how one would go about creating a good object. What I mean is explain the step most people skip when they go about creating a library - the planning.

__________________
My Blog

i agree with Enfernikus, my own thoughts, some spelling mistakes, but that we wont nag about, some things i wanna nag about first,just to get it over with then i will say some nice things i promise, well first off, too some people dry text is too hard for the brain to process, i would recommend to spice it up a little with some more colors maybe, and more visual stuff for lazy people, and also a big thing is i would really just give this a top 10,

if you would go into more detailed on some of the thing's you talked about as enfernikus said, some points started good but faded out into something else and then was dropped and yeah well.


Now that i have said that, i would like to thank you first of all for a great read, i applaud some one who makes an effort into the work, it was good, but everything can be better :)
nice visual, it needs some more i think.


I liked it well yeah i might edit this text with some more thing's i like to say, i give this a 8.2/10. if you take some notes and do some changes i think you can make it to 10. i know you can! keep it up and look forward to more articles from you and also see the changes you make to this one if you do. Thanks mate!

__________________
Codefreek's - News Letter, Tech, & some random ramblings

Will do.

Please do nag about them so I can fix them.

Definitely a good idea, I'll see how I can add more illustrations.

If I could write in such a way that would fend off lazy people, I would. Anyone who is too lazy to read three to four pages shouldn't be programming for the sake of the next guy.

Can you be a little more specific? What points needed better explanation?


Thanks for the kinds words.

Thank you very much for the critique so far, I will try to get an updated version out soon.

__________________

i don't really wanna say what you should change in the text i would more like too see you look at it and maybe figure out what could use, more explaining, i will look into the text one more time, to get more of a vibe what i would like to see be explained more, but i hope you can see it for your self :)

on the spelling mistakes, well not that big of a deal you missed "Frank wants to his friend’s house", should have a go to, in it, and also, hum now i forgot the other ones.. i will edit it in after i read it again..


-Cf

__________________
Codefreek's - News Letter, Tech, & some random ramblings

To expand upon my original post, I found when I first started programming for larger applications the hardest part wasn't the actual scripting/coding/programming but planning out the object and really keeping it concise and deciding what functionality goes in which object.

For instance, when I was working with Cruise data, the question was what sort of information should the Cruise Liner Object have? What sort of functionality should it have? Should their even be an object for a cruise liner?

Are itineraries ( their sailing plan ), which are intrinsic to ships, dependent on the ship object or should I make it independent?

__________________
My Blog

This is just a quick write, I intend on expanding further later. but is this what you are taking about?

Objects are designed to give you reusable code. But what does reusability really mean? Reusable code has two possible meanings

1. Code that will be used many times though your particular program
2. Code that will see uses (whatever the amount) in many different programs

The first use, code that will be used many times in your program, is probably what you’ll end up writing the most unless you repetitively do the same area of programming. These objects contain common functions and variables that are used many times throughout the program. When I write games, virtually every item of importance needs the following: X position, Y position, display image, direction, speed, functions to change all previously mentioned, a checker to see if the X and Y cords are in or out of the screen and many other common functions. Since everything uses them, I make an abstract class (a class that can only be inherited) and inherit that class for everyone one of my objects that require it. This alone saves me 300+ lines per object I need to write after that.
The second use is not as common, but can prove more useful. Most advanced programmers have a set of objects they use for almost everything. These objects complete generic tasks that cover a wide range of things. If you are a computer programmer in C, you might want to have a class that opens a window very easily (it is time consuming to do it from scratch). Higher level languages (like PHP, VB and python) don’t as often require these generic classes since the tedious low level stuff is taken care of for you. But a PHP programmer may have classes for SQL interaction or user authentication. This way the programmer can complete tedious but common tasks by just copying and pasting these classes into their application.


Classes, however, need to be written right to achieve this reusability. As mentioned before, specifics that are not reused should not be placed in a class. To continue with the games I write, let’s say I’m writing a game of pong. Two of the objects I need to create would be a paddle and a ball. Both these objects require the characteristics I named in the second paragraph. So I make a ball and paddle class that both inherit these properties. So then I only have to do the following (written in pseudo-code to maintain language independence)
And that’s it! Both my objects inherited the common properties that they use. Now all I needed to do was specify the specifics and I have a working object. While the ball and paddle classes are specific to this program, the paddle class will be used twice and the ball class may be used more than once. Due to their need for lots of robust functions, they belong in a class. These classes will probably see no use in a later project, the object properties class will.


So what should we avoid placing in classes? Anything non-generic. Different classes do have different levels of needed generalness, the object_properties class has to be extremely generic and only contain the properties that every graphical object would require. The paddle and ball classes were specific to this program, but would be used multiple times in that single program. If I were to have placed the key bindings in the ball class, what use would that be of? That would be needlessly adding a specific feature to a general object. This is where you come into the picture, there is no set answer to what should go in and what should not. Only you can decide where your code needs to be placed. Although, here are a few guidelines to help you decide:

1. Ask yourself “why should this be a class”. If you cannot answer this, it probably should remain outside of one.
2. Ask “would I have to rewrite this multiple times if I took this out of a class.” If the answer is yes, it probably should not be in a class
3. Do your programs have lots of variables defined at the global scope that have numerators (var paddle_1, var paddle_2, ect). If so you might want to be using an object to reuse the code.

__________________

nice work, :)

__________________
Codefreek's - News Letter, Tech, & some random ramblings