struct<\/code>s or class<\/code>es)<\/a><\/li>\n- C.2: Use
class<\/code> if the class has an invariant; use struct<\/code> if the data members can vary independently<\/a><\/li>\n- C.3: Represent the distinction between an interface and an implementation using a class<\/a><\/li>\n
- C.4: Make a function a member-only if it needs direct access to the representation of a class<\/a><\/li>\n
- C.5: Place helper functions in the same namespace as the class they support<\/a><\/li>\n
- C.7: Don\u2019t define a class or enum and declare a variable of its type in the same statement<\/a><\/li>\n
- C.8: Use
class<\/code> rather than struct<\/code> if any member is non-public<\/a><\/li>\n- C.9: Minimize exposure of members<\/a><\/li>\n<\/ul>\n
I will only write as much to the general class rules to make their intention clear.<\/p>\n
<\/span>General rules for classes<\/span><\/h2>\n![\"Observer\"](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2017\/08\/Observer.png\")
<\/p>\n
<\/span>C.1: Organize related data into structures (struct<\/code>s or class<\/code>es)<\/a><\/span><\/h3>\nIf data is related, you should put it into a struct or class; therefore, the second function is straightforward to comprehend.<\/p>\n
\nvoid<\/span> draw<\/span>(int<\/span> x, int<\/span> y, int<\/span> x2, int<\/span> y2); \/\/ BAD: unnecessary implicit relationships<\/span>\r\nvoid<\/span> draw<\/span>(Point from, Point to); \/\/ better<\/span>\r\n<\/pre>\n<\/div>\n <\/p>\n<\/p>\n
<\/span>C.2: Use class<\/code> if the class has an invariant; use struct<\/code> if the data members can vary independently<\/a><\/span><\/h3>\nAn invariant is a logical condition that a constructor typically establishes.<\/p>\n
\nstruct<\/span> Pair { \/\/ the members can vary independently<\/span>\r\n string name;\r\n int<\/span> volume;\r\n};\r\n\r\nclass<\/span> Date<\/span> {\r\npublic:<\/span>\r\n \/\/ validate that {yy, mm, dd} is a valid date and initialize<\/span>\r\n Date(int<\/span> yy, Month mm, char<\/span> dd);\r\n \/\/ ...<\/span>\r\nprivate:<\/span>\r\n int<\/span> y;\r\n Month m;\r\n char<\/span> d; \/\/ day<\/span>\r\n};\r\n<\/pre>\n<\/div>\n <\/p>\n
The class Date<\/span> has the invariants y<\/span>, m<\/span>, and d<\/span>. They are initialized and checked in the constructor. The data type Pair<\/span> has no invariant; therefore, it is a struct.<\/p>\nDue to the invariance, the class is easier to use. This is precisely the aim of the following rule.<\/p>\n
<\/span>C.3: Represent the distinction between an interface and an implementation using a class<\/a><\/span><\/h3>\nThe public methods are, in this case, the interface of a class, and the private part is the implementation.<\/p>\n
<\/p>\n
\nclass<\/span> Date<\/span> {\r\n \/\/ ... some representation ...<\/span>\r\npublic:<\/span>\r\n Date();\r\n \/\/ validate that {yy, mm, dd} is a valid date and initialize<\/span>\r\n Date(int<\/span> yy, Month mm, char<\/span> dd);\r\n\r\n int<\/span> day() const<\/span>;\r\n Month month() const<\/span>;\r\n \/\/ ...<\/span>\r\n};\r\n<\/pre>\n<\/div>\n <\/p>\n
From a maintainability perspective, the implementations of the class Date<\/span> can be changed without affecting the user.<\/p>\n<\/span>C.4: Make a function a member-only if it needs direct access to the representation of a class<\/a><\/span><\/h3>\nIf a function needs no access to the internals of the class, it should not be a member. Hence you get loose coupling, <\/a>and a change in the internals of the class will not affect the function.<\/p>\n<\/span>C.5: Place helper functions in the same namespace as the class they support<\/a><\/span><\/h3>\nSuch a helper function should be in the namespace of the class.<\/p>\n
\nnamespace<\/span> Chrono { \/\/ here we keep time-related services<\/span>\r\n<\/span><\/span><\/span>\r\n class<\/span> Date<\/span> { \/* ... *\/<\/span> };\r\n\r\n \/\/ helper functions:<\/span>\r\n bool<\/span> operator<\/span>==<\/span>(Date, Date);\r\n Date next_weekday<\/span>(Date);\r\n \/\/ ...<\/span>\r\n}
...
if (date1 == date2){ ... \/\/ (1)
\r\n<\/pre>\n<\/div>\n <\/p>\n
Thanks to argument-dependent lookup<\/a> (ADL), the comparison in (1) will additionally look for the identity operator in the Chrono<\/span> namespace.<\/p>\n<\/span>C.7: Don\u2019t define a class or enum and declare a variable of its type in the same statement<\/a><\/span><\/h3>\nI admit: defining a class and declaring a variable of its type in the same statement confuses me.<\/p>\n
<\/p>\n
\n\/\/ bad<\/span>\r\nstruct<\/span> Data { \/*...*\/<\/span> } data{ \/*...*\/<\/span> }; \r\n\r\n\/\/ good<\/span>\r\nstruct<\/span> Data { \/*...*\/<\/span> }; \r\nData data{ \/*...*\/<\/span> };\r\n<\/pre>\n<\/div>\n<\/span>C.8: Use class<\/code> rather than struct<\/code> if any member is non-public<\/a><\/span><\/h3>\nThis is quite a valid and often-used convention. If a data type has private or protected members, make it a class.<\/p>\n
<\/span>C.9: Minimize exposure of members<\/a><\/span><\/h3>\nThis rule, also called data hiding, is one of the cornerstones of object-oriented class design. It means that you should think about two interfaces for your class. A public interface for the general use case and a protected interface for derived classes. The remaining members should be private.<\/p>\n
I will continue with the more special rules. Here is an overview:<\/p>\n
\n- C.concrete: Concrete types<\/a><\/li>\n
- C.ctor: Constructors, assignments, and destructors<\/a><\/li>\n
- C.con: Containers and other resource handles<\/a><\/li>\n
- C.lambdas: Function objects and lambdas<\/a><\/li>\n
- C.hier: Class hierarchies (OOP)<\/a><\/li>\n
- C.over: Overloading and overloaded operators<\/a><\/li>\n
- C.union: Unions<\/a><\/li>\n<\/ul>\n
Let’s continue with the two rules to concrete types.<\/p>\n
<\/span>Concrete types<\/span><\/h2>\n\n- C.10: Prefer concrete types over class hierarchies<\/a><\/li>\n
- C.11: Make concrete types regular<\/a><\/li>\n<\/ul>\n
First of all, I have to write about concrete types and regular types.<\/p>\n
A concrete type<\/strong> is “the simplest kind of a class”. It is often called a value type and is not part of a type hierarchy. Of course, an abstract type can not be concrete.<\/p>\nA regular type<\/strong> is a type that “behaves like an int” and has, therefore, to support copy and assignment, equality, and order. To be more formal. A regular type Regular<\/span> supports the following operations.<\/p>\n\n- Copy and assignment\n
<\/ul>\n<\/li>\n<\/ul>\n\nRegular a;\r\nRegular a =<\/span> b;\r\n~<\/span>Regular(a);\r\na =<\/span> b;\r\n<\/pre>\n<\/div>\n\n- Equality<\/li>\n<\/ul>\n
<\/p>\n
\na ==<\/span> b;
a !=<\/span> b;<\/pre>\n<\/div>\n\n- Ordering<\/li>\n<\/ul>\n
<\/p>\n
\na <<\/span> b;<\/pre>\n<\/div>\n <\/p>\n
The built-in types are regular such as the container of the standard template library.<\/p>\n
<\/span>C.10: Prefer concrete types over class hierarchies<\/a><\/span><\/h3>\nUse a concrete type if you have no use case for a class hierarchy. A concrete type is way easier to implement, smaller, and faster. You do have not to think about inheritance, virtuality, references, or pointers, including memory allocation and deallocation. There will be no virtual dispatch and, therefore, no runtime overhead.<\/p>\n
You have value.<\/p>\n
<\/span>C.11: Make concrete types regular<\/a><\/span><\/h3>\nRegular types (ints) are easier to understand. They are, per see, intuitive. If you have a concrete type think about upgrading it to a regular type.<\/p>\n
<\/span>What’s next<\/span><\/h2>\n