vart was wrong, by the way. A function and a module in C are very different things. Modules in C are typically source files.
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
It is discussable.Originally Posted by CornedBee
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.![]()
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
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.Originally Posted by wart101
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: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.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
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: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.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;
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"
I actually have no idea what modular programming is talking about:Originally Posted by vart
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
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 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.
i am patient, i said it before so i was just being funny, sorry you didn't get it.Originally Posted by relyt_123
WhAtHA hell Is GoInG ON
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.Originally Posted by Raigne
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
Thanks for taking the time to answer my question, you where very clear in your answers and i appreiciate it.Originally Posted by jEssYcAt
WhAtHA hell Is GoInG ON
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...