[n00b warning!] "Procedural" vs "Object Oriented"... what?

S

starhawk

[H]F Junkie
Joined
Oct 4, 2004
Messages
8,908
I'm a n00b when it comes to any real programming anything. I know just enough QuickBASIC (remember that crap?) to hammer out my sig and stuff of similar (non-) sophistication.

That is to say I don't know crap.

My admittedly primitive understanding is that QuickBASIC and similarly-designed, similarly-antiquated programming languages are "procedural". That is:

10 IF this condition is met THEN do this thing ELSE do some other thing
20 PRINT blah blah blah
30 GOTO somewhere else​

Obviously nowhere near a real program! But in no case does the computer execute line 30 before line 20. Things happen in a "procedural order". Instruction One, then Instruction Two, then Instruction Three. Thing 2 never goes before Thing 1.

That's how I'm used to thinking of programming. But every time I hear about a programming language these days, the buzzword "object oriented" is thrown in. WTF?

So far I've basically just ignored it.

Thing is, I'm now thinking that it would be really good for me, income-wise, to learn Java. The idea is, learn Java on a PC. Save up for a cheap but half-decent tablet. (Something just a little nicer than what eBay hands out for $50.) Then make games and such on the tablet with Java and sell them cheap on That Thing We Used To Call The Android Market and make some dough.

Java, as I (again, quite primitively) understand it, has more of this "object oriented"-ness to it than any other language just about. So I've finally got to learn this shit, I suppose. (I guess it was bound to happen somehow.)

So I ask:

In simple English for a simple mind, accustomed to the sort of programming languages cavemen were using when they discovered fire (lol) --

What the SHIT is "Object Oriented" programming?
 
Object Oriented programming is just hiding underlying data and code and displaying it as a more real-world concept. Underneath it's still executing code in a very linear/procedural fashion. Load some data, call some functions, get results, do comparison, do some looping, call some functions etc. It's just so the programmer can look at a higher level view of their programs. They can think in terms of how these objects interact instead of the specifics.

So you know that most languages have some basic types: integers, floats, strings, etc. And some functions or operations you can perform "on" or "with" those types. Well Object Oriented languages let you define your own types and functions to operate on those types. Underneath they're still composed of the basic types, and the functions are written like any other procedural function with conditions, looping, and manipulating the basic data.

The types you define are usually called "classes" or "objects". The functions that operate on them are "member functions" or maybe "class functions", meaning they only operate on that class where they were defined. You hide the internal data of the class from the outside world, only allowing them to use your functions to manipulate the data. The data could also be another class, but eventually it can all be broken down into the simple data types.

Some languages like Java force you into an Object Oriented style, which sometimes doesn't make sense. C++ gives you more freedom, so you can write a mix of procedural and object oriented code. I felt the transition from C to C++ was pretty natural, just extending what I already knew about writing procedural code. If something was confusing I could always go back to writing it C style.

I had a bit more typed up, like inheritance and interfaces, but felt It would have been too confusing / overwhelming. Let me know if that makes sense though. I felt the same way when I started, programmers like to throw around "fancy" words and terminology.
 
OK... so first question. What's a "function"? Is that like the "subroutine" of old?

10 PRINT
20 GOSUB
[...]
210 END
SUBROUTINE
220 do stuff
230 do more stuff
240 RETURN

Also, go ahead and tell me what you can. The point is for me to learn ;) If I don't understand I'll ask questions! Just keep in mind... simple English is best. 80% or more of what I know I learned around 1998 on a secondhand 386 with QBASIC and Windows 3.1 (ah, those were the days :D )...
 
Most likely, if you could pass parameters and get a value returned to you... that's all a function does in C / C++, or any language I know of for that matter.

Games can be harder to write though. Some developers are barely selling a few hundred copies of games they spent months on, and they have small teams of people with artists, etc. Android market is just way too saturated with apps, let alone games.
 
starhawk said:
...crap.
Click to expand...
Programming, in general, is not easy. Work through learning how to program, but set your big milestone at something more realistic at this point; one idea is a simple turn-based game, such as tic-tac-toe. If/When you hit that milestone, then you can reflect on the thought of pursuing programming or game development as a career or hobby.
 
