Dismiss Notice
Join Physics Forums Today!
The friendliest, high quality science and math community on the planet! Everyone who loves science is here!

Going from Procedural to OO

  1. Jan 13, 2007 #1

    I started off programming in high school with Turing. I continued with that untill 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?

  2. jcsd
  3. Jan 14, 2007 #2


    User Avatar
    Homework Helper

    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 SICP. It helped me to realise 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 Language Pragmatics" by Michael Scott. It isn't a book on OOP but it should serve as a bridge between languages.
  4. Jan 14, 2007 #3
    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 [Broken]

    see A trip to Objectville.
    Last edited by a moderator: May 2, 2017
  5. Jan 14, 2007 #4
    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.
    Code (Text):

    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)

    void counterDecrement(int 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:

    Code (Text):

    class counter
      int c;  // member variable
      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.
    Last edited: Jan 14, 2007
  6. Jan 14, 2007 #5

    Dr Transport

    User Avatar
    Science Advisor
    Gold Member

  7. Jan 14, 2007 #6


    User Avatar
    Homework Helper

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

    This is very close to OOP code.
    Last edited: Jan 14, 2007
  8. Jan 14, 2007 #7
    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.

  9. Jan 16, 2007 #8
    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.
  10. Jan 16, 2007 #9


    User Avatar
    Homework Helper

    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.
  11. Jan 29, 2012 #10
    What do you think these extremes are? Is not C++ extreme or Java after all its evolution steps (generics...)?

    br jussi
  12. Jan 29, 2012 #11
    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)
  13. Jan 29, 2012 #12


    User Avatar
    Science Advisor
    Homework Helper

    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.
  14. Jan 29, 2012 #13
    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):
    Code (Text):

    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).
Share this great discussion with others via Reddit, Google+, Twitter, or Facebook