Serviceを読んで理解し、同意したものとみなします。スタック・オーバーフローはプログラマーとプログラミングに熱心な人のためのQ&Aサイトです。226件01クラスの命名について相談です。articlesたとえばこんなのが考えられるかなと。ArticleRecommenderなどもちろんこのクラスが呼び出される文脈などの前条条件によるよって話はあると思います。適当に仮定をおいてもらって答えてもらってもいいですし、ジェネラルな範疇での回答でも構いません。とあるクラスを複数個管理するクラスのクラス名は、上の例に限らず前からかなりの回数困っているので、皆さんのアドバイスを伺いたいです。Railsならの話を。Railsを利用していたら、Articleはモデルになるパターンと思われます。その場合、クラスメソッドでArticleのArrayを返すように実装するのが普通で、それだけで足りる場合も多かったりするので、このパターンで悩むことはなかったりします。何か個々の処理endPythonでも、Railsのようなフレームワーク(Djangoなど?)があると思いますので、どういう風になっているか研究すると、悩まずに済むかもしれません。してもArrayなどでなかったり、拡張するクラスが必要なら、私なら「Articleが集まったら何になる?」という観点で考えます。Articleが記事という意味ならば、話題(TopicとかSubject)とか、スレッド(Thread)とか、掲示板(Board)ですね。Threadは言語的に既に存在したり、プログラム概念的に使われたりするので除外します。あとは、自分が作っているものは何かを考えて、それに沿うものを採用するという感じですね。あと、挙げられたパターンを私が検討するとすると、Typoの可能性があるので、他の人がメンテナンスする可能性があるのなら、採用しないです。実験で小さいプログラムを組むときや使い捨てのプログラムを組むときは、あまり悩みたくないので使うかもしれません。本当に色々な管理(単にArticleが集まっているだけではない場合)なら採用するかもしれません。その場合はArticleだけじゃないことが多いので、この名前にはなりそうにありませんが。Articleが何になるかすぐ思いつかない時などに仮で使ったりするかもしれません。あとで時間ができたらいい命名がないか考えます。いう感じで、3→2→1の優先順位で考えます。悩んでも仕方ないので、名前は単純置き換えしやすいものを優先し、実装しているうちにこんな名前がいいかもと思った時に、全置換で置き換えたりします。ArticleRecommenderなど1は良くないと思います。いろいろなArticleを適当に返すクラスはArticleの集合ではないので。2も良くないと思います。Managerって具体的に何をするのか不明瞭なので、命名のバッドプラクティスとしてよく上げられています。私なら、3の線で検討するべきかと思います。記事をチョイスして返すので、Curator(キュレーター)とか、ArticlePickerなんかを思いつきました。いうロジックで記事を選定するのか、他のモデルにはどんなものがあるとか、そういった点も考慮する必要がありそうなので、何がベストなのかは一概に言えないと思いますが・・・ご参考になれば幸いです。さんの回答で必要十分かとは思います。いくつかの言語を並列して挙げられているので、なるべく汎用的なクラス命名の関する答えが欲しいのかな、とも思っています。いうクラスを命名する」だと思います。引っ張ってくるメソッドなのかな、と思っています。それは、必然、データベースにどのようにデータが格納されているかについての情報を知っていないと、実装することは難しそうだと推察できます。ないかな、と思っています。