I was actually thinking of a more retro-style thing than Angry Birds type stuff...

Anyone remember text adventures? :D
 
starhawk said:
Anyone remember text adventures? :D
Click to expand...
Text based games are a great place for a beginner to start. In that genre, you'll focus on game play and implementation and won't get distracted with graphics, artwork, and sound.
 
mikeblas said:
Text based games are a great place for a beginner to start. In that genre, you'll focus on game play and implementation and won't get distracted with graphics, artwork, and sound.
Click to expand...

+1.

It's actually pretty damn good idea.

Zork on mobile phone? Win.
 
Yeah, doesn't sound like a terrible idea. You just need to release it as free, then nickle and dime the user for new areas and content. :D Probably the only way to swim with market saturated with so many people who are ahead of the app making curve.
 
Oof. I *LOATHE* "freemium" shit. My mother played Farmville for a while. Part of the reason she stopped was because the Zynga game cards were really eating into our budget. But, while technically you can play FV without spending money, it's hard and disappointing.

I've got a better idea. Release a couple small games for free, and then make much bigger and nicer ones that cost a small amount of money. "Oh, it's only $5, I can do that!" adds up real fast, trust me ;) Happens to me (in the wrong direction of course) almost every month!
 
Ummm. there is a lot of information out there if you search the net on object oriented programming. I doubt any of us are going to be able to hack out a short paragraph that more clearly describes it than what you can find elsewhere.

In a procedural language you can write a piece of code that accomplishes some task or represents some sort of functionality. In an objected oriented language such as java, you can define an object which groups a set of functions and properties so that you can create this object, execute it's functions, and interact with it in reusable way. If someone were to give you this object definition and a list of what functions it had, you could create and use it, but without needing to know how it works internally.

Let's think of something in the real world... such as a Microwave. If you were trying to write some code that represents a Microwave, in Java you could create a "class" called Microwave. What do you expect a microwave to be able to do? Accept input about how long it should run, start the cook cycle, count down and alert you when it is finished. Let you see how much time it has left, etc. So basically, you can create a method (similar to procedure) called "SetTime" which takes the number of seconds, another method called "Start" which stats the microwave, and the microwave may raise a notification or event of some kind when it is finished cooking. It could also have a "GetTimeLeft" method which returns how many seconds are left to cook and a "Stop" method to stop the cook cycle. The microwave object would contain all of these functions and its internal state information to make this all work.

Once you have defined all the functionality of a Microwave.. I could then use it to create a Microwave Object in the program and interact with it to achieve my goal. I could even create two, three, four, or more Microwaves simultaneously and interact with each one.

Now obviously, this is a bit sily of an example... but in the real world there are objects of all types such as Lists in which you can create a List and then Add, Remove, or Find data in the list, ask it for how many items it contains, etc.
 
I started with Perl and learned that for a couple years,but then I took on Ruby due to a certain project. I am totally self taught so far (and I'm sure my ettiquette shows :) )

In Perl you have 3 general types of Data. String, Array and Hash. Each of these is identified differently;

$string
@array
%hash

Whats great about this, and Perl especially, is that the compiler will always know what type of data it is and as a result what can be done to that data. Perl is also a very lazy language, in a good way though. It will often assume certain things which means you don't always have to tell the compiler things ahead of time and it will fill in the blanks. As long as you understand how it will fill in those blanks, it is very handy.

The downside is that once a variable is created it will always be whatever type of data it was made as. So an array will always be an array. If you want to make a string out of it, you have to create a new instance, which means more memory allocation and more processing time. Perl is absolutly fantastic when working with raw data. But as a result you will never see a video game written in Perl.

When I moved to Ruby it was a learning curve for me. An "object" can be anything. You still have the string, array and hash concepts. But a variable can be any of those and can be modified from one to another. This allows you do some pretty cool stuff as the program (or your abilities) get more complex. But the downside is that the compiler can't be "lazy" like Perl because it can never assume anything about a variable.

One thing that really threw me was autovivification. This was something I got really used to doing and didn't even realize it was special. It allows you to assign arbitrary elements within an array or hash in Perl without worrying about anything else in the data set. For instance I could say

$arrayname[3] = "testvalue";

Perl will create the array @arrayname. It will then create elements 0,1,2 and give them no value and then it will assign element 3 with the value of testvalue. This goes back to Perl being lazy in a good way.

Well when I went to Ruby this didn't fly. Because the compiler cannot make assumptions about the object. I have to tell it to create an object as well as what type of data that object is currently.

My suggestion is find a PDF of a good beginners book of the language your thinking about. Come up with a project. It can be anything, maybe something that organizes all your songs in a certain way (reads metadata info). And make it interactive so that you have to deal with working with user input and displaying to screen in a ledgable way. Then try to figure it out. Every time you get stuck go straight to Google and type what your problem is. Look for search results pointing to Stack Overflow website, they are usually very helpfull for most all languages. This will teach you basic logic issues. Don't be afraid to draw it out on a piece of paper too, this helped me a couple times. Then move on to the flashy stuff. Start small. You will look the same information, it will just be more managable then something like a game.
 
I'm a very beginner C# learner (first language I've learned except very basic html) and the biggest problem in getting my head around the concept of OO programming is that people keep describing it as "looking at the bigger picture", not having to focus on the specifics, etc, but as someone who has never had to focus on the specifics that just doesn't tell me anything. Those microwave and "creating a human" examples can only take you so far ; )

The best way to explain it to a person like me would be code snippets of how you would go about solving a problem in an OO language, like C#, and in contrast how it would work in something else.

So C# has methods, and classes. I can write some code in a class or a method, and use that code later down the line if I need to. Is that all there is to it? And non-OO languages do not have those two elements?
 
Well I would classify myself as a beginner as well. With OOP you do need to keep a mental note of the specifics. You need to know what the data is when you to apply a method to it.

For example in Perl if you create a variable that is a "string" then you are only allowed to use methods on that variable that are valid for strings. If a method requires an array then it will fail when it compiles because the compiler knows that the method can't be applied to that data type. But in OOP any method can be applied to an object. But if the object internally is not the right data structure the program will fail. So as the programer you have to keep a mental note of whats going on with the data.

For me transitioning from procedural to object orientated was quite a learning curve. I taught myself, so it was mostly A LOT of running into walls and banging through it until I made it work and then figureing out WHY it worked. It was frustrating.

I think procedural is more linear and easy to understand, but at some point you reach a point where it just doesn't cut it anymore and you need the flexibility of OOP. Again, theres no games made in Perl. Not because Perl sucks, just it sucks at that specific task.
 
westrock2000 said:
Well I would classify myself as a beginner as well. With OOP you do need to keep a mental note of the specifics. You need to know what the data is when you to apply a method to it.

For example in Perl if you create a variable that is a "string" then you are only allowed to use methods on that variable that are valid for strings. If a method requires an array then it will fail when it compiles because the compiler knows that the method can't be applied to that data type. But in OOP any method can be applied to an object. But if the object internally is not the right data structure the program will fail. So as the programer you have to keep a mental note of whats going on with the data.
Click to expand...

The "data" you're referring to should really be instantiated objects as in complete object oriented languages the programmer don't pass unstructured data to methods. Because the parameters of the method have a type, the method won't accept an object that's incompatible with its action. OOP doesn't guarantee that "any method can be applied to an object"; quite the opposite, in fact. If such a method does exist, then whoever designed the object model of the program did a very poor job as they've managed to defeat one of the primary advantages of object oriented programming.

Frozen Bubble is probably the most famous example of a game written in Perl. Perl is of pretty dubious value, if you ask me; and Perl games are rare indeed, but they do exist.
 
OK, starting to feel like I need a glossary here :p

What is a "method"? Is that like a subroutine?
I know "function" has a different meaning in OOP from that of real life... but I don't know what it is ;)
"Class"...?
"instantiated object"...? That's a $2 phrase, where I live!
"object model"...?

What I meant by "procedural language" is eg QuickBASIC (see my sig for an example) where you have line numbers, goto's, and subroutines that branch off and return (which is as close to nonlinear as it gets). I'm guessing that the "procedural" label is possibly not correct here because someone in this thread (can't find it quickly) used the term "procedure" as some sort of discrete element of the language, ie "a procedure"... what? I was referring to the iron linearity of the language more than anything else.

I know most of my variable types, at least... but I can look up the ones I don't understand myself, later ;) I don't think that's really needing to be part of this thread.
 
Yes, a method is like a subroutine. The difference is that a method is associated with a class, while a subroutine is global. In OOP, a class is a definition of code (methods) and data. It provides a template for creating objects at run time.

You could learn these terms yourself if you had any initiative. Any OOP tutorial will define them very early, as would any tutorial of an OOP language.
 
mikeblas said:
You could learn these terms yourself if you had any initiative.
Click to expand...

I find this statement a bit harsh. I have plenty of initiative.

I want to learn this stuff. I created a thread on a forum to get the basic concepts down so I know (eg) what to type into google to find further material. My google-fu is very weak (old man) anyways.

What I /don't/ have is money for subscription-based online stuff, or for that old-fashioned stuff that USPS now calls "bound printed material"... what was the layman's term for that... oh yeah, "BOOK". Those cost $30 at least -- and that's about $30 more than I have right now. I also /don't/ have the knowledge of where really even to look for free online tutorials and such -- at least, beyond what little google will give me. (I've already done that search. I got one result that looked mildly promising initially, and then I realized it was probably not going to help after all.)

If someone would kindly point me to some good free online tutorials about this stuff (OOP, regular Java, and Android Java) rather than making harsh, accusatory, and non-constructive comments... this would be quite helpful indeed.
 
Knowing how to google is the most important thing you will (need to) learn as a programmer.. Even the most experienced programmers probably go to google to find some stuff, if not because they can't solve the problem theirself then because it's easier to use someone elses code. So figuring out how to find a basics tutorial on google should probably be your first task.

Hint: type in "java basics tutorial"
 
starhawk said:
If someone would kindly point me to some good free online tutorials about this stuff (OOP, regular Java, and Android Java) rather than making harsh, accusatory, and non-constructive comments... this would be quite helpful indeed.
Click to expand...
Searching for "object oriented programming tutorial" gets some great results: The first is a link to a Java tutorial at the Oracle website. It has brief answers to all your "what is?" questions and links to more detailed information. You can chase down the details or follow the tutorial step-by-step. Seems like you should do both.

Sorry if you find my appraisal harsh, but having initative means that you take action to overcome your limitations -- not that you make excuses. I'm curious: what specific searches did you try? I'm further sorry that you didn't find my response helpful, as it includes answers to two of the questions you asked.
starhawk said:
Those cost $30 at least -- and that's about $30 more than I have right now.
Click to expand...
Used books are very inexpensive. At amazon.com, it's not hard to find OOP programming books that cost less than a dollar and several are listed for just a penny.

Magix said:
Knowing how to google is the most important thing you will (need to) learn as a programmer..
Click to expand...
Using Google can be helpful, but someone who relies on it too heavily will never be better than the solutions they happen to find.
 
Last edited:
Looks like that might help with Android development, but if you're interested in teh fundamentals you'll be left wanting. For example, they begin using the term "method" before ever defining it, and I don't see an explanation of the term proffered in the first three sections.
 
I'll start with the wiki stuff, and then look at what you posted, mikeblas, and then I'll look back at the Android Java bit.

At least, that's the plan right now ;)
 
mikeblas said:
Using Google can be helpful, but someone who relies on it too heavily will never be better than the solutions they happen to find.
Click to expand...

Depends on how you learn I suppose. If you grab a tutorial/book and learn step by step, google won't be that necessary. But I suspect many people will prefer to learn by making things they want, and as such will run into problems or concepts they're not familiar with. So you use google to figure out how to overcome those obstacles. If that's the way you learn, I wouldn't say using a search engine is helpful, but unavoidable. =P

Of course, if you just look up code snippets and copy/paste them into your editor, that's not gonna help much. I'm talking more about looking at the solutions, figuring out the principles, and recreating them for yourself
 
Magix said:
Of course, if you just look up code snippets and copy/paste them into your editor, that's not gonna help much. I'm talking more about looking at the solutions, figuring out the principles, and recreating them for yourself
Click to expand...
I don't know of any formal studies of the behaviour, but I think the majority of developers copy-and-paste without understanding the code they're adding to their legacy.

Informally, it's certainly demonstrated that blindly copy-and-paste. When working at Microsoft, we discovered that code examples in SDKs and help topics was very important to review for security issues because it gets reused without review very, very frequently.
 
Hey guys I think I get it...! Let me see if I can do this...

You have a class or type. Say, "car". Within that class (I'll just use that word for now), you can define objects -- instances (examples) of the class that have attributes. So... within the class "car" you could have, eg, "Saturn SW2" with attributes "1998 model year" "dark blue exterior" "beige interior" "poor interior trim condition" (lol) "soft tires" etc. You can observe these conditions, eg "get interior trim condition from car(saturn sw2)" or "get model year from car(saturn sw2)" etc. You can also modify some or all of those attributes -- "set.tires car(saturn sw2) = 'properly inflated' " etc. You can also define functions/subroutines that modify those attributes, eg "repair.trim.interior on car(saturn sw2)", etc.

I know my syntax is probably way off for eg Java, but it's pseudocode anyways so I don't think it matters all that much :p

Whereas, in a linear (or as I've probably incorrectly been calling it, procedural) language, you can do the same sort of thing but it's rather a bit different.

CARTYPE$ = "saturn_sw2"
CARYEAR% = 1998
CAREXCOL$ = "dark_blue"
CARINCOL$ = "beige"
CARTRIM$ = "poor"
PRINT CARTYPE$
GOSUB
REM fix car trim
CARTRIM$ = "slightly_worn"
RETURN

...etc. BTW that's old QuickBASIC / QBASIC (QBASIC is interpreted-only, is the only difference) so $ is string and % is IIRC integer variable declarations. Also "LET" is a waste of space in Quick/Q BASIC land :p

Am I making sense here, with these explanations? Did I get it right?
 
Object instances will be external to the class. In Java parlance, you would do something akin to the following:
Code: 
Car saturn_sw2 = new Car(/* parameters */)
...within a function, or you may instead wish to initiate new instances of Car as members of another class, perhaps of type DealerInventory. In a DealerInventory class, you may have an array to hold many instances of Car to express a has-a relationship between the DealerInventory and instances of Car. This relationship binds the lifetime of Car instances to the instance of DealerInventory such that Cars are destroyed when DealerInventory is destroyed.
 
So, per my example with (well, actually...) my mother's car...

Moms_stuff = Car

Car saturn_sw2 = new Car(year = 1998 /* etc. */)

OK so how do I do multiple attributes? Arrays are one data type I've never understood hardly at all. But I know if I can learn a whole new programming paradigm that I can get my head around arrays :D
 
starhawk said:
Am I making sense here, with these explanations? Did I get it right?
Click to expand...
What you're missing is instantiation, and it's a fundamental concept of OOP.

In BASIC, you're creating global variables and using those variables from globally scoped code. With the scheme you invented, you can possibly only consider one car at a time. If you wanted to think of more than one car, the best you can do is construct an array of types for each of the attributes of the car you'd like to manage.

In any OOP, you'd instead build your own new type -- a class -- that holds all of the data associated with a car, plus all of the code that touches a car's instance. In OOP, that data can be made private so you can be perfectly sure that the data associated with a car is only touched by the code directly associated with a car. In BASIC, everything is global; any code touching a car might touch the one car with very simple bugs, and there's no protection, scoping, or encapsulation.

Funny thing is, the pseudo-code you write would really be exactly the same as it doesn't really acknowledge the scope of the data you're touching. In BASIC, we know that each of those variables are global because BASIC doesn't support scoping or encapsulation. In OOP languages, you'd inherently have scope within the member function and the members would be instances within the instance of the class you' were initializing.


You'll probably have a better time with the OOP concepts if you neglect your previous knowledge of BASIC, as that language simply can't represent the concepts you're trying to learn.
wonderfield said:
Object instances will be external to the class.
Click to expand...
This isn't accurate. Object instances are an instances of a class. A class is just a concept; an object is something that's in memory and exists.

starhawk said:
OK so how do I do multiple attributes?
Click to expand...
What do you mean by "do"? How do you declare them? How do you instantiate them? How do you initialize them? How do you access them? Something else?
 
mikeblas said:
This isn't accurate. Object instances are an instances of a class. A class is just a concept; an object is something that's in memory and exists.
Click to expand...
That is why I said it is external to the class. The instance of the class does not appear within the definition of the class itself.
 
By "how do I do" I meant:

Class object = new Class (attribute)

How do I insert more than one attribute in the () -- it's the syntax (a linguist would say "punctuation") that I'm missing. Is it attribute1,attribute2 or attribute1.attribute2 or attribute1;attribute2 or ... ?

I'll look up instantiation, although it'd be very helpful if you were willing to post a simple explanation -- wading through Wikipedia's jargon fields is a little difficult at times, to say the least...

Also, a similarly simple explanation of array variables would help tremendously.

I can understand just about anything if you break it down into simple parts ;) but my brain is a bit simple itself...
 
All of this information is in the Java reference. I'll give you a hint, however: construction.
 
wonderfield said:
That is why I said it is external to the class. The instance of the class does not appear within the definition of the class itself.
Click to expand...

An instance of a class can appear within a definition of the class.
starhawk said:
By "how do I do" I meant:

Class object = new Class (attribute)

How do I insert more than one attribute in the () -- it's the syntax (a linguist would say "punctuation") that I'm missing. Is it attribute1,attribute2 or attribute1.attribute2 or attribute1;attribute2 or ... ?
Click to expand...
There are several ways to do it. You can pass multiple parameters to the constructor, or you can use setting access methods, or you can use the builder pattern.
 
If this helps. Here's a general rule (and with plenty of exceptions to the rule)
Class = blue print of an object (ignoring static stuff for a moment). Typically, but not always, the variables are empty and not filled with data (numbers, strings, etc..)
Object = an actual item based off the class blue print. [Car analogy alert] Going off the dead horse of car analogies, I have 4 wheels to my car, they are 4 objects based on the class (blueprint) of a wheel. The data within the object is typically intended to have their variables filled up with data (again number, strings, etc...). You declare a new variable from a class and instantiate it. Each time you create one, you are adding more info to load into your computer's memory.

Methods/Functions = The verb or action to take. Maybe the wheel object has the method/function of "Spin" or if you will, "SlowDown". Methods among other things can tweak the nature of an object, i.e. change the data of the object. Maybe the wheel has a variable "NumberOfTimesSpinned". Let's say NumberOfTimesSpinned = 7. If I call "Spin" then NumberOfTimesSpinned = NumberOfTimesSpinned + 1, thus an a variable inside the wheel object changed.

This however does nothing to change the class (blue print) of wheel.

Magix said:
Knowing how to google is the most important thing you will (need to) learn as a programmer.. Even the most experienced programmers probably go to google to find some stuff, if not because they can't solve the problem theirself then because it's easier to use someone elses code. So figuring out how to find a basics tutorial on google should probably be your first task.

Hint: type in "java basics tutorial"
Click to expand...

google or stack overflow? Google usually just links to stackoverflow pages, with the occasional blog piece to mix things up. :D
 
It might be more accurate for me to say "a class can be defined to contain an instance of another class". The class definition defines what's in memory. Consider this example in C++:

Code: 
class Color 
{
public:
	int r, g, b;
};

class Car
{
public:
	Color colorInterior;
	Color colorExterior;
};

The Car class is defined to have two instances of the Color class within it. When the Car class is instantiated, it will have two instances of the Color class within it. We can see, then, that object instances are not external to a class; this principle is called "containment" or "composition".
 
starhawk said:
I find this statement a bit harsh. I have plenty of initiative.
Click to expand...

In this case I don't think he is being harsh. Programmers have to learn a lot on their own, even every day, no matter how long you have been doing it. Even if we explain the basics of OOP, there will be an endless supply of questions and knowledge for you to research and discover.

I know you've had some good discussion on this thread since then, so I do not want to distract too much, but I think that is where he is coming from (i.e. you won't get very far unless you can research and learn foreign and at first confusing concepts on your own).
 
I'm starting to get really confused.

I think, since I'm wanting to learn the Android flavor of Java, that I'll just see if I can get a book from Amazon that can teach me. I'm pretty good with books, and generally they give me enough of a clue to go on Wiki or Google to find what little they don't explain...
 
You must log in or register to reply here.
Back
Top