Effective C + + (NOTE): clause 18--clause 23

Article 18: Make the interface easy to use correctly, not easy to misuse

1. When the customer does not know how to use the (parameter) type, it is possible to import a simple "outer" type to differentiate the parameters. That is, custom data types that enable customers to explicitly invoke related types to prevent misuse.

2. Try to make the behavior of the custom type the same as the built-in type, because the customer would take it for granted and use the same custom type as the built-in type, which is what the above says makes the interface easy to use correctly. The STL interface of the containers is very consistent, which is one reason they are very easy to use.

3. Any interface that requires a customer to remember to do something is prone to "incorrect use," because the customer may forget to do that thing.

Ways to promote proper use include consistency of interfaces and compatibility of built-in types; the way to prevent misuse is to create new types, restrict operations on types, constrain object values, and eliminate customer resource management responsibilities .

Article 19: Design class like design type

• typeHow should new objects be created and destroyed?
• What is the difference between the initialization of an object and the assignment of an object?
• typewhat does a new object mean if it is passed as a value?
• What type is the legal value of the newly?
• Does your new type need fit into a succession diagram?
• typeWhat kind of conversion do you need for your new?
• What operators and functions are legal for this type ?
• What kind of standard function should be dismissed?
• Who should take the new type members?
• What type is the "Undeclared interface"?
• typeHow generalized is your new one?
• Do you really need a new one type ?

Clause 20: Prefer to replace pass-by-value with Pass-by-reference-to-const

pass-by-valueWhen constructing and destroying objects, it is an expensive (time-consuming) operation to call constructors and destructors multiple times.pass-by-reference-to-constMuch more efficient: No constructors or destructors are called because no new objects are created.referenceAbility to eliminate the creation and destruction of objects (parameters are base types, and if references are not used, they can cause cutting),constis to let the function not modify the value of the object.

If you peek at C++ the bottom of the compiler, you'll find that references are often implemented as pointers, so passing references often means that pointers are really passed. Objects are often more efficient if they belong to built-in types pass-by-value pass-by-reference .

Clause 21: When you must return an object, don't be paranoid about returning it reference

Whenever you see a reference declarative statement, you should immediately ask yourself, what is the other name of it? Because it must be another name for something.

There are two ways that a function creates a new object:heap(heap) andstack(Stack). If you define alocalObject, which is created in the stack space. When the function returns, the stack space will be freed, but the return is a reference to the destructor of the object, followed by a lot of questions. You're smart, you'll think of creating objects in the heap so that the function returns do not deconstruct the object, which is really possible, so there will be another problem: who should benewOut of the object implementationdelete? Even if the caller is honest and cautious, the memory leak cannot be prevented when the following conditions occur:

rational W, x, y, z;w = x*y*z;  

agreed to a statement called two times function (* ), two times using new , released two times before you can. But there is no proper way to get them to get the references returned by the function, nor to implement the release, which will definitely lead to resource leaks.

You may also be smart enough to define the object static so that you feel good about yourself, but the problem still comes. The results of the previous calculation are cumulative and affect the next calculation. This is obviously not what we want to happen.

The solution is also easy to imagine: a function that must return an object lets the function return the new object. This, of course, causes the cost of object construction and destruction, but in the long run it is only a small price to pay for the right behavior. Even if optimization is required, it is the compiler author's thing.

Article 22: Declaring a member variable as private

1. if the member variable is not public , the only way for a client to access a variable is to use a member function, that is, all access to the member variable is accessed through parentheses, and the requirements for interface consistency are met.
2. can use functions to give you more precise control over the handling of member variables. It is possible to control read-only or variable correctness.
3. Encapsulation. If you use a function to access member variables, you can later modify a calculation to replace this member variable, while class the customer does not know at all that the inside of the class has changed. -For example: we want to calculate the average speed of a car's multiple tests, return this value through a function, two implementations: Store the mean with a variable, and simply return the value when querying, and recalculate the mean value each time the function is called.

The first approach-benefit: Fast query speed, the disadvantage: a large amount of space to store the speed mean at any time; the second approach: The query is slow, but requires less memory space.

Which scheme is better? The answer is different for different situations. Therefore, the member variable is hidden behind the function interface and can provide flexibility for all possible implementations.

ProtectedMember variables are Public as lacking as encapsulation, because in both cases, if the member variable is changed, there will be an unpredictable amount of code being destroyed.

Clause 23: Ning to non-member non-frindReplace memberFunction

One view: the encapsulation of member functions is lower than the encapsulation of non-member functions .

The more things are encapsulated, the fewer people can see it, the less people can see it, the greater the elasticity we have to change it---the more things are encapsulated, the greater our ability to change those things. ---Encapsulation: enables us to change things and affect only limited customers.

Let's quantify this: using the number of functions that can access data as a rough quantization of encapsulation. The more functions can access it, the lower the encapsulation of the data, and vice versa.

Functions that have access to private data members are only member functions and friend functions, ifmemberFunctionnon-member non-friendFunctions andnon-memberChoose between functions,non-member non-friendfunction because it does not increase the number of "functions that can access private data." Yes, because it's more encapsulated, and that's what we want.

We call this function a "convenience function" because it is done by using a common member function to accomplish some group or combination of operations. Placing all "convenience functions" in multiple header files but belonging to the same namespace means that customers can easily extend this set of convenience functions. ---just like C++ the standard library does.

Effective C + + (NOTE): clause 18--clause 23