Tonight I was having a little bit of fun explaining object-oriented programming to my girlfriend. She isn't completely computer illiterate, but doesn't know enough to understand what all goes into programming. We've been dating for 6 months now, and I've always been programming, but I couldn't always fully explain what I was working on to her. I've been doing a lot more lately, and I'm always excited when I add a new function or something, so I figured it would be nice to explain it to her.
I started out by saying in OOP, you create these classes, or objects. Objects in programming are kind of objects in the real world, like a car. A car as certain properties, such as number of doors, size of the engine, and whether it has a CD player or not. Code objects have properties too. In nGallery, we have an Album object, which has properties of the ID, the album name, and the description.
Objects also have functions. In a car, you push a button and the window rolls down or you turn the key and the engine starts. Code objects have functions do, where you call a function, pass it some input, and it returns some data or gives a response.
She got all that pretty well, but then I was explaining abstraction. In nGallery, we have multiple data access methods. We have a DLBase, which creates all the abstract functions and then a DLXML and a DLSQL which all override and expand on them. She didn't get how you send the same data, get the same data back, but it works differently. So I explained it like this... using cars again, I said you have a carburated car and a fuel injected car. On both, you push the gas pedal, and it moves, but internally, it is working a little bit different. Even though it works differently, you use it the same.
Once she got all that, I was able to explain multi-tiered design. nGallery is the first OOP program I've work on that used a true tied design. My classes taught me how to do it, but never really in practice (a big problem I have with the educational system). We have a UI layer, a business layer, and a data layer. Each layer interacts with just itself, or the layer above or below it. The UI layer talks to the business layer, which talks to the data layer, and returns the data needed. The data layer cannot modify the UI or the page being shown and the UI layer cannot change how data is stored. They pass our Album and Picture objects through each other until it gets to where it needs to be. This is nice since how you store data is only done in one place, instead of like 10 different places like can happen in a procedural language. Then, since we have an abstract data layer, you can easily create new data storage types and just create the functions for it and the rest of the program doesn't care how it is stored as long as it works the same to it.
She kind of got it all. I was kind of proud of myself that I was able to make most of it make sense and now it'll be a little bit clearer the next time I tell her I was programming something. Told her that she really has to see it work and see the code to understand the structure, so I'll have to remember to do that the next time she is over.
This is my first post to my new blog. I've been a long time LiveJournal user, but have been straying away from it more lately. It is mostly just personal, day-to-day posts and I wanted a place for technology/development type posts. I still update my LiveJournal, since my parents read it from time to time to make sure I'm still alive and the more I update it the less they call me to see what's up. :)
So, some information about me. I am a 22 year old senior at CSU Sacramento majoring in Computer Science. I have 3 semesters left (I hope... 5.5 year plan). I also work at the CA Department of Motor Vehicles. I work at the headquarters, not the field office. I don't have access to the drivers license or vehicle registration databases, so don't ask me to do anything for you. I don't know what form you need to fill out to do *fille in blank* either. I am a programmer, so I don't deal with any of that (I have no people skills).
Some of my current projects include:
nGallery - I am one of the main developers on nGallery, an open source web-based photo gallery written in C#. I work closely with Jason Alexander, who has done a tremendous job on it. I mostly responsible for the SQL Server support and the image processing stuff. If you have any problems with either of those, I am to blame.
At the DMV, I am the primary developer on a web-based cost estimating system. Basically, any state legislature bills that are proposed have to have a dollar amount attached to them. If they have any impact to the IT department at the DMV, it comes to us and users enter in what programs they'd have to modify or systems they'd have to purchase and we send it back saying it would cost $X. Its written in ASP and using SQL Server 7. They're finally deploying SQL Server 2000 to our test environment in December, and production by Jan/Feb. I've wanted to rewrite it in ASP.NET, but they said no since their core infrastructure is J2EE and don't have any plans to go .NET.
Additionally, for school I am currently working on my Senior Project for the CSUS Office of Community Collaboration. This project is a small faculty survey system for service learning programs (basically, internships in the field for students). I'll run through all of the CSU system and get information on faculty and community partner's satisfaction with the students and cross-reference it with student satisfaction across all the campuses and various classes. I have the joy of being the Project Manager for our team, Dataformation, so it is a nice learning experience. We are still in the early stages. It utilizes the full IEEE development lifecycle, so it is well documented. We aren't even to the Requirements Specification yet. It will be in ASP and SQL Server 2000. I was pushing for ASP.NET (they said it could in the beginning), but the sponsor said no, and you have to give the client what they want. Boo.