NOOB class question

This is a discussion on NOOB class question within the C++ Programming forums, part of the General Programming Boards category; vart was wrong, by the way. A function and a module in C are very different things. Modules in C ...

  1. #31
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    vart was wrong, by the way. A function and a module in C are very different things. Modules in C are typically source files.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  2. #32
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,484
    Quote Originally Posted by CornedBee
    vart was wrong, by the way. A function and a module in C are very different things. Modules in C are typically source files.
    It is discussable.

    Files in C are called modules.
    But modular programming is not talking about splitting your code between several source files...

    So functions ARE representing the idea of modules used by the modular programming paradigm.

    As structures in C have nothing to do with the structural programming paradigm.
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  3. #33
    verbose cat
    Join Date
    Jun 2003
    Posts
    209
    Quote Originally Posted by wart101
    and i asked the question, is one idea to use modularity in your classes?

    perhaps my question should have been more defined,

    IN MY QUEST TO UNDERSTAND OOP SHOULD I BE USING MODULES IN MY CLASSES?
    Yes. Modularity is a fundamental part of programming. Breaking something down into smaller somethings is modularizing. In programming, you break a problem down into parts and then write functions, procedures, methods, or whatever the language calls them to handle those parts.

    The term "modules" is also used to mean source files, but I don't think that's what you're specifically asking here.

    In procedural programming, you focus on the steps you need to take in order to accomplish some task and pass your data around from function to function to accomplish the task. You break the steps down into smaller steps (functions in C/C++) in order to more easily accomplish the overall task of the program. This is modularizing. It helps reduce how much code you have to use (instead of copying/pasting the same code over and over, you put it into a function, make it work right and re-use it) as well as making it easier to understand the code. Think of how difficult it would be to read a simple section of a program that asks the user for his name, inputs the name and then displays the name if you had to put all the underlying code from cin and cout instead of just calling them with cout << "Hi, " << name << endl;.

    Here is an example of a procedural program in psuedocode:
    Code:
    start
        initialize all the variables
        show the main menu
        ask for a menu choice
        while the user hasn't picked the "quit" option
        {
            if the user picked option one, call the option one function
            if the user picked option two, call the option two function
            ...
            if the user picked an invalid option, show an error message to that effect
            show the main menu
            ask for a menu choice
        }
    end
    Suppose this is a simple record keeping program and option 1 is to enter a new record, option 2 is to search for a specific record and so forth. You could represent the records as structs, and the program would be written such that all of the functions revolve around manipulating those structs; adding new ones, deleting existing structs from the list, displaying existing structs in the list, reading structs from the disk, writing structs to the disk, etc.

    Object Oriented programming is a completely different way of thinking. At the highest level, instead of focusing on the steps you take to manipulate data as in procedural design, in object oriented programming you focus on what you are working with and then define how those things do their job. The objects you create model the things you are working with.

    For example, you could create a card class to represent playing cards (that you can play poker, solitaire, blackjack, euchre, etc. with) and then a deck class to represent a deck of cards. You then define how those things interact. You could make the card objects able to compare themselves to each other, and then make the deck class able to shuffle and sort the cards and keep track of which cards have been dealt from the deck. Now, instead of having a bunch of functions to keep track of and worrying about calling the right ones in the right order, you would have something like the following:
    Code:
      Deck d;       // just like creating an int or a float, except the Deck class constructor
                    // automatically creates 52 Card objects
      Card mycard;  // again, like creating an int or a float, except this makes a Card class object
      Card anothercard;
      d.shuffle();  // telling your deck object to shuffle the cards
      mycard = d.deal(); // telling your deck object to deal the top card and storing the value
                         // of that card in the mycard variable
      anothercard = d.deal();
      if (mycard > anothercard)
          cout << "My card was bigger." << endl;
      else
          cout << "My card was not bigger." << endl;
    As you can see, instead of thinking about the program in terms of some data and a bunch of functions to manipulate that data, here we see the program in terms of the things we are trying to model. It is easy to understand what d.shuffle() means (assuming we gave the function an appropriate name), and it is obvious that we are comparing the value of one card to the value of the other card. What that card comparison is based on (rank of the card, suit, a combination of the two, or something else) is up to the designer of the Card class. You don't have to worry about how the deck will shuffle the cards (unless you are writing the .shuffle() function), instead you conceptually tell the deck to be shuffled.

    Modularization here is more about the classes than the functions. Presumably when you have finished a class and are confident that it is working correctly, you can drop it in and tell it to do things in a more natural way, and visualize the object doing those things in your program. As you build the classes in a program, the relationships between the things you are modeling should make the program easier to understand, maintain and build upon. The string class is a good example. You don't worry about how the string is implemented and you can be pretty sure it's going to work as you expect. When you add 2 strings together with the + operator, you expect them to be added together like writing the 2nd string right after the first.

    There is more (MUCH more) to object oriented programming, but classes are a fundamental concept for OOP. You can extend classes to an absurd level and have a Card class, a Deck class, a PokerDealer class that handles the deck, a Table class and a Player class to have a bunch of players sit down and play a game of poker at a table, a Casino class that employs the PokerDealer and perhaps handles other PokerDealers as well as SlotMachine's and RouletteWheel's and so forth, a City class that contans several Casino objects, and so on.

    However, no matter how far you take classes or how deeply you dive into OOP, at the core of all programming is procedural programming. When you get down to it, the shuffle() function has to follow certains steps (a procedure) to accomplish its goal, and even within a class you'll find modularization in the form of writing private class functions to take care of things, as well as using other library functions, other classes and so on the same as if you were writing the main() function.

    C++ is a tool however that allows you to write in whatever style you want, and even mix styles. You can write a completely procedural program, a completely object oriented program, you can use classes as more complex datatypes that know how to interact with the basic datatypes, you can write programs around a few objets, etc.

    Also, not every situation calls for one or the other type of design. Sometimes object oriented programming is ideal to solve a problem, sometimes object oriented programming would make the design of a program more complex than a simple procedural design. Knowing both is good since you then have more than one tool in your toolbox.
    abachler: "A great programmer never stops optimizing a piece of code until it consists of nothing but preprocessor directives and comments "

  4. #34
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by vart
    Files in C are called modules.
    But modular programming is not talking about splitting your code between several source files...
    I actually have no idea what modular programming is talking about:
    http://en.wikipedia.org/wiki/Modular_programming
    But judging from the length of the article, it can't be very important today.

    Modular programming, the way I used to understand the term, is just a general term for all paradigms that try to achieve modularity. That includes object-oriented programming, but also procedural structured programming, which is what I think you're talking about.

    Although functions are one way to achieve modularity, calling them modules is still extremely misleading, since the term is already taken in C and rarely, if ever, used for anything smaller than a group of related functions, even outside C. In software design, a module is a building block of the application, e.g. the network module, the UI module, etc.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  5. #35
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,581
    The article is very thin.

    Vart is correct though, from all I know. The problem is that the concept of modularity evolved considerably to the point of having fall into disuse. It was also considerably confusing since it meant different things to different people (and different marketing strategists).

    Programming languages like BASIC, dBase, Clipper and FlagShip, and others predating these (talking only about the ones I ever had my hands on) were highly modular with little to none functionality regarding procedural programming. Each module (physical file) had to be independent and capable of being separately executed without the need of others. This was one notion of module and I remember it being debated like so back then.

    Structured programming and procedural programming extended the notion of modularity with their units of code, functions and procedures. Languages like C and Pascal. However, the need for independent execution was dropped. And the notion of modularity was being debated in terms of blocks of code that could be seen as a part of the whole. In order to understand the program, we would have to understand its individual structures (aka modules).

    Under a strict structural programming paradigm, a module is a function or routine. Whereas under procedural programming, a module can be seen as either a unit of code, or a function or routine (the scale of a module in a procedural programming paradigm is dictated by its usage. And the same program can present various scales).

    This is what I think I know of the word modules. The whole notion of modules as a programming paradigm has fall into disuse, now that almost every language is modular. But there were a time when the discussion was more pertinent.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  6. #36
    Registered User
    Join Date
    Sep 2005
    Posts
    142
    Quote Originally Posted by relyt_123
    How about being patient? You only waited half an hour.
    i am patient, i said it before so i was just being funny, sorry you didn't get it.
    WhAtHA hell Is GoInG ON

  7. #37
    Registered User
    Join Date
    Sep 2005
    Posts
    142
    Quote Originally Posted by Raigne
    Yea patience is a thing of requirement on boards. One, people here have to work, two they mightnot be on their comps, or maybe even three they are not in the mood for answering questions. Just be patient your answers will come. As for me I have been programming for almost 2 years. Also, in most situations ( as I have found ) use OOP if and only if it is needed or necessary. Something like a basic media player, or a text based game generally wont need it. Yet if you are going to be making a large scale full blown media player ( similar to WMP ) then yea it is necessary for easy maintenance. Changing one function or variable, or adding those is much easier in a class because you dont have to hunt through 1000's of lines of code. you just change it in your class, and Tada it changed. That may seem a little unclear but think about it for a second, and it should become clear. Although I am one of the more inexperienced people on the boards so may not be smart to take my advice without asking a pro first.
    I am patient, as i said before i was just trying to be funny but abviously i was not, i have been programming for about 1 and a half years now so i'm not completly oblivious to the OOP concepts but am looking for more clarifacation.

    i understand %100 of what your are saying except from what i am being told, you can have classes and it doesn't mean you are doing OOP, it's how you use classes that defines OOP
    classes will give you a basis for OOP but it goes a bit deaper than just having classes in you programme.
    WhAtHA hell Is GoInG ON

  8. #38
    Registered User
    Join Date
    Sep 2005
    Posts
    142
    Quote Originally Posted by jEssYcAt
    Yes. Modularity is a fundamental part of programming. Breaking something down into smaller somethings is modularizing. In programming, you break a problem down into parts and then write functions, procedures, methods, or whatever the language calls them to handle those parts.

    The term "modules" is also used to mean source files, but I don't think that's what you're specifically asking here.

    In procedural programming, you focus on the steps you need to take in order to accomplish some task and pass your data around from function to function to accomplish the task. You break the steps down into smaller steps (functions in C/C++) in order to more easily accomplish the overall task of the program. This is modularizing. It helps reduce how much code you have to use (instead of copying/pasting the same code over and over, you put it into a function, make it work right and re-use it) as well as making it easier to understand the code. Think of how difficult it would be to read a simple section of a program that asks the user for his name, inputs the name and then displays the name if you had to put all the underlying code from cin and cout instead of just calling them with cout << "Hi, " << name << endl;.

    Here is an example of a procedural program in psuedocode:
    Code:
    start
        initialize all the variables
        show the main menu
        ask for a menu choice
        while the user hasn't picked the "quit" option
        {
            if the user picked option one, call the option one function
            if the user picked option two, call the option two function
            ...
            if the user picked an invalid option, show an error message to that effect
            show the main menu
            ask for a menu choice
        }
    end
    Suppose this is a simple record keeping program and option 1 is to enter a new record, option 2 is to search for a specific record and so forth. You could represent the records as structs, and the program would be written such that all of the functions revolve around manipulating those structs; adding new ones, deleting existing structs from the list, displaying existing structs in the list, reading structs from the disk, writing structs to the disk, etc.

    Object Oriented programming is a completely different way of thinking. At the highest level, instead of focusing on the steps you take to manipulate data as in procedural design, in object oriented programming you focus on what you are working with and then define how those things do their job. The objects you create model the things you are working with.

    For example, you could create a card class to represent playing cards (that you can play poker, solitaire, blackjack, euchre, etc. with) and then a deck class to represent a deck of cards. You then define how those things interact. You could make the card objects able to compare themselves to each other, and then make the deck class able to shuffle and sort the cards and keep track of which cards have been dealt from the deck. Now, instead of having a bunch of functions to keep track of and worrying about calling the right ones in the right order, you would have something like the following:
    Code:
      Deck d;       // just like creating an int or a float, except the Deck class constructor
                    // automatically creates 52 Card objects
      Card mycard;  // again, like creating an int or a float, except this makes a Card class object
      Card anothercard;
      d.shuffle();  // telling your deck object to shuffle the cards
      mycard = d.deal(); // telling your deck object to deal the top card and storing the value
                         // of that card in the mycard variable
      anothercard = d.deal();
      if (mycard > anothercard)
          cout << "My card was bigger." << endl;
      else
          cout << "My card was not bigger." << endl;
    As you can see, instead of thinking about the program in terms of some data and a bunch of functions to manipulate that data, here we see the program in terms of the things we are trying to model. It is easy to understand what d.shuffle() means (assuming we gave the function an appropriate name), and it is obvious that we are comparing the value of one card to the value of the other card. What that card comparison is based on (rank of the card, suit, a combination of the two, or something else) is up to the designer of the Card class. You don't have to worry about how the deck will shuffle the cards (unless you are writing the .shuffle() function), instead you conceptually tell the deck to be shuffled.

    Modularization here is more about the classes than the functions. Presumably when you have finished a class and are confident that it is working correctly, you can drop it in and tell it to do things in a more natural way, and visualize the object doing those things in your program. As you build the classes in a program, the relationships between the things you are modeling should make the program easier to understand, maintain and build upon. The string class is a good example. You don't worry about how the string is implemented and you can be pretty sure it's going to work as you expect. When you add 2 strings together with the + operator, you expect them to be added together like writing the 2nd string right after the first.

    There is more (MUCH more) to object oriented programming, but classes are a fundamental concept for OOP. You can extend classes to an absurd level and have a Card class, a Deck class, a PokerDealer class that handles the deck, a Table class and a Player class to have a bunch of players sit down and play a game of poker at a table, a Casino class that employs the PokerDealer and perhaps handles other PokerDealers as well as SlotMachine's and RouletteWheel's and so forth, a City class that contans several Casino objects, and so on.

    However, no matter how far you take classes or how deeply you dive into OOP, at the core of all programming is procedural programming. When you get down to it, the shuffle() function has to follow certains steps (a procedure) to accomplish its goal, and even within a class you'll find modularization in the form of writing private class functions to take care of things, as well as using other library functions, other classes and so on the same as if you were writing the main() function.

    C++ is a tool however that allows you to write in whatever style you want, and even mix styles. You can write a completely procedural program, a completely object oriented program, you can use classes as more complex datatypes that know how to interact with the basic datatypes, you can write programs around a few objets, etc.

    Also, not every situation calls for one or the other type of design. Sometimes object oriented programming is ideal to solve a problem, sometimes object oriented programming would make the design of a program more complex than a simple procedural design. Knowing both is good since you then have more than one tool in your toolbox.
    Thanks for taking the time to answer my question, you where very clear in your answers and i appreiciate it.
    WhAtHA hell Is GoInG ON

  9. #39
    Marxist-Trotskyist
    Join Date
    May 2005
    Location
    Many, many miles from the center of the Earth.
    Posts
    31
    It seems like the definition of modular programming is and issue of semantics. Honestly, all I can say is that breaking your code into smaller, psuedo-independent chunks is definitly necessary for a program of any considerable function. When I first started programming (I was 11, keep in mind, and had no clue what I was doing), I was programming in BASIC, and I attempt to put every piece of code (for a top-down shooter) into the main loop directly. I didn't have any concept of functions and didn't comment my code. It was, needless to say, totally dysfunctional spagetti code.

    I made couple little games with BASIC, and, when I code, I try to take each aspect of the game (general aspect; i.e. initial setup, graphics loading, graphics display, user inpute, et cetera), and design a function that can be called from the loop with a few arguments. I break each one of those down into several (sometimes quite a few) smaller functions that handle more detailed functions. For instance, initial setup would call several functions; preferences loading, GUI initialization, API initialization (if you're using one), and so forth. I don't know if this architecture works with larger programs, and I've only recently starting using OOP (as far as classes or structures go), and I usually implement them on top of this structure (to contain the variables that the functions interact with). In any case, I wouldn't really call the individual, specialized functions modules in and of themselves, since they're usually highly independent, functionally; the primary functions, the ones that the main loop calls, are more along the lines I think when I consider the idea of modularity... //2_cents
    If a=b, and b=c, then a=c, except where void and prohibited by law...

Page 3 of 3 FirstFirst 123
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Screwy Linker Error - VC2005
    By Tonto in forum C++ Programming
    Replies: 5
    Last Post: 06-19-2007, 03:39 PM
  2. Dikumud
    By maxorator in forum C++ Programming
    Replies: 1
    Last Post: 10-01-2005, 07:39 AM
  3. My Window Class
    By Epo in forum Game Programming
    Replies: 2
    Last Post: 07-10-2005, 03:33 PM
  4. question about DLL's and class functions
    By btq in forum Windows Programming
    Replies: 2
    Last Post: 02-25-2003, 06:08 AM
  5. gcc problem
    By bjdea1 in forum Linux Programming
    Replies: 13
    Last Post: 04-29-2002, 07:51 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21