Preface to "Object-Oriented Programming With ANSI-C"

ANSI-C object-oriented programming

       foreword

 


There is no one-size-fits-all programming technique

There is no programming language that produces only correct results

Not every project is programmed from scratch

 

 


Object-oriented programming is pretty much the cure-all today - even though it's been around for more than 10 years. As a core language, some technical experts have paid a lot of research on it, thus forming good programming rules, which we have been learning from for 20 years. C++ ( Eiffel , Oberon-2 , Smalltalk... take your pick) is a new programming language because it's object-oriented - although you don't need to use it or you don't want to (or don't know how), but you can use plain ANSI-C (standardized) as easily as you can use these object-oriented languages . In projects, only object-oriented languages ​​allow code reuse - although the idea of ​​some subroutines is as old as the development of computers, good programmers will always use toolboxes or libraries to use these subroutines.

       The intent of this book is not to praise object-oriented programming or to criticize old programming disciplines. We simply use ANSI-C to discover how object-oriented languages ​​are implemented, what the tricks are, why it can help us solve larger problems, and how we can use general methods and programming to catch errors earlier. Along the way, we'll come across some jargon classes, inheritance, instances, links, methods, objects, polymorphism, and so on but we'll strip off its magic to see how it translates to something we've all known and done all along.

       I'm happy to discover that ANSI-C (standardized) is a comprehensive object-oriented language. To be able to share in the fun, you'll need a decent level of fluency in ANSI-C before you start familiarity with structs, pointers, prototypes, and mastery of function pointers is a must. Throughout the text, you'll encounter all the new sayings in the words of Orwell and Webster : "Design is to narrow the breadth of thought" —and I'll try to show how it's possible to combine all these good ones that you've been wanting to use consistently, and, as a result, you're likely to become a proficient ANSI-C programmer.

       The first six chapters establish the foundations of ANSI-C object-oriented programming. We will start with a very precise information hiding abstract data structure, and then through the expansion of the structure, we will add functional properties based on dynamic linking and code inheritance. Finally putting them together into an inheritable class makes the code easier to maintain.

       Programming requires rules. Good procedures follow a lot of rules, lots of rules, standards, self-defensive ways to get things done right. Programmers must learn to use tools. Good programmers write tools to handle everyday programming routines. ANSI-C object-oriented programs require a certain amount of fixed code names change, data structures do not. So, in chapter 7 we build a small preprocessor to create a necessary boilerplate, it's more like another new object oriented language (maybe yanoodle) but it's not seen as such, OOC (object oriented programming ANSI-C ) was developed, and let's focus on using a new technique in the creative side of problem solving. OOC has strong plasticity. We designed it, understood it and changed it, and were able to write ANSI-C code as we wished .

       In the next chapters we will refine our technique. In Chapter 8, we added dynamic type checking to pre-catch exceptions. In Chapter 9 we programmed the automatic initialization mechanism to prevent other defect classes from arising. In Chapter 10, we introduced polymorphism and how to cooperate with each other to achieve the purpose of simplification. For example: routine affairs that generate standard main programs. Further chapters will be concerned with using the class's methods, storing, and loading structure data that follows the consistency policy. And by nesting the exception handler system to achieve consistent error recovery and self-healing.

       Finally, in the last chapter, we sidestepped the limitations of ANSI-C and implemented a mouse-operated calculator, first for the curses terminal and then for the X Window System ( check out that if you want to know what curses and the x window are) . This example clearly demonstrates the elegance of the design and examples we do with classes and objects, although we have to deal with the extrinsic nature of libraries and class hierarchies.

       There is an overview in front of each chapter. In this overview, I will give an outline to introduce the main content of the chapter and what to do next, which is very helpful for readers who skim this chapter. Most chapters suggest doing exercises; however, this is not meant to be formal, since we are building such techniques from scratch. I've avoided making and using huge class libraries, even though some examples seem to be advantageous to do so. If you want to better understand object-oriented programming, it is especially important to master this technology and consider code design; relying on other people's class libraries for development is a piece of cake later.

       An important part of this book is the accompanying code floppy disk - using the DOS file system, contains a single shell command to create the code in all chapters. There is a ReadMe file on the floppy disk - read it before you generate the code. Programming, like using a program like diff , it will be very beneficial for you to keep track of the evolution of base classes. OOC will be well reflected in the next chapters.

       The description of these technologies comes from my awareness of C++ , when I need to use object-oriented technology to implement an interactive programming language. And realize that in C++ you can't cast a portable instance. I turned to what I knew, ie ANSI-C , and I was able to do exactly what I had to. I have shared this technique with many people in my teaching process, including my workplace. And others have done their jobs just fine using these methods. This is where the book resides, because the footnotes to me seem particularly bleak. Brian Kernighan , my publisher, Hans-Joachim Niclas and John , etc., did not encourage me to publish these notes (had a chance, and will reorganize them in due course), I thank them and those who helped me to continue this book, and finally, my family - and, no, object-oriented mechanisms will not replace "sliced ​​bread".

Hollage, October 1993

Axel Tobias Schreiner

Guess you like

Origin blog.csdn.net/besidemyself/article/details/6376405