Damage-oriented programming
Damage-oriented programming is a set of approaches that encourages code reuse and guarantees long-term use of code produced by programmers in combat systems. The number of lines of code is a universally applicable indicator of the significance of the application, and the number of lines that a programmer writes per working day is a useful metric used in project planning and resource allocation. Damage-oriented programming is one of the most effective ways to get the most voluminous source in the shortest possible time.
Inheritance is a way to get the capabilities of the old code in the new code. The programmer is inherited from an existing function or code block, copying this piece to itself and making edits. Inherited code, as a rule, is specified for new needs using features that the old code did not support. In this sense, the old code remains intact, but the new one is inherited from it.
Programs that use inheritance can be identified by a large number of almost identical code fragments that still contain small differences. Another sign of inheritance can be considered static fields - variables and blocks of code that are not directly used anywhere, but serve as a link between the new code and the old one.
An example of pseudo code inheritance:
')
The
Type polymorphism is one of the types of inheritance. In it, when inheriting code, the types of source variables are replaced.
The modular program is divided into several files that have a common header with comments. The module usually includes:
The size of the modules is usually kept within reasonable limits in order to reduce connectivity and improve power . If a module becomes too large, it can be divided into several parts, copying copyright, disclaimer, and so on into each. Comments can always be inherited without fear, so it is best to transfer all the original comments to the sprung module.
In flaw-oriented programming, plug-ins and components are commonly used — pieces of code found on the Internet or in books. Googling allows the savvy programmer to save a lot of time due to the fact that there are already components written in advance for almost anything. The best among them are black boxes : the programmer does not need to know or think about how the component works. Many large applications are written using inheritance from other applications and components found on the network.
The essence of encapsulation is to separate the data from the code. Sometimes this approach is also called data hiding , but the data is not really hidden - they are placed in an extra layer of code. For example, when in the code everywhere database queries are a bad practice. The damage-oriented approach is supposed to write wrappers for these functions, thereby encapsulating the database. In the
In some programming languages, fields can be tagged with
During the study of the lesion-oriented approach, the concept of polymorphism causes problems for many programmers. However, the idea is simple and very easy to implement. A polymorphic code is a code whose format or content of the output data varies depending on the input.
For example, the functions above can be rewritten into a single polymorphic function using inheritance and polymorphism:
Polymorphism is also associated with non-deterministic Turing finite automata , which you can remember from the informatics course.
This is the subtlety of a good flawless design. Novice programmers often abuse inheritance (the “is” model), while with the advent of experience it becomes clear that in many places the relation “contains” is more appropriate. In the example above, the information about each client contains a name, while custRec is a record in the database.
A virtual class or function is a code that will be needed in the program in the future, but has not yet been written. As a rule, this is implemented through the base class on which the final code will be based.
A fragile base class is a class or module that exists in a project for a long time, any changes in which break the entire application as a whole.
Overloading is an approach where a single module or block of code performs more than one task. For example, a function that returns the user name, his email and the state value added tax. Overloaded functions can save on dispatching methods , which is often the cause of slow working code written using other approaches.
Authorities claim that the code should be written so that it is easy to read. From here the conclusion follows that the documentation should be written in the least readable way. It should be maintained for each new module and updated as changes are introduced into the combat code — well, or at least when there is really nothing to do.
A great time to do documentation is when someone submits a letter of resignation. in two weeks that the employee is supposed to work, it would be nice to write documentation on all the code he developed.
Clogging the code with comments announcing the mechanisms of its work, distracts attention and slows down the compilation. Therefore, programmers who follow the “best practices” of flaw-oriented programming store the documentation in the workflow accounting system so that programmers cannot accidentally overwrite it.
This, of course, is not so much the practice of programming, but the followers of the deficiency-oriented approach use it. Keeping previous versions and change history at hand is important, even if only one person works on a project. Experienced flawless programmers adhere to the following rules:
You will probably notice that many enterprises follow some (or even all) practices of flaw-oriented programming. New-fashioned flows such as flexible or extreme methodologies come and go, but flaw-oriented programming has passed the test of time. Managers are always aware of a flaw-oriented approach and expect you to be able to work with projects written in this style.
From the translator: although the article was also in 2007, it did not lose relevance. Thanks to vovochkin for the link in the article " How to develop unsupported software ."
Damaged - flawed , defective. Harmful, insufficient.
Inheritance
Inheritance is a way to get the capabilities of the old code in the new code. The programmer is inherited from an existing function or code block, copying this piece to itself and making edits. Inherited code, as a rule, is specified for new needs using features that the old code did not support. In this sense, the old code remains intact, but the new one is inherited from it.
Programs that use inheritance can be identified by a large number of almost identical code fragments that still contain small differences. Another sign of inheritance can be considered static fields - variables and blocks of code that are not directly used anywhere, but serve as a link between the new code and the old one.
An example of pseudo code inheritance:
')
function getCustName(custID) { custRec = readFromDB("customer", custID); fullname = custRec[1] + ' ' + custRec[2]; return fullname; } function getCustEmail(custID) { custRec = readFromDB("customer", custID); fullname = custRec[1] + ' ' + custRec[2]; /*************** * 4/15/96 git : email * ***************/ return custRec[17]; } The
getCustEmail function was inherited from the getCustName function when support for email addresses appeared in the application. Inheriting the code in this way avoids the accidental introduction of new bugs into the program.
Type polymorphism is one of the types of inheritance. In it, when inheriting code, the types of source variables are replaced.
Modularity
The modular program is divided into several files that have a common header with comments. The module usually includes:
- Copyright
- Denial of responsibility
- From three to five lines with asterisks
- Change history
- Description of what the module was originally supposed to do
- Three more - five lines with asterisks
- A large block with spaces and blank lines, surrounded by asterisks or other characters, which lists the names of all functions, the name or initials of the author, as well as the date of writing
- Code
The size of the modules is usually kept within reasonable limits in order to reduce connectivity and improve power . If a module becomes too large, it can be divided into several parts, copying copyright, disclaimer, and so on into each. Comments can always be inherited without fear, so it is best to transfer all the original comments to the sprung module.
Components and Libraries
In flaw-oriented programming, plug-ins and components are commonly used — pieces of code found on the Internet or in books. Googling allows the savvy programmer to save a lot of time due to the fact that there are already components written in advance for almost anything. The best among them are black boxes : the programmer does not need to know or think about how the component works. Many large applications are written using inheritance from other applications and components found on the network.
Encapsulation
The essence of encapsulation is to separate the data from the code. Sometimes this approach is also called data hiding , but the data is not really hidden - they are placed in an extra layer of code. For example, when in the code everywhere database queries are a bad practice. The damage-oriented approach is supposed to write wrappers for these functions, thereby encapsulating the database. In the
getCustName method presented above, the database is accessed not directly, but through such a special wrapper that reads one record. Both of these methods (as well as many similar ones) “know” where they have the data they need in the customer record. The way to read a record from the database is In some programming languages, fields can be tagged with
private , public or protected modifiers. This has nothing to do with a flaw-oriented approach. The author of the module can not know what internal variables from its module will be required to implement the required functionality in the future! Therefore, all fields should be made public, and variables - global, and let the external code itself decide what to touch and what not.
Polymorphism
During the study of the lesion-oriented approach, the concept of polymorphism causes problems for many programmers. However, the idea is simple and very easy to implement. A polymorphic code is a code whose format or content of the output data varies depending on the input.
For example, the functions above can be rewritten into a single polymorphic function using inheritance and polymorphism:
function getCustData(custId, what) { if (what == 'name') { custRec = readFromDB("customer", custId); fullname = custRec[1] + ' ' + custRec[2]; return fullname; } else if (what == 'email') { custRec = readFromDB("customer", custId); fullname = custRec[1] + ' ' + custRec[2]; /*************** * 4/15/96 git : email * ***************/ return custRec[17]; } /* ... . */ }
Polymorphism is also associated with non-deterministic Turing finite automata , which you can remember from the informatics course.
" Is " against " contains "
This is the subtlety of a good flawless design. Novice programmers often abuse inheritance (the “is” model), while with the advent of experience it becomes clear that in many places the relation “contains” is more appropriate. In the example above, the information about each client contains a name, while custRec is a record in the database.
Virtual Classes and Functions
A virtual class or function is a code that will be needed in the program in the future, but has not yet been written. As a rule, this is implemented through the base class on which the final code will be based.
function calcSalesTax(price, isTaxable, state) { /**************************************** * * TO DO: * * * - , * * ****************************************/ /** 02/07/99 git -- **/ return price * (7.25 / 100.0); }
A fragile base class is a class or module that exists in a project for a long time, any changes in which break the entire application as a whole.
Overload
Overloading is an approach where a single module or block of code performs more than one task. For example, a function that returns the user name, his email and the state value added tax. Overloaded functions can save on dispatching methods , which is often the cause of slow working code written using other approaches.
Documentation
Authorities claim that the code should be written so that it is easy to read. From here the conclusion follows that the documentation should be written in the least readable way. It should be maintained for each new module and updated as changes are introduced into the combat code — well, or at least when there is really nothing to do.
A great time to do documentation is when someone submits a letter of resignation. in two weeks that the employee is supposed to work, it would be nice to write documentation on all the code he developed.
Clogging the code with comments announcing the mechanisms of its work, distracts attention and slows down the compilation. Therefore, programmers who follow the “best practices” of flaw-oriented programming store the documentation in the workflow accounting system so that programmers cannot accidentally overwrite it.
Version control
This, of course, is not so much the practice of programming, but the followers of the deficiency-oriented approach use it. Keeping previous versions and change history at hand is important, even if only one person works on a project. Experienced flawless programmers adhere to the following rules:
- Always add your initials and last modified date to the file header.
- If you touch the file and you realize that the changes will be difficult to roll back, save a copy with the
.bakextension. - Keep several copies of the code by appending your initials and date of change to the file name. For example:
custdata_git20040321.bak. - Always keep backups in the same folder as the original files so that the change history is easier and more convenient to track.
Conclusion
You will probably notice that many enterprises follow some (or even all) practices of flaw-oriented programming. New-fashioned flows such as flexible or extreme methodologies come and go, but flaw-oriented programming has passed the test of time. Managers are always aware of a flaw-oriented approach and expect you to be able to work with projects written in this style.
From the translator: although the article was also in 2007, it did not lose relevance. Thanks to vovochkin for the link in the article " How to develop unsupported software ."
Source: https://habr.com/ru/post/203646/
All Articles