Valid tive C ++ clause 23: Native replaces the member function with non-Member and non-friend.

There is a class to indicate the web browser:

Class webbrowser
{
Public:
Void clearchache ();
Void clearhistory ();
Void removecookies ();
Protected:
PRIVATE:
};

Many users want to execute all these actions, so webbrowser also provides the function cleareverything.

Class webbrowser
{
Public:
Void clearchache ();
Void clearhistory ();
Void removecookies ();
Void cleareverything ();
Protected:
PRIVATE:
};

Of course, it can also be provided by a non-member function to call the appropriate member function:

Void clearbrowser (webbrowser WB)
{
WB. clearchache ();
WB. clearhistory ();
WB. removecookies ();
}

Which one is better?

Encapsulation considerations:

The more things are encapsulated, the more powerful we can change those things.

Data in the object. The less code you can see (access it), the more data you can encapsulate, the more freedom you can change the object data, such as changing the number and type of member variables. How can I measure how many codes can I see a piece of data? Compute the number of functions that can access it for rough measurement. The more functions access it, the lower the Data encapsulation.

The member variables should be private. Only Member and friend functions of the class can access the private member variables. If you want to use a member function (not only can access private data, but also can use private function, enums, typedefs, etc.) and a non-member function (unable to access anything above) the two provide the same function, which leads to a large encapsulation of the non-member non-friend function, because it does not increase the number of functions that can access the private component in the class.

This applies only to the non-member non-friend function. The access power of the friend function to the class private member is the same as that of the member function, so the two have the same impact on encapsulation.

The function "becomes a non-member of the class" because it cares about encapsulation does not mean that it "cannot be a member of another class ". Assume that clearbrowser can be another static member function of a tool class (utility class.

In C ++, it is natural to make clearbrowser a non-member function that is located in the same namespace (namespace) of webbrowser:

Namespace webbrowserstuff {
Class webbrowser {...};
Void clearbrowser (webbrowser WB );
...
}

A function like clearbrowser is a "convenient function ". A class like webbrowser may have a lot of convenience functions, some of which are related to bookmarks, some are related to printing, and some are related to Cookie management ..., Generally, most customers are only interested in some of them. There is no reason that a user interested in bookmarks is dependent on the compilation of a cookie-related convenience function. The most direct way to separate them is to put them into different header files:

// Header file webbrowser. h this file targets the class webbrowser itself and core functions of webbrowser.

Namespace webbrowserstuff {
Void clearbrowser (webbrowser WB );
... // Core function of webbrowser, which is required by almost all customers.
}

// Header file "webbrowserbookmarks. H"

Namespace webbrowserstuff {
Class webbrowser {...};
... // Convenient functions related to bookmarks
}

// Header file "webbrowsercookies. H"

Namespace webbrowserstuff {
Class webbrowser {...};
... // Convenience functions related to cookies
}

The C ++ standard library is organized in this way. Dozens of header files, each header file declares certain functions of STD. If you only want to use vector, do not use # include <memory>. If you do not want to use list, do not use # include <list>. this allows the customer to build dependencies only on the small part of the system they use. This cutting machine is not suitable for class member functions, because the class must be defined as a whole and cannot be split into segments. Namespace can span multiple source code files, but the class cannot.

Placing all convenience functions in a multi-head file but under the same namespace means that you can easily expand this group of convenience functions. All they need to do is add more non-member non-friend functions to this namespace. For example, if you want to write convenience functions related to image download, you only need to create a header file in the webbrowserstuff namespace that contains the declaration of those functions. New functions are available and integrated just like other old functions. This is another attribute that the class cannot provide, because the class definition cannot be extended for the customer.

Replace the non-member non-friend function with the member function. Packaging flexibility, packaging flexibility, and scalability can be added.