EC Reading Notes series 10: clause 16, 17

Terms - make the interface easy to use correctly, not easy to misuse

Remember:

★ "Promote proper use" includes interface consistency and compatibility with built-in types of behavior

★ The "block misuse" approach includes establishing new types , restricting operations on types , constraining object values , and eliminating customer resource management responsibilities (i.e., class designers should preempt).

★TR1::SHARED_PTR supports custom-made filters. This can prevent DLL problems, which can be used to automatically unlock mutexes and so on.

--------------------------------------------------------------------------

C + + interfaces include: function interface, class interface, template interface ...

Interface ideal: If the customer attempts to use an interface and does not get the behavior he expected, should let this code not compile, if the code is compiled, it is what the customer wants.

A prevent the interface from being misused by importing new types:

1 classDate {2      Public:3Date (intMonthintDayintYear );4         ...5 };6 customers are prone to make mistakes:7Date D ( -,3,1995);//Error passing parameter order8Date D (2, -,1995);//Pass an invalid month or number of days

You can solve the problem by importing a simple type of outer overlay (that is, creating a new type):

structDay {ExplicitDay (intD): Val (d) {}//member initialization lists can also be used in structs .//up in the pose!!!    intVal;};structMonth {ExplicitMonth (intm): Val (m) {}intVal;};structYear {ExplicitYear (inty): Val (y) {}intVal;};D Ate class should read:classDate { Public: Date (ConstMonth &m,ConstDay &d,ConstYear &y); ...}; When used: Date D (Month (3), Day ( -), Year (1995) );

b prevent the interface from being misused by restricting object values:

If all valid months are defined in advance:classMonth { Public:        StaticMonth Jan () {returnMonth (1); }//return valid month        StaticMonth Feb () {returnMonth (2); }//Ibid .        ...    Private:        ExplicitMonth (intm);//prevent the generation of new month, this is the month exclusive data}; When used: Date D (Month::mar (), Day ( -), Year (1995) );

c prevent the interface from being misused by restricting the operation on the type:

For example: a common limitation is to add a const.

D eliminate the client's responsibility for resource management (i.e. the designer of the class should preempt):

For the following statement:

investment* createinvestment (); This function returns the dumb ptrs

The client can place its return value in a smart pointer, so the delete responsibility is pushed to the smart pointer, but in case the customer forgets it, it should be preemptive, making the above function return a smart pointer:

Std::tr1::shared_ptr<investment> createinvestment () {  // create a null shared_ PTR and getridofinvestment as the    std::tr1::shared_ptr<investment> retVal (static_cast<investment* > (0), getridofinvestment);         = ...;  // make retval point to the correct object    return RetVal;}

The good nature of shared_ptr is that it automatically uses its " every pointer-specific delete ", thus eliminating another potential customer error:cross-dll problem. This problem occurs when the object is created in the DLL, but is deleted in the other DLL. On many platforms, this type of "cross-DLL New/delete" results in run-time errors. shared_ptr no problem, ∵ its default is the delete from the DLL where Tr1::shared_ptr was born.

SHARED_PTR is larger than the original pointer, and uses auxiliary dynamic memory. These additional execution costs are not significant in many applications, but their "reduced customer error" results are significant (meaning cost-effective).

Terms + Design class like a design type

Remember:

The design of ★class is the design of type. Before you define a new type, make sure that you have considered all the discussion topics covered by this article

EC Reading Notes series 10: clause 16, 17