Printable View
I read somewhere that you should place all of your structures and datatypes in a file along with all of the functions that use those datatypes, and than include the files in the main source. Does this make any sense to you C experts? Maybe I read it wrong, however it came from a noteable author.
writting data types and classes plus function prototype in extra file ,which is known as HEADER FILE is normal thing in c++, as it helps re-using this classes in another programs and its easier to maintain , plus its basically was used for achiveing some goals of OOP(Object Oriented Programming ) expecially Encapsulation.
you should read more about this topic , which is essentially in c++ programming .
Good luck :), hoping i helped you :rolleyes:
No, this is not what I am talking about. I was referring to C and in specific C maintainence due to the fact that C is an action based rather than an object oriented language. Anyone else want to take a crack at this?
Having the function prototypes with the data types, mimics a C++ class.
>Does this make any sense to you C experts?
Yes, it does make sense, but I'm not saying it's right or wrong ;)
Simply put though, moemen is right, you need to read up on Header File usage.
If you have a specific C question, why not ask it in the C board, not on General Discussion..... ;)
Hammer, in what way do you find this usage productive?
I think that you guys are totally missing the point. I will explain in a while.
>Hammer, in what way do you find this usage productive?
Function prototypes and such go in header files so that they can be #include'd and used within other source files. Even a newbie C programmer uses a header file, even when they write their first hello world program.
Here, we used the printf() function which is declared in stdio.h. The only code that gets compiled is what you see here. Once it is compiled, it gets linked with the other standard modules to form an executable.Code:#include <stdio.h>
int main(void)
{
printf ("Hello, world\n");
return 0;
}
>I think that you guys are totally missing the point. I will explain in a while.
The sooner the better... in your first post would have been nice, too ;)
Mod - care to move this to Cprog board?
This has nothing to do with my question. I figured that you missed the point. Why should the moderators delete this perfectly good thread. It is not a specific programming question, that's why I didn't post it on the C board. It is a theoretical question.
I am well aware of how to create and use a header file. I'll explain in more detail in a couple hours.
This is just a small section of the article. It comes from the book, "Object Oriented Design Heuristics", by Arthur J. Riel
Quote:
When first exposed to the action-oriented solution to the preceding problem, many people state that they do not build action-oriented software in this way. They place each data structure of their system in a separate file in which they include any functions in the system relying on that data structure. It is true that this makes the system more maintainable, but what is the file they have created? It is the bidirectional relationship between data and behaviour, namely, a class, in object-oriented terminology. What the object-oriented paradigm does is to replace the convention of encapsulating data and behaviour using the file system with a design-language-level mechnanism. In short, it takes programming by convention carried out by the best porgrammers and replaces it with a lower-level mechanism. This allows the average programmer to take advantage of good design/implementation techniques without fully understanding the principles behind them. The main problems of programming by convention is that first a given developer has to understand it and second, he or she must stick with it. The latter constraint is the toughest to enforce.
We see that when the action-oriented programming goes right, it takes on the attributes of the object-oriented paradigm. This makes sense, since the object-oriented paradigm is really an evolutionary step from the action-oriented paradigm. Does that imply that the object-orented paradigm is the panacea that will eliminate the software crisis? If it isn't, where does the object-oreinted paradigm go wrong? There are two very distinct areas where the object-oriented paradigm can drive design in a dangerous direction. The first is a problem of poorly distributed system intelligence, while the second is the creation of too many classes for the size of the design problem. We refer to these pitfalls as the god class problem and the proliferation of classes problem. The god class problem manifests itself in two forms, the behavioral form and the data form. The proliferation of classes problem is produced by a number of factors. Wel will examine each of these problems in the following sections
Originally posted by TK
>Why should the moderators delete this perfectly good thread.
I didn't ask them to, I suggested they MOVE it (this thread just appears in the other forum, that's all).
>It is not a specific programming question, that's why I didn't post it on the C board.
Err... but you said:
but... now I've read your last post, I agree with you on this:Quote:
I was referring to C and in specific C maintainence due to ....
>It is a theoretical question.
However, I still don't understand what your question is. Can you expand please?
If you are asking do I agree with the author, I think my answer is yes, I do.
Well, putting it like this might help:
would you like having all the definitions of
(printf,scanf,strcpy,etc..) in your source code.;)
Another reason i think is to "hide" the implementation from
the interface.
iow - you just use the functions without caring how they work.
The functions that you create should be used the same way as
the standard C functions.
Here is the story without the diagrams.
Quote:
Topologies of action-oriented versus object-oriented applications.
Differences in application topologies.
It is very helpful to think of object-oriented software development as the next logical step in removing the details of the machine away from software developers. However, a learning curve is associated with this removal of details, due mostly to the different topology that the object-oriented paradigm enforces on the software development process. While action-oriented software development is involved with functional decomposition through a very centralized control mechanism, the object-orented paradigm focuses more on the decomposition of data with its corresponding functionality in a very decentralized setting. It is this decentralization of software that gives the object-oriented paradigm its ability to control essential complexity. It is also the cause for much of the learning curve. When the object-orented community talks about the need for designers to undergo a paradigm shift, it is this decentralization to which they refer.
In the following examples we will discuss the worst-case action-oriented topology contrasted with the best-case object-oriented topology. We will then examine what happens when the action-oriented paradigm goes right and when the object-oriented paradigm goes wrong.In any event, many developers believe that the average action-oreinted development leans toward the worst-case scenario while the average object-oriented development tends toward the best-case result (especailly in the presence of important design heuristics). Consider the symbolic functional decomposition displayed in Figure 3.1.
As the figure shows, an application has been broken down into five (three) functions. As an afterthought, underlying data structures are created as part of the implementation of these functions. The developers of these data structures have realized that some functions can share parts of their underlying data (e.g., f1() and f2() are sharing parto f the data structure). In the action-oriented world, it is easy to find data dependencies simply by examining the implementation of functions. Given the union of the formal parameter types, local variable types, and any accessed global variable types, the developer knows exactly the data on which code is dependent. However, we have a problem if we wish to know the functional dependencies on a piece of data in the system. In the action-oriented paradigm, there is not an explicit relationship between data and functionality. Consider a change to the data structure marked X in the figure.Code:
f1()
------------
- _
_ _____________ f2()
_______ X _
_ _____________ f3()
________ _
_ _
_____________
Note: This is not the whole diagram (I don't want to type it all)
Based on the diagram, we can state that only the functions f1() and f2() will require modification if the data marked X is modified. However, last weekend another developer creaded f6() without your knowledge (see figure that I don't want to draw). It is also dependent on the data marked X. You make all of your changes to the data X and the fucntions F1() and f2(). You compile, link, and run the resultant executable, and things do not work properly. You spend the next n days trying to find out what went wrong. Anyone who has developed any application of reasonable size has undoubtedly run into this problem. Most action-oriented systems have these undocumented data/behaviou dependencies due to their unidirectional relationship between code and data. Most action-oreinted systems have a spaghetti-like underlying data structure on which all developers hang their code.
How does object-oriented programming control this complexity? Consider an object-oriented solution to the above problem.
Many developers correctly claim that tbe action-oriented paradigm focuses only on the functionality of the system and typically ignores the data until it is required. They then claim that the object-oriented paradigm focuses exclusively on the data, ignoring the functionality of the system until it is required. This is not possible because the behavior of a system often drives the decomposition of data. It is preferable to think of the object-oriented paradigm as keeping data in the front of a developer's mind while keeping functionality in the back of his or her mind. The result of this process is the decomposition of our system into a collection of decentralized clumps of data with well-defined public interfaces. The only dependencies of functionality on data are that the operations of the well-defined public interfaces are dependent on their associated data (ie implimentation). In the figure the classes D1 and D2 use one another to carry out the functionality. The action-oriented picture is not always so bleak, nor the object-oriented picture so rosy. (next read previous post which contains the next paragraph). I wanted to know how many C programmers deal with the separation of data and behavior by using files to tie them together.Code:---------------- ----------------
- D1's data _ _ D2's data _
---------------- calls ----------------
_ f1() - <------- - f4() _
= f2() - __ _ f5() _
- f3() _ ---> - f6() -
---------------- ----------------