Is Learning OOP in C a Good Way to Understand OOP in Other Languages?

[vg19]

Hey,

I started off programming in high school with Turing. I continued with that until Grade 10 and in Grades 11/12, I learned Visual Basic. In year 1 of university, I learned C, and now in Year 2, we are being taught Java.

My problem is Java seems very foriegn to me. No matter how hard I try, I find myself not really understanding object orientated programming well. I fully understand the concepts of procedural programming, but Java is really getting me frustrated.

I just wanted to know if this normal? I thought having a solid foundation of programming would allow me to do well in Java, but it seems to be the opposite. Any advice? Would you be able to reccomend any good resources, whether online or books?

Thanks

 

[verty]

I have found OOP to be murderously annoying because it was explained to me with examples like "a dog is an animal" but that is far away from coding something.

Surprisingly, the book I found the most enlightening was http://mitpress.mit.edu/sicp/full-text/book/book.html. It helped me to realize that cons, car and cdr are the same thing as constructors and selectors on objects.

I have also read "Object Oriented Software Construction" by Bertrand Meyer but I don't feel like I really gained that much from it. More than anything it showed me that OOP can be taken to unhealthy extremes.

A book I did enjoy was "Programming Langauge Pragmatics" by Michael Scott. It isn't a book on OOP but it should serve as a bridge between languages.

 

[haki]

vg19, I had the same problem, it is perfectly normal. Its funny that the computer doesn't think in terms of Objects nor do we at first. But OOP is the greatest thing ever in programming. I didn't tough like that at first but after half a year in OOP I don't imagine going back to procedural programming. Just note OOP is great but it takes some time to get familiar, going from procedures to OOP is not an over-night process.

I found this IDE very helpful - BlueJ http://bluej.org/about/what.html it forces you to think in terms of Objects rather than procedures.

OOP: -low level view: OOP is just a technique on how to package your source code, instead of having one giant file with huge list of methods, they are packaged into neat small coherent units.

-high level view: OOP is a technique that enables you to model real-world Objects or abstractions in your code.

You might enjoy this sample chaper, of the book Head First Java, it explains OOP.

http://www.oreilly.com/catalog/hfjava/chapter/index.html

see A trip to Objectville.

 

[Jheriko]

If you have used Visual Basic, haven't you ever wondered how to make something like "Text1" where you have a list of properties you can modify, e.g. "Text1.Left", "Text1.Caption" and functions you can call "Text1.Hide"?

This was how I first picked up the ideas of OO programming. There is nothing really complicated about it until the long words are introduced, like inheritance and polymorphism... but its best to leave those things for later. Really all that OO functionality is (at the beginning) is wrapping functions and variables under a header like "Text1" to make it easier to read the code. If you have written any large procedural programs you have probably made functionality which is equivalent by hand without even realising it...

For example, in a C++ program you may have some functions like this to provide some counters.

static int c[10];

void counterInit()
{
  for(int i = 0; i < 10; i++) c[i] = 0;
}

void counterReset(int counter)
{
  c[counter] = 0;
}

void counterIncrement(int counter)
{
  c[counter]++;
}

void counterDecrement(int counter)
{
  c[counter]--;
}

int getCounterValue(int counter)
{
  return c[counter];
}

You could dynamically resize the array and etc... to allow for more than 10 counters, and add some safety checks etc... to allow for endless numbers of counters, but its a lot easier to just make a class:

class counter
{
private:
  int c;  // member variable
public:
  counter() { c = 0; }  // constructor
  // member functions (methods)
  void reset() { c = 0; }
  void increment() { c++; }
  void decrement() { c--; }
  int getValue() { return c; }
};

Then you can use the counter just with "counter myCounter;" in code, "myCounter.increment()" calls the increment routine etc...

In summation OO doesn't let you do anything new, it just gives you better language constructs for doing things that you are probably already doing in your procedural programs. Notice that in allowing n "counter" objects the compiler is performing some dynamic memory allocation for us and keeping it all hidden away beneath the OO syntax, which is nice, since it means you are less likely to end up with leaks or access violations in your compiled program than if you had to do that all manually...

OO is not so much about learning anything new (to start with), its more about learning how to write what you already know in a different, more recyclable way. The more advanced concepts like inheritance are just there to make this functionality even more flexible and should only be learned, in my opinion, after you have a fairly complete understanding of implementing basic classes.

Hope this helped.

 

[Dr Transport]

try this site...

http://www.mindview.net/

 

[verty]

For example, in a C++ program you may have some functions like this to provide some counters.

Actually, you could do it more elementarily without a static variable, like so:

typedef int counter;

//constructor
counter newCounter(int a) {return (counter)a;};
counter newCounter() {return newCounter(0);};

//selector
int getCounterValue(counter a) {return (int)a;};

//then (we don't need casts anymore)
counter incrementCounter(counter a) {
return newCounter(getCounterValue(a) + 1);
}
counter decrementCounter(counter a) {
return newCounter(getCounterValue(a) - 1);
}

//or if you like:
void incrementThisCounter(counter& a) {
a = newCounter(getCounterValue(a) + 1);
}
void decrementThisCounter(counter& a) {
a = newCounter(getCounterValue(a) - 1);
}
void resetThisCounter(counter& a) {
a = newCounter();
}

//then we have
int main() {
counter a = newCounter();
//some code
incrementThisCounter(a);
//some more code or whatever
printf("The counter value is %d.", getCounterValue(a));
}

This is very close to OOP code.

 

[nmtim]

Any advice? Would you be able to reccomend any good resources, whether online or books?

Thanks

It's a shift in the way you think. You need to DO it, not just read about it. Write more code, you'll get it.

Cheers,
Tim

 

[Jheriko]

Actually, you could do it more elementarily without a static variable, like so:

...

This is very close to OOP code.

This is an interesting implementation. If we were actually implementing it we might as well use int - I was just trying to illustrate the point that its easier to make a class for somethings, which is part of the motivation for OO. There are much better examples of course.

 

[verty]

I was just trying to illustrate the point that its easier to make a class for somethings, which is part of the motivation for OO. There are much better examples of course.

I meant to show that one can often do OO-like stuff in a procedural language.

Actually, there's a very good reason not to use an int. When you use 'counter' and treat it as a new type, you can see what a method takes because it is much more meaningful in methods like 'incrementThisCounter' to see that it takes a 'counter&' rather than 'int&'. It is somewhat self-documenting.

 

[ardjussi]

I have also read "Object Oriented Software Construction" by Bertrand Meyer but I don't feel like I really gained that much from it. More than anything it showed me that OOP can be taken to unhealthy extremes.

What do you think these extremes are? Is not C++ extreme or Java after all its evolution steps (generics...)?

br jussi

 

[edaffade]

learncpp.com is a very good web tutorial for beginners. Short and to the point. It is cpp though. OOP in general is very similar to procedural. It is a wrapper around the procedural to simplfy code reuse. To make the code easier to maintain and scalable. One additional benefit compared to C on C++ and java is stronger type checking in compile time (harder to make the code compile and harder to introduce bug into compiled code)

 

[AlephZero]

OO is really about software design not implementation. Of course it helps to use a programming language that makes it easy to implement an OO design, but I eventually found out I had been part of a team writing object oriented software in Fortran 77, years before anybody had even invented the buzzword "OO".

The main trouble with learning design is that small "toy" examples in tutorials can seem rather pointless. An example like verty's "counters" only makes sense if you have an application where counting things is a significant part of what the application is about. Otherwise, anybody in their right mind is going to declare "int count = 0" and increment it with "count++".

Even worse, when you start implementing a bad OO design, it's easy to "look busy" writing hundreds of lines of code that defines a bunch of classes with lots of constructors and lots of get/set methods, none of which really contributes to doing what the application is supposed to do. And somewhere buried inside that tangle of nothingness there is probably a small procedural program trying to escape...

Hard fact of life: using OO usually makes good programmers better, but it can make average to bad programmers a whole lot worse, IMO.

 

[TylerH]

I recommend you try implementing an OOP API in C. (For example, I made an OOP implementation of a linked list in C.) I never really understood the OOP features of other languages, namely C++ and Java, until I learned to use OOP in C.

An example of how you would do that (linked list object in C):

struct list_node
{
    void *data;
    struct list *next;
};

struct list
{
    size_t sizeof_data;
    struct list_node *root;
};

void list_init(struct list *l, size_t sizeof_data); // initialize init (initialize next and data to NULL)
void list_fini(struct list *l); // free list nodes and data
void *list_get(struct list *l, int index); // return void* to data
void list_set(struct list *l, int index, void *data); // if necessary, extend list, then allocate memory for data set l->data to data
void list_append(struct list *l, void *data); // append data to list 
// etc.

The reason struct->data is a void* is because (until C1X) C doesn't have a way of making general statements. C++ fixes that with templates. That's an example of what I learned from doing OOP in C (although, templates aren't really an advantage of OOP, rather an advantage of generic programming).