Explaining Object-Oriented Programming to Laymen
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.