I've been thinking about Object Oriented programming lately, especially after my current job and the job I had at the end of last year. Object Oriented Programming (OOP) is what I do and there are similar concepts in databases. Basically, the idea in OOP is to take your program and group the code by actions or descriptions. If you have 32 buttons that all do the same thing, create a single section of code that they all use. If you have a bunch of different actions that all at some point do the same thing, have that same thing in a single section that they all use when appropriate.
The problem here is that I think people get carried away with this. Additional aspects of programming are readability and speed. On this project and last fall's, the programmers have taken every little thing that could possibly be reused and placed it in its own section. This means that there are times code will be running when it
jumps off into another place, which is ok, but then it
jumps off into yet another place and then
and yet another and at this level, you're doing something that's really only 1 line and by putting it into its own section you're using 6 lines where 1 would do and passing information many times and perhaps asking other information to be passed back, which reminds me, it is time to jump back to the previous spot
and back again
and back again
and maybe out again
and back again
You get the idea.
There are times the same procedure will make 5 or 10 calls to procedures that could be done in-line, like passing a variable to a single line that uses a built-in function to determine if the string contains an apostrophe, for example, before passing it back.
This becomes hard to follow fairly quickly. It isn't hard for the computer to follow, but it is for any programmer that might need to make changes or updates. And as I said, there are plenty of times these things can be done in a single line in the code instead of sending out to subroutines. Readability is important.
In addition, I know everyone says it doesn't matter now 'cause computers are so fast, but all these calls to smaller and smaller bits slow down the process and use more ram 'cause of all the information being referenced. I say it is bad practice.
In databases, astonishingly, the opposite tends to happen. You should "normalize" the data so everything that is non-repeated information about an object is in the same table, to a point.
For example, if you're putting together information about a person you could have First Name, Last Name, Age, Street Address, City, State, Zip, Home Phone, Cell Phone, Birthday, job history, etc...
You'd want to have job history off in a related table 'cause there could be many jobs that each person has had. You probably wouldn't separate Phone Numbers into their own table, though you could, because you're only looking for 2 for each person.
Unfortunately, you'll frequently see people creating tables that have Job1, Job2, Job3, Job4, Job5, Job6 as fields in a table and this is just wrong for many reasons. Even worse, I've seen a number of databases lately that have UserInfo1, UserInfo2 and so on. These fields don't even have specific data associated with them. The people that created this think they're being flexible when they're really being lazy. And I encounter the same arguments here "It doesn't matter because storage is cheap and computers are fast" as though that's a good reason to do something the wrong way.
So this is what I'd like to hear your opinions on.
Am I nuts for thinking people are overdoing the object-oriented division into little procedures?
Am I just wrong here and that's the right way to do it?
Was I wrong? If so, I'm sorry.