Thread: NOOB class question

vart was wrong, by the way. A function and a module in C are very different things. Modules in C are typically source files.

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.

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.

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.

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.

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.

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.

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.

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