C#のクラス名の付け方｜命名規則・よくある悩み・実例でわかりやすく解説

はじめに

C#でプログラムを書いていると、意外と悩みやすいのが「クラス名」の付け方です。

処理そのものは書けているのに、

C#
public class Data
{
}

C#
public class Manager
{
}

C#
public class UserInfoProcess
{
}

のような名前を付けてしまい、「このクラスは結局何をするものなのか」が後からわかりにくくなることがあります。

C#のクラス名は、単なる識別子ではありません。コードを読む人に対して、そのクラスの役割や責務を伝える重要な情報です。適切なクラス名を付けることで、コードの読みやすさ、保守性、チーム開発のしやすさが大きく変わります。

この記事では、C#のクラス名の基本的な命名規則から、実務で迷いやすい命名パターン、良い例・悪い例、FAQまでわかりやすく解説します。

1. C#のクラス名とは？まず押さえる基本

1-1. クラス名は「何を表すクラスか」を示す名前

C#のクラス名とは、そのクラスが何を表すのかを示す名前です。

たとえば、ユーザーを表すクラスであれば次のように命名します。

C#
public class User
{
    public int Id { get; set; }
    public string Name { get; set; }
}

注文を表すクラスであれば、次のような名前が自然です。

C#
public class Order
{
    public int Id { get; set; }
    public DateTime OrderedAt { get; set; }
}

このように、クラス名を見るだけで「何を扱うクラスなのか」が想像できることが大切です。

逆に、次のようなクラス名は意味が曖昧です。

C#
public class Data
{
}

C#
public class Info
{
}

C#
public class Process
{
}

DataやInfoは一見便利そうですが、あまりに抽象的です。何のデータなのか、何の情報なのかがわからないため、コード全体の見通しが悪くなります。

1-2. クラス名が読みやすさ・保守性に与える影響

クラス名は、コードの読みやすさに直接影響します。

たとえば、次のコードを見てみましょう。

C#
var service = new Service();
service.Execute();

このコードだけでは、何のサービスなのか、何を実行するのかがわかりません。

一方で、次のように書かれていればどうでしょうか。

C#
var emailService = new EmailService();
emailService.SendWelcomeEmail(user);

EmailServiceというクラス名から、メール送信に関する処理を担当していることがわかります。さらに、SendWelcomeEmailというメソッド名から、歓迎メールを送る処理であることも読み取れます。

クラス名が適切だと、コードを読む人は実装の中身を細かく確認しなくても、全体の構造を理解しやすくなります。これは、バグ修正や機能追加を行うときにも大きなメリットになります。

1-3. 変数名・メソッド名・ファイル名との違い

C#では、クラス名、変数名、メソッド名、ファイル名にはそれぞれ役割があります。

クラス名は「何を表す型なのか」を示します。

C#
public class Customer
{
}

変数名は「その値が何なのか」を示します。

C#
Customer customer = new Customer();

メソッド名は「何をする処理なのか」を示します。

C#
public void RegisterCustomer(Customer customer)
{
}

ファイル名は、基本的にそのファイルに定義されている主要なクラス名と一致させます。

Customer.cs

C#では、クラス名とファイル名が違っていてもコンパイルできる場合があります。しかし、実務ではクラス名とファイル名を一致させるのが一般的です。

たとえば、次のようにすると探しやすくなります。

Customer.cs        → public class Customer
OrderService.cs    → public class OrderService
UserRepository.cs  → public class UserRepository

1-4. C#でクラス名を適当に付けると起きる問題

C#のクラス名を適当に付けると、次のような問題が起きやすくなります。

まず、コードの意味が読み取りにくくなります。

C#
public class Common
{
}

Commonという名前だけでは、何を共通化したクラスなのかがわかりません。便利な名前に見えますが、さまざまな処理が詰め込まれやすく、結果的に保守しづらいクラスになりがちです。

また、似たような名前のクラスが増える原因にもなります。

C#
UserManager
UserService
UserHelper
UserUtility
UserCommon

名前だけでは役割の違いがわからないため、どのクラスを使うべきか迷ってしまいます。

さらに、クラス名が曖昧だと、責務が広がりすぎることがあります。最初は小さな処理だけを担当していたクラスに、後から別の処理がどんどん追加され、巨大なクラスになってしまうのです。

クラス名は、設計の方向性にも影響します。適切な名前を付けることは、適切な責務を持たせることにもつながります。

2. C#のクラス名の基本的な命名規則

2-1. クラス名はPascalCaseで書く

C#のクラス名は、基本的にPascalCaseで書きます。

PascalCaseとは、単語の先頭を大文字にしてつなげる書き方です。

C#
public class User
{
}

C#
public class UserProfile
{
}

C#
public class OrderService
{
}

次のような書き方は、C#のクラス名としては一般的ではありません。

C#
public class user
{
}

C#
public class userProfile
{
}

C#
public class user_profile
{
}

userProfileのような書き方はcamelCaseと呼ばれ、C#では主にローカル変数や引数名で使われます。

C#
public void UpdateUser(User userProfile)
{
}

クラス名にはPascalCaseを使う、と覚えておきましょう。

2-2. 名詞または名詞句で命名する

C#のクラス名は、基本的に名詞または名詞句にします。

良い例は次のとおりです。

C#
public class User
{
}

C#
public class Product
{
}

C#
public class OrderHistory
{
}

C#
public class PaymentService
{
}

クラスは「もの」や「概念」や「役割」を表すことが多いため、名詞で命名すると自然です。

一方、次のような動詞だけのクラス名は避けたほうがよいです。

C#
public class Create
{
}

C#
public class Calculate
{
}

C#
public class Send
{
}

処理を表したい場合は、動詞ではなく、役割を表す名詞句にします。

C#
public class UserCreator
{
}

C#
public class PriceCalculator
{
}

C#
public class EmailSender
{
}

ただし、CreatorやSenderのような名前を使う場合は、そのクラスの責務が本当に明確かどうかも確認しましょう。

2-3. 英単語を使い、省略しすぎない

C#のクラス名には、基本的に英単語を使います。

C#
public class Customer
{
}

C#
public class Invoice
{
}

C#
public class ProductCategory
{
}

英語にすると長くなるからといって、省略しすぎるのは避けましょう。

悪い例です。

C#
public class Usr
{
}

C#
public class Ord
{
}

C#
public class PrdCat
{
}

このような省略は、書いた本人にはわかっても、他の人には伝わりにくいです。数か月後の自分が読んでも、意味を思い出せない可能性があります。

改善するなら、次のようにします。

C#
public class User
{
}

C#
public class Order
{
}

C#
public class ProductCategory
{
}

ただし、一般的に広く使われている略語であれば使用しても問題ありません。

C#
public class UserDto
{
}

C#
public class ApiClient
{
}

C#
public class HtmlParser
{
}

DTO、API、HTMLなどは、多くの開発者に通じる略語です。ただし、プロジェクト内で表記を統一することが大切です。

2-4. 数字・記号・アンダースコアは基本的に避ける

C#のクラス名では、数字や記号、アンダースコアは基本的に避けます。

避けたい例です。

C#
public class User_001
{
}

C#
public class Order_Service
{
}

C#
public class Product2
{
}

C#ではアンダースコアを使った名前も書けますが、クラス名ではPascalCaseを使うのが一般的です。

C#
public class OrderService
{
}

数字を使いたくなるケースもありますが、Product2やUserService2のような名前は、設計が整理されていないサインであることが多いです。

たとえば、次のような名前があるとします。

C#
public class PaymentService
{
}

public class PaymentService2
{
}

この場合、何が違うのかがわかりません。

改善するなら、違いがわかる名前にします。

C#
public class CreditCardPaymentService
{
}

C#
public class BankTransferPaymentService
{
}

名前に数字を付ける前に、「何が違うクラスなのか」を言葉で表せないか考えてみましょう。

2-5. C#の予約語はクラス名に使わない

C#には、class、namespace、public、returnなどの予約語があります。これらは言語仕様で特別な意味を持つため、通常はクラス名として使えません。

たとえば、次のようなクラス名は避けます。

C#
public class Class
{
}

C#
public class Namespace
{
}

C#
public class Return
{
}

C#では、@を付けることで予約語を識別子として使える場合があります。

C#
public class @class
{
}

しかし、このような書き方は読みづらく、実務では避けるべきです。

予約語と紛らわしい名前ではなく、具体的な意味を持つ名前にしましょう。

C#
public class SchoolClass
{
}

C#
public class NamespaceDefinition
{
}

C#
public class ReturnValue
{
}

2-6. ファイル名とクラス名は基本的に一致させる

C#では、1つのファイルに複数のクラスを書くこともできます。しかし、基本的には1ファイルに1つの主要なクラスを定義し、ファイル名とクラス名を一致させるのがわかりやすいです。

たとえば、次のようにします。

User.cs

C#
public class User
{
}

OrderService.cs

C#
public class OrderService
{
}

ファイル名とクラス名が一致していると、Visual Studioやエディタ上で目的のクラスを探しやすくなります。

悪い例です。

Data.cs

C#
public class UserProfile
{
}

この場合、UserProfileクラスを探したいときに、Data.csというファイル名からは見つけにくくなります。

特にチーム開発では、ファイル名とクラス名を一致させるだけでも、コードの見通しがかなり良くなります。

3. C#のクラス名の付け方｜実務で使える考え方

3-1. クラスの責務から名前を決める

C#のクラス名を決めるときは、まず「このクラスの責務は何か」を考えます。

責務とは、そのクラスが担当する役割のことです。

たとえば、ユーザー情報を表すだけのクラスであれば、次のような名前が自然です。

C#
public class User
{
    public int Id { get; set; }
    public string Name { get; set; }
}

ユーザー登録の処理を担当するクラスであれば、次のような名前が考えられます。

C#
public class UserRegistrationService
{
}

ユーザー情報をデータベースから取得するクラスであれば、次のような名前が考えられます。

C#
public class UserRepository
{
}

同じ「ユーザー」に関するクラスでも、責務によって名前は変わります。

C#
User
UserProfile
UserRepository
UserRegistrationService
UserController
UserDto

クラス名を考えるときは、「このクラスは何を知っているのか」「このクラスは何を担当しているのか」を言葉にしてみると決めやすくなります。

3-2. 「何を扱うクラスか」で名前を決める

もっとも基本的な考え方は、「何を扱うクラスか」で名前を決めることです。

商品を扱うなら、次のようになります。

C#
public class Product
{
}

注文を扱うなら、次のようになります。

C#
public class Order
{
}

顧客を扱うなら、次のようになります。

C#
public class Customer
{
}

さらに具体化したい場合は、名詞を組み合わせます。

C#
public class ProductCategory
{
}

C#
public class OrderHistory
{
}

C#
public class CustomerAddress
{
}

このように、「対象となるもの」を中心に考えると、自然なクラス名になりやすいです。

3-3. 「何をするクラスか」を名前に含める場合

クラスが何らかの処理を担当する場合は、「何をするクラスか」を名前に含めることがあります。

たとえば、価格を計算するクラスなら次のようにします。

C#
public class PriceCalculator
{
}

メールを送信するクラスなら、次のようにします。

C#
public class EmailSender
{
}

レポートを生成するクラスなら、次のようにします。

C#
public class ReportGenerator
{
}

ただし、処理内容を名前に含める場合でも、クラス名そのものは名詞句にします。

悪い例です。

C#
public class CalculatePrice
{
}

改善例です。

C#
public class PriceCalculator
{
}

悪い例です。

C#
public class SendEmail
{
}

改善例です。

C#
public class EmailSender
{
}

メソッド名は動詞から始めることが多いですが、クラス名は名詞または名詞句にするのが基本です。

3-4. ドメイン・用途・役割を組み合わせる

実務では、単にServiceやRepositoryと付けるだけでは不十分なことが多いです。そこで、ドメイン、用途、役割を組み合わせて命名します。

たとえば、注文に関するサービスなら次のようにします。

C#
public class OrderService
{
}

注文の支払い処理を担当するなら、さらに具体化します。

C#
public class OrderPaymentService
{
}

ユーザー登録専用のサービスなら、次のようにします。

C#
public class UserRegistrationService
{
}

商品検索を担当するクラスなら、次のようにできます。

C#
public class ProductSearchService
{
}

命名の考え方としては、次の順番で組み合わせるとわかりやすくなります。

対象 + 用途 + 役割

例です。

User + Registration + Service
Order + Payment + Service
Product + Search + Service
Customer + Address + Repository

結果として、次のようなクラス名になります。

C#
UserRegistrationService
OrderPaymentService
ProductSearchService
CustomerAddressRepository

長くなりすぎる場合は、クラスの責務が広すぎないかも確認しましょう。

3-5. 迷ったときは具体的すぎず抽象的すぎない名前にする

クラス名は、抽象的すぎても具体的すぎても使いにくくなります。

抽象的すぎる例です。

C#
public class Data
{
}

C#
public class Processor
{
}

C#
public class Manager
{
}

これらは意味が広すぎて、何を担当するクラスなのかわかりません。

一方で、具体的すぎる名前も問題になることがあります。

C#
public class UserNameAndEmailAndPasswordValidationService
{
}

この名前は長すぎます。名前を見るだけで疲れてしまいますし、責務が細かく分かれていない可能性もあります。

改善するなら、次のようにします。

C#
public class UserValidationService
{
}

クラス名は、読む人が役割を理解できる程度に具体的でありながら、長くなりすぎないことが大切です。

目安としては、名前だけを見て「何を扱うクラスか」「どんな役割か」がだいたいわかれば十分です。

4. C#のクラス名でよく使われる命名パターン

4-1. Model・Entityを使うクラス名

ModelやEntityは、データ構造や業務上の概念を表すクラス名でよく使われます。

たとえば、ユーザーを表すクラスです。

C#
public class User
{
    public int Id { get; set; }
    public string Name { get; set; }
}

Entityとして明示したい場合は、次のようにすることもあります。

C#
public class UserEntity
{
    public int Id { get; set; }
    public string Name { get; set; }
}

ViewModelを使う場合は、画面表示用のデータであることを示します。

C#
public class UserViewModel
{
    public string DisplayName { get; set; }
}

ModelとEntityの使い分けはプロジェクトによって異なりますが、一般的には次のように考えるとわかりやすいです。

Entityは、データベースやドメイン上の実体を表すときに使われます。

C#
public class ProductEntity
{
}

Modelは、画面やAPI、アプリケーション上で扱うデータ構造を広く表すときに使われます。

C#
public class ProductModel
{
}

ただし、すべてのクラスにModelやEntityを付ければよいわけではありません。単にUserやProductで十分な場合も多くあります。

4-2. Serviceを使うクラス名

Serviceは、業務ロジックやアプリケーションの処理を担当するクラスによく使われます。

例です。

C#
public class UserService
{
}

C#
public class OrderService
{
}

C#
public class PaymentService
{
}

ただし、Serviceは便利な反面、何でも入れられる名前になりやすい点に注意が必要です。

悪い例です。

C#
public class UserService
{
    public void RegisterUser() { }
    public void SendEmail() { }
    public void ExportCsv() { }
    public void DeleteOldLogs() { }
}

このように、ユーザーに少しでも関係していれば何でも入れてしまうと、責務が広がりすぎます。

必要に応じて、より具体的な名前に分けましょう。

C#
public class UserRegistrationService
{
}

C#
public class UserNotificationService
{
}

C#
public class UserExportService
{
}

Serviceを使うときは、「何のサービスなのか」「どの業務処理を担当するのか」がわかる名前にすることが大切です。

4-3. Repositoryを使うクラス名

Repositoryは、データの取得や保存を担当するクラスによく使われます。

たとえば、ユーザー情報をデータベースから取得したり保存したりするクラスです。

C#
public class UserRepository
{
    public User FindById(int id)
    {
        // データベースからユーザーを取得する処理
        return new User();
    }

    public void Save(User user)
    {
        // データベースにユーザーを保存する処理
    }
}

商品を扱うRepositoryなら、次のようになります。

C#
public class ProductRepository
{
}

注文を扱うRepositoryなら、次のようになります。

C#
public class OrderRepository
{
}

Repositoryという名前を使う場合は、データアクセスに関する責務を持つクラスであることが伝わるようにしましょう。

逆に、業務ロジックを大量に含める場合は、RepositoryではなくServiceなどに分けることを検討します。

4-4. Controllerを使うクラス名

Controllerは、ASP.NET Core MVCやWeb APIでよく使われる命名パターンです。リクエストを受け取り、必要な処理を呼び出し、レスポンスを返す役割を持ちます。

例です。

C#
public class UsersController
{
}

C#
public class OrdersController
{
}

ASP.NET Coreでは、Controllerクラス名にControllerを付けるのが一般的です。

C#
public class ProductsController
{
}

Controller名は、扱うリソースに合わせて命名します。

ユーザーを扱うなら、

C#
UsersController

注文を扱うなら、

C#
OrdersController

商品を扱うなら、

C#
ProductsController

のようにします。

Web APIでは、リソースを扱うController名に複数形を使うこともよくあります。ただし、プロジェクト内で単数形・複数形の方針を統一することが大切です。

4-5. Managerを使うクラス名

Managerは、何かを管理するクラス名として使われることがあります。

C#
public class UserManager
{
}

C#
public class SessionManager
{
}

C#
public class CacheManager
{
}

ただし、Managerは意味が広くなりやすい名前です。「管理する」と言っても、作成、更新、削除、通知、変換、保存など、さまざまな処理が含まれてしまう可能性があります。

悪い例です。

C#
public class OrderManager
{
    public void CreateOrder() { }
    public void CancelOrder() { }
    public void SendOrderEmail() { }
    public void ExportOrderCsv() { }
    public void CalculateOrderTotal() { }
}

このように、何でも担当するクラスになっている場合は、より具体的な名前に分けることを検討します。

C#
public class OrderCreationService
{
}

C#
public class OrderCancellationService
{
}

C#
public class OrderNotificationService
{
}

Managerを使ってはいけないわけではありません。しかし、名前が曖昧になりやすいため、より具体的な名前が付けられないかを先に考えるのがおすすめです。

4-6. Helper・Utilityを使うクラス名

HelperやUtilityは、補助的な処理をまとめるクラス名として使われることがあります。

C#
public class StringHelper
{
}

C#
public class DateTimeUtility
{
}

C#
public class FileHelper
{
}

ただし、HelperやUtilityも非常に便利な名前なので、使いすぎると責務が曖昧になります。

悪い例です。

C#
public class CommonHelper
{
    public string FormatDate(DateTime date) { return ""; }
    public void SendEmail() { }
    public int CalculatePrice() { return 0; }
    public void SaveFile() { }
}

このようなクラスは、関係のない処理が集まりやすくなります。

改善するなら、処理の種類ごとに分けます。

C#
public class DateFormatter
{
}

C#
public class EmailSender
{
}

C#
public class PriceCalculator
{
}

C#
public class FileStorage
{
}

HelperやUtilityを使う場合は、本当に補助的な処理なのか、より意味のある名前にできないかを確認しましょう。

4-7. Factoryを使うクラス名

Factoryは、オブジェクトの生成を担当するクラスに使われます。

C#
public class UserFactory
{
    public User Create(string name)
    {
        return new User
        {
            Name = name
        };
    }
}

複雑な生成処理がある場合や、生成条件によって返すオブジェクトを変える場合に使われます。

例です。

C#
public class PaymentFactory
{
    public IPayment Create(string paymentType)
    {
        if (paymentType == "CreditCard")
        {
            return new CreditCardPayment();
        }

        return new BankTransferPayment();
    }
}

Factoryを使うと、「このクラスは何かを作る役割を持つ」ということが名前からわかります。

ただし、単にnewするだけのクラスに無理にFactoryを作る必要はありません。生成処理が複雑な場合に使うと効果的です。

4-8. DTO・Request・Responseを使うクラス名

APIやレイヤー間のデータ受け渡しでは、DTO、Request、Responseといった名前がよく使われます。

DTOは、Data Transfer Objectの略で、データを運ぶためのオブジェクトです。

C#
public class UserDto
{
    public int Id { get; set; }
    public string Name { get; set; }
}

リクエスト用のクラスにはRequestを付けます。

C#
public class CreateUserRequest
{
    public string Name { get; set; }
    public string Email { get; set; }
}

レスポンス用のクラスにはResponseを付けます。

C#
public class CreateUserResponse
{
    public int UserId { get; set; }
    public string Message { get; set; }
}

検索条件を表す場合は、次のような名前もよく使われます。

C#
public class UserSearchRequest
{
    public string Keyword { get; set; }
}

C#
public class UserSearchResponse
{
    public List<UserDto> Users { get; set; }
}

RequestやResponseを付けると、APIの入力用なのか出力用なのかがわかりやすくなります。

5. C#のクラス名の具体例

5-1. 良いクラス名の例

良いクラス名は、役割が明確で、読みやすく、プロジェクト内の命名規則に合っています。

例です。

C#
public class User
{
}

ユーザーを表すクラスだとすぐにわかります。

C#
public class Order
{
}

注文を表すクラスとして自然です。

C#
public class ProductCategory
{
}

商品カテゴリを表すクラスだとわかります。

C#
public class UserRepository
{
}

ユーザーのデータ取得や保存を担当するクラスだと想像できます。

C#
public class OrderPaymentService
{
}

注文の支払い処理を担当するサービスだとわかります。

C#
public class PriceCalculator
{
}

価格計算を担当するクラスだとわかります。

C#
public class ReportGenerator
{
}

レポート生成を担当するクラスだとわかります。

良いクラス名に共通しているのは、名前を読んだだけで役割をある程度想像できることです。

5-2. 悪いクラス名の例

悪いクラス名は、意味が曖昧だったり、短すぎたり、責務が広すぎたりします。

例です。

C#
public class Data
{
}

何のデータなのかわかりません。

C#
public class Info
{
}

何の情報なのかが不明です。

C#
public class Common
{
}

共通処理を何でも入れてしまいやすい名前です。

C#
public class Manager
{
}

何を管理するのかがわかりません。

C#
public class Test
{
}

テスト用なのか、実装用なのか判断できません。

C#
public class A
{
}

短すぎて意味が伝わりません。

C#
public class UserService2
{
}

UserServiceとの違いがわかりません。

このような名前を見つけたら、「このクラスは何を表しているのか」「何を担当しているのか」を言葉にして、より具体的な名前に変更しましょう。

5-3. 抽象的すぎるクラス名の改善例

抽象的すぎるクラス名は、具体的な役割が伝わる名前に改善します。

悪い例です。

C#
public class Data
{
}

改善例です。

C#
public class UserData
{
}

さらに、データの意味を明確にするなら次のようにします。

C#
public class UserProfile
{
}

悪い例です。

C#
public class Processor
{
}

改善例です。

C#
public class PaymentProcessor
{
}

悪い例です。

C#
public class Helper
{
}

改善例です。

C#
public class DateFormatter
{
}

悪い例です。

C#
public class Manager
{
}

改善例です。

C#
public class SessionManager
{
}

さらに具体的にできるなら、次のようにします。

C#
public class UserSessionStore
{
}

抽象的な名前を改善するときは、「何の」「どんな役割の」クラスなのかを追加するとわかりやすくなります。

5-4. 長すぎるクラス名の改善例

クラス名は具体的であることが大切ですが、長すぎる名前は読みづらくなります。

悪い例です。

C#
public class UserNameAndEmailAndPasswordValidationService
{
}

改善例です。

C#
public class UserValidationService
{
}

悪い例です。

C#
public class ProductPriceAndTaxAndDiscountCalculationService
{
}

改善例です。

C#
public class ProductPriceCalculator
{
}

悪い例です。

C#
public class CustomerOrderHistoryCsvFileExportService
{
}

改善例です。

C#
public class OrderHistoryCsvExporter
{
}

長すぎるクラス名になる場合は、次のどちらかを疑いましょう。

1つ目は、名前に情報を詰め込みすぎているケースです。重要な単語だけを残せば、短くできます。

2つ目は、クラスの責務が多すぎるケースです。1つのクラスが複数の役割を持っているなら、クラスを分割したほうがよい場合があります。

5-5. 日本語ローマ字のクラス名を避けるべき理由

C#では、日本語のローマ字を使ったクラス名も書けます。

C#
public class Seihin
{
}

C#
public class Chumon
{
}

C#
public class Kokyaku
{
}

しかし、実務では基本的に避けたほうがよいです。

理由は、英単語より意味が伝わりにくいからです。SeihinよりProduct、ChumonよりOrder、KokyakuよりCustomerのほうが、多くの開発者に伝わりやすくなります。

改善例です。

C#
public class Product
{
}

C#
public class Order
{
}

C#
public class Customer
{
}

また、ローマ字は表記ゆれが起きやすいという問題もあります。

C#
Chumon
Tyumon
Chuumon

このように、人によって書き方が変わる可能性があります。英単語で統一したほうが、コード全体の一貫性を保ちやすくなります。

5-6. 初心者がやりがちな命名ミスと修正例

初心者がやりがちなミスとして、まず短すぎる名前があります。

悪い例です。

C#
public class U
{
}

修正例です。

C#
public class User
{
}

次に、意味が広すぎる名前です。

悪い例です。

C#
public class Common
{
}

修正例です。

C#
public class DateFormatter
{
}

C#
public class FilePathBuilder
{
}

次に、処理名をそのままクラス名にしてしまうケースです。

悪い例です。

C#
public class CreateUser
{
}

修正例です。

C#
public class UserCreator
{
}

または、サービスとして表現します。

C#
public class UserRegistrationService
{
}