Page 1 of 3 123 LastLast
Results 1 to 10 of 25

Thread: Proceural Programming vs. Object Oriented Programming

  1. #1

    Question Proceural Programming vs. Object Oriented Programming

    Hey guys! I think we are being unfair to Jimmy Valavanis myself including.
    We acused him of using bad programing approach, of making ineficent code, of spending more time coding somethink that we belive it could be done faster in our way (OOP aproach) and we done all this without any relavent facts. We haven't seen any of his coding. What gives us right to judge him in the way we do?
    So why don't we alow him first to prove himself solving a real problem in practise and only then judge him.
    I will present problem below (the problem can be easily solved using OOP aproach) and I hope Jimmy would be so kind to take some of his time to show us how he would solve it. Maybe we will even learn something from him. Isn't that the purpose of our comunity - to learn.
    Now Jimmy if for some rason you don't want to publicly participate in this I still hope that you take some time and send me solution for the problem below using your approach. I would realy like to see how it can be done in procedural way becouse I cant imagine how myself. Maybe I will learn something.

    The problem is as folows:
    Lets say you are creating a strategy game. In this game there are several different unit types. Your goal is to write a code wich will define these unit types as specified below.
    For the sake of simplicity lets say that the gameworld is respresented with two dimensional array (tiles). These are defined like so:
    0 for unpasable terrain
    1 for land terrain
    2 water terrain
    3 for deep water terrain

    Unit types are like this:
    1. Land unit capable of atacking other land units
    2. Land unit capable of atacking air units
    3. Air unit capable of atacking other air units
    4. Air unit capable of atacking land units
    5. Air units capable of atacking submersible units
    6. Naval units capable of atacking other naval units
    7. Naval units capable of atacking submersible units
    8. Submersible units capable of atacking other submersible units
    9. Submersible units capable of atacking naval units
    10. Submersible units capable of atacking land units.

    Your code also need to make sure that these units can move properly (prevent ilegal moves)
    1. Land units can move only on land
    2. Naval units can move only on water
    3. Submersible units can only move in deep water when submerged
    4. Air units can move anywhere

    Naturally each units have his health so this should also be covered in your code.

    If you wish I will show you all how I would solve this problem myself using OOP aproach. I could also try to explain the benefits of using OOP in this case.

  2. #2
    Quote Originally Posted by WILL View Post
    Why not start another thread about Object Oriented Programming vs. Procedural Programming?
    I will wait Jimmy's response for now. Afterwards I will move all the posts relating to this matter to a new topic as you sad.

  3. #3
    Quote Originally Posted by SilverWarior View Post
    Lets say you are creating a strategy game.
    ...
    If you wish I will show you all how I would solve this problem myself using OOP aproach.
    I'm not sure exactly how the constraint you enumerated would favor an OOP approach on their own, as they're basically boolean truth tables.

    That said, such a game certainly favors a modular approach (to handle the various actions and movement cases), a database approach (to hold the zillions of parameters that would describe the characteristics of all the units in an easily editable fashion) and a scripting approach (for general AI and all scenario-specific behaviors about where/when things should move, what/how they should prioritize in their attack, etc.).

    On the other hand, I've known this kind of problems to be a good trap for "by the book" class hierarchies, as the best way to approach that problem with OO is IME not the one obvious to beginners. The common errors being not to differentiate actions from behaviors, and implementing those as methods of the entities rather than as distinct class hierarchies.

  4. #4
    Hey Eric you are free to present me with a third option for solution. I'll be glad to see it and study it. I bet I could learn something from it.

  5. #5
    Quote Originally Posted by WILL View Post
    Why not start another thread about Object Oriented Programming vs. Procedural Programming?
    I think there's no difference with "C Vs. Pascal" or "Windows Vs. Linux Vs. Mac" threads, a "religious war" that doesn't benefit nobody.
    No signature provided yet.

  6. #6
    Quote Originally Posted by Ñuño Martínez View Post
    I think there's no difference with "C Vs. Pascal" or "Windows Vs. Linux Vs. Mac" threads, a "religious war" that doesn't benefit nobody.
    Quite likely...

  7. #7
    Come guys, why you need to be that strict? As I see it, there's no sacred war here, the proposal is to learn from different aproachs on the same problem. Any of us can come with a brilliant solution to it, don't you think? Let's work on enlightment instead of senseless fight between us.

  8. #8
    The conversation becomes religious when people start to take things to the heart and personally. I think everyone should be aware that it's just a conversation between developers, to help each other with advice and share opinions; it is not an award/diploma/social_status/recognition contest.

    In certain occasions I've mentioned Unskilled and Unaware article, but it wasn't to say that someone's stupid, but because it's an interesting read and a useful study that says that we should be careful, especially in areas where we feel more confident in. It has numerous applications, not only in programming, but in life in general: in economy, politics, sports, car driving, gaming and even women!

    Procedural approach has its uses, especially in low-level frameworks, and I was not trying to prove that OOP is an answer to everything. However, while developing typical applications, starting from hello world and ending with large enterprise software, OOP is typically used. In fact, some languages would not allow you to work otherwise: C#, for instance, is very class-driven and working strictly procedural can be difficult.

    I've seen people, especially those who grew in Fortran age, to incline more into procedural ways and be wary of any modern programming techniques and tools. I myself have worked in procedural and even in assembler quite a lot, but I think you shouldn't fear to leave your comfort zone and try to learn something new. Who knows, you might even have some fun.

  9. #9
    Quote Originally Posted by Lifepower View Post
    I've seen people, especially those who grew in Fortran age, to incline more into procedural ways and be wary of any modern programming techniques and tools. I myself have worked in procedural and even in assembler quite a lot, but I think you shouldn't fear to leave your comfort zone and try to learn something new. Who knows, you might even have some fun.
    That for sure. Some months ago, I find myself explaining the benefits to use an rdms instead of flat tables, my customer grown up working with isam files in times of mainframes, cobol and punched cards. When I show him the virtues of visual development and sql language, he was in shock. Right now (6 months after) he still wonders about why he didn't have this nice tech on his time.

    Learning is a continual process. No matter if you are 80 years old, if you stop learning, you're dead and wasting our time. Sorry if it sounds rude, truth is rude, life shows no mercy for the weak.

    This non-sense is going weird.

  10. #10
    Quote Originally Posted by pitfiend View Post
    That for sure. Some months ago, I find myself explaining the benefits to use an rdms instead of flat tables
    Same level of shock happens IME when you're trying to explain "NoSQL" and "eventual consistency" to RDBMS users. ;-)

Page 1 of 3 123 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •