デザインメッセージシステム：公的および私的メンバーの心配

Question

ooデザインの質問のインタビュー：デザインメッセージシステムで、各クラスのメンバー/方法はpublicとprivateのいくつかの用途を理解できません。

ロングストーリー。ユーザークラスを次のように定義します。

class user { 
public: 
    string account_name; 
    string info; 
    vector<User> friend_list; 
    vector<Chat> chat_list; 
    void friend_request(User friend_target); 

private: 
    string system_user_id; 
} 

最初にprivateのメンバーがいるのでしょうか？

ここでは、system_user_idは、システムの実際のユーザーに公開されるべきではないため、プライベートであると定義しました。皆さんはどう思いますか？

Answer 1

私が参考になる別のことは、外部ユーザーだけでなく、userクラスのクライアントに適用されるカプセル化を検討することです。

クライアントは内部ユーザーである可能性があります。あなたのユーザーがインターネット上で最も人気のあるもので、システムに取り組んでいる開発者チームがいることを想像してみてください。

公開されているユーザークラスはaccount_nameです。彼らはアカウントの名前を変更して直接更新したいと考えています。しかし、有効なアップデートでデータストアなどとの同期が必要な場合はどうすればよいでしょうか？ユーザクラスの設計により、クライアント（内部）は不正なコードを作成することができました！

同じことがfriend_list、chat_listに行くことができます。ユーザーが並行環境で使用されている場合は、何らかのロックが必要な場合があります。リストを直接公開すると、内部クライアントはレースプライベートでカプセル化されていれば、内部のクライアントをより良く保護することができます。