C ++ 클래스의 멤버는 어떻게 주문해야합니까?

C ++ 클래스의 멤버는 어떻게 주문해야합니까?

---

모든 개인 구성원, 보호 대상 구성원, 모든 공개 구성원을 갖는 것이 더 낫습니까? 아니면 그 반대? 아니면 여러 개인, 보호 및 공용 레이블이 있어야 작업이 생성자와 별도로 유지 될 수 있습니까? 이 결정을 내릴 때 어떤 문제를 고려해야합니까?

---

퍼블릭 인터페이스를 먼저 두었지만 항상 그렇게하지 않았습니다. 나는 이것에 대해 사적, 보호, 공개로 거꾸로 일했습니다. 돌이켜 보면 말이 안됐다.

클래스 개발자는 "내부"에 대해 잘 알고있을 수 있지만 클래스 사용자는별로 신경 쓰지 않거나 적어도해서는 안됩니다. 그들은 주로 수업이 그들을 위해 무엇을 할 수 있는지에 관심이 있습니다.

그래서 저는 대중을 우선시하고 일반적으로 기능 / 유틸리티별로 구성합니다. 나는 그들이 X와 관련된 모든 방법을 찾기 위해 내 인터페이스를 훑어 볼 필요가없고, 조직적인 방식으로 모든 것을 함께 볼 수 있기를 바랍니다.

나는 여러 공개 / 보호 / 비공개 섹션을 사용하지 않습니다. 내 의견으로는 따르기에는 너무 혼란 스럽습니다.

---

Google은 다음 순서를 선호 합니다 . "Typedef 및 열거 형, 상수, 생성자, 소멸자, 정적 메서드를 포함한 메서드, 정적 데이터 멤버를 포함한 데이터 멤버"

Matthew Wilson (Safari 구독 필요)은 다음 순서를 권장합니다. "구성, 작업, 속성, 반복, 상태, 구현, 구성원 및 내가 가장 좋아하는, 구현되지 않음".

그들은 좋은 이유를 제공하고 이러한 종류의 접근 방식은 상당히 표준적인 것처럼 보이지만 무엇을하든 일관성을 유지하십시오.

---

그것은 제 의견이며, 대부분의 사람들이 공적인 방법이 우선되어야한다는 데 동의 할 것이라고 추측합니다. OO의 핵심 원칙 중 하나는 구현에 신경 쓸 필요가 없다는 것입니다. 퍼블릭 메소드를 살펴보면 클래스를 사용하기 위해 알아야 할 모든 것을 알 수 있습니다.

---

항상 그렇듯이 먼저 인간을 위한 코드를 작성하십시오 . 클래스를 사용하게 될 사람을 고려하고 배치 가장 중요한 구성원 / 열거 형 / 구조체에는 / 무엇이든 그들에게 상단에.

일반적으로 이는 클래스의 대부분의 소비자가 가장 관심을 갖는 항목이므로 공개 멤버가 최상위에 있음을 의미합니다. 보호됨이 다음으로 개인 항목이옵니다. 보통.

몇 가지 예외가 있습니다.

때때로 초기화 순서가 중요하며 때로는 개인이 공개 전에 선언되어야합니다. 때로는 클래스를 상속하고 확장하는 것이 더 중요합니다.이 경우 보호 된 멤버가 더 높은 위치에 배치 될 수 있습니다. 그리고 레거시 코드에 단위 테스트를 해킹 할 때 공개 메서드를 노출하는 것이 더 쉬울 때가 있습니다.이 근사한 죄를 범해야하는 경우 클래스 정의의 맨 아래에 배치합니다.

그러나 그들은 비교적 드문 상황입니다.

대부분의 경우 "공개, 보호, 개인"이 동급 소비자에게 가장 유용합니다. 지켜야 할 괜찮은 기본 규칙입니다.

그러나 액세스에 의한 주문보다는 소비자의 관심에 따라 주문하는 것이 더 중요합니다 .

---

나는 일반적으로 먼저 인터페이스 (읽기)를 정의합니다. 즉, 공개, 보호, 비공개 항목 순입니다. 이제 많은 경우에 한 단계 더 나아가서 PIMPL 패턴을 사용하여 실제 클래스의 인터페이스에서 모든 개인 정보를 완전히 숨 깁니다.

class Example1 {
public:
   void publicOperation();
private:
   void privateOperation1_();
   void privateOperation2_();

   Type1 data1_;
   Type2 data2_;
};
// example 2 header:
class Example2 {
   class Impl;
public:
   void publicOperation();
private:
   std::auto_ptr<Example2Impl> impl_;
};
// example2 cpp:
class Example2::Impl
{
public:
   void privateOperation1();
   void privateOperation2();
private: // or public if Example2 needs access, or private + friendship:
   Type1 data1_;
   Type2 data2_;
};

내가 밑줄을 사용하여 비공개 (및 보호 된) 멤버를 붙인 것을 알 수 있습니다. PIMPL 버전에는 외부 세계가 작업을 보지 못하는 내부 클래스가 있습니다. 이렇게하면 클래스 인터페이스가 완전히 깨끗하게 유지됩니다. 실제 인터페이스 만 노출됩니다. 질서에 대해 논쟁 할 필요가 없습니다.

동적으로 할당 된 개체를 빌드해야하므로 클래스 생성 중에 관련 비용이 발생합니다. 또한 이것은 확장되지는 않았지만 계층 구조가 부족한 클래스에 대해 정말 잘 작동합니다. 보호 된 메서드는 외부 클래스의 일부 여야하므로 실제로 내부 클래스로 푸시 할 수 없습니다.

---

코딩 스타일은 놀라 울 정도로 열띤 대화의 원천이며, 다른 의견을 제공 할 위험이 있다는 점을 염두에 두십시오.

코드는 사람이 가장 쉽게 읽을 수 있도록 작성해야합니다. 나는 여기에 여러 번 주어진이 진술에 완전히 동의합니다.

편차는 우리가 취하는 롤입니다.

도움말을 사용자 클래스의 그것을 사용하는 방법을 이해 하나 작성하고 적절한 유지해야 문서를 . 사용자는 클래스를 사용하기 위해 소스 코드를 읽을 필요가 없어야합니다. 이것이 수행되면 (수동으로 또는 소스 내 문서 도구를 사용하여) 공개 및 비공개 클래스 멤버가 소스에서 정의되는 순서는 사용자에게 중요하지 않습니다.

그러나 코드 를 이해해야 하는 사람에게는 코드 검토, 풀 요청 또는 유지 관리 중에 순서가 매우 중요합니다. 규칙은 간단합니다.

항목을 사용하기 전에 정의해야합니다.

This is neither a compiler rule not is it a strictly public v.s. private rule, but common sense - human readability rule. We read code sequentially, and if we need "juggle" back and forth every time we see a class member used, but don't know its type for example, it adversely affects the readability of the code.

Making a division strictly on private v.s. public violates this rule because private class members will appear after they have been used in any public method.

---

i think it's all about readability.

Some people like to group them in a fixed order, so that whenever you open a class declaration, you quickly know where to look for e.g. the public data members.

In general, I feel that the most important things should come first. For 99.6% of all classes, roughly, that means the public methods, and especially the constructor. Then comes public data members, if any (remember: encapsulation is a good idea), followed by any protected and/or private methods and data members.

This is stuff that might be covered by the coding standards of large projects, it can be a good idea to check.

---

I tend to follow the POCO C++ Coding Style Guide.

---

In practice, it rarely matters. It's primarily a matter of personal preference.

It's very popular to put public methods first, ostensibly so that users of the class will be able to find them more easily. But headers should never be your primary source of documentation, so basing "best practices" around the idea that users will be looking at your headers seems to miss the mark for me.

It's more likely for people to be in your headers if they're modifying the class, in which case they should care about the private interface.

Whichever you choose, make your headers clean and easy to read. Being able to easily find whatever info I happen to be looking for, whether I'm a user of the class or a maintainer of the class, is the most important thing.

---

In our project, we don't order the members according to access, but by usage. And by that I mean, we order the members as they are used. If a public member uses a private member in the same class, that private member is usually located in front of the public member somewhere, as in the following (simplistic) example:

class Foo
{
private:
  int bar;

public:
  int GetBar() const
  {
    return bar;
  }
};

Here, the member bar is placed before the member GetBar() because the former is used by the latter. This can result in multiple access sections, as in the following example:

class Foo
{
public:
  typedef int bar_type;

private:
  bar_type bar;

public:
  bar_type GetBar() const
  {
    return bar;
  }
};

The bar_type member is used by the bar member, see?

Why is this? I dunno, it seemed more natural that if you encounter a member somewhere in the implementation and you need more details about that (and IntelliSense is screwed up again) that you can find it somewhere above from where you're working.

---

It is really helpful to the folks that will use your class to list the public interface first. It's the part they care about and can use. Protected and private can follow along after.

Within the public interface, it's convenient to group constructors, property accessors and mutators, and operators in distinct groups.

---

Note that (depending on your compiler and dynamic linker), you can retain compatibility with previous versions of a shared library by only adding to the end of the class (i.e. to the end of the interface), and not removing or changing anything else. (This is true for G++ and libtool, and the three part versioning scheme for GNU/Linux shared libraries reflects this.)

There's also the idea that you should order members of the class to avoid wasted space due to memory alignment; one strategy is to order members from smallest to largest size. I've never done this either in C++ or C though.

---

Overall, your public interface should come before anything, because that's the main/only thing that users of your classes should be interested in. (Of course, in reality that doesn't always hold, but it's a good start.)

Within that, member types and constants are best first, followed by construction operators, operations, and then member variables.

---

Put the private fields first.

With modern IDEs, people don't read the class to figure out what it's public interface is.

They just use intellisence (or a class browser) for that.

If someone is reading through the class definition, it's usually because they want to understand how it works.

In that case, knowing the fields helps the most. It tells you what the parts of the object are.

---

Depends entirely on your preference. There is no "the right way".

When doing C++ in my own pet projects I personally keep convention that I put access modifier before each member or method declaration.

ReferenceURL : https://stackoverflow.com/questions/308581/how-should-i-order-the-members-of-a-c-class