特定のフィールドのクラスのメソッドをラップしたメソッドを自動生成したい

Question

下記のコードのようにHogeクラスがHoge2インスタンスを持っている場合に、Hoge2のメソッドをラップしたメソッドを自動生成かインテリセンスで補完する方法を探しています。

interfaceを実装していて、フィールドとして持っている場合はVisualStudioのインテリセンスが機能しますが、下記のような場合だと機能しません。
拡張機能などでもかまわないので、ご教授いただけると幸いです。

        public class Hoge
        {
            Hoge2 m_hoge2;

            //このようなメソッドを自動生成したい。
            public void Do()
            {
                m_hoge2.Do();
            }
            public void Do2()
            {
                m_hoge2.Do2();
            }
        }
        public class Hoge2
        {
            public void Do()
            {
            }
            public void Do2()
            {
            }
        }

Comments

[退会済みユーザー]

> Hoge2のメソッドをラップしたメソッドを自動生成かインテリセンスで補完する

どういう結果になればいいのかを追記してもらえますか？　インターフェイスを継承したときのように、インターフェイスで定義されているメソッドが、中身は throw new NotImplemantationException(); で自動的に追加されればいいのですか？

インターフェイスの場合とは違って、全く便利だとは思えないのですが、どうしてそんな機能が欲しいのですか？

[concern12]

補完結果を記述しました。
>インターフェイスの場合とは違って、全く便利だとは思えないのですが、どうしてそんな機能が欲しいのですか？
単にコードを書く手間を抑えられればいいなという考えからです。

[episteme]

なら一時的に public class Hoge : IHoge2 しておいてインテリセンスにひな型作らせ、しかるのち : IHoge を消しては?

[Zuishin]

m_hoge2 を public にすれば事足りるので、需要はほとんど無いと思われます。自分で作るしかないんじゃないでしょうか。

[concern12]

>なら一時的に public class Hoge : IHoge2 しておいてインテリセンスにひな型作らせ、しかるのち : IHoge を消しては?
ありがとうございます。思いつきませんでした。参考にさせていただきます。

>m_hoge2 を public にすれば事足りるので、需要はほとんど無いと思われます。自分で作るしかないんじゃないでしょうか。
Hoge2のメンバーをすべて公開したいのであればその手法で問題ありませんが、Hoge2の一部のメソッドだけを公開したい場合や、Hoge2のメソッドの実行の前に確実に特定のメソッドを実行したい場合は事足りません。

[Zuishin]

ますますもって需要が無さそうです。私ならマルチキャレットを使うか、Vim で開いてマクロで処理します。

[退会済みユーザー]

> Hoge2の一部のメソッドだけを公開したい場合や、

言ってることが矛盾してるのでは？　「メソッドを自動生成」でやるなら、自動であなたがどれを公開したいのか Visual Studio が判断するのですか？

> Hoge2のメソッドの実行の前に確実に特定のメソッドを実行したい

どういう意味ですか？　「自動生成かインテリセンスで補完する方法」が知りたいのですよね？　それと「実行の前に確実に特定のメソッドを実行」とどう関係するのでしょう？

[Zuishin]

もしかすると「アスペクト志向」を調べれば別の解決法がみつかるかもしれません。

[concern12]

SurferOnWwwさん
>言ってることが矛盾してるのでは？　「メソッドを自動生成」でやるなら、自動であなたがどれを公開したいのか Visual Studio が判断するのですか？
矛盾していないと思います。
VisualStudioのinterfaceの抽出の機能のようなものをイメージしていただけれるとわかりやすいかもしれません。

>どういう意味ですか？　「自動生成かインテリセンスで補完する方法」が知りたいのですよね？　それと「実行の前に確実に特定のメソッドを実行」とどう関係するのでしょう？
以下のように補完されたメソッド内に記述したいという話です。
public void Do()
{
Aaa();
m_hoge2.Do();
}

質問で求めている自動生成、インテリセンスの手法をご存知でなければ存じていないという旨だけでありがたいので大丈夫です。

[Zuishin]

> ご存知でなければ存じていないという旨だけでありがたいので大丈夫です。

知っています。

[concern12]

Zuishinさん
VisualStudio側がこのような機能を提供していないということは、たしかに需要が少ない、もしくは、マルチキャレットなどを駆使して定義しろという事かもしれませんね。
ありがとうございました。

[Zuishin]

望み通りの物を作る方法は知っていて、作ることもできます。

[退会済みユーザー]

> 質問で求めている自動生成、インテリセンスの手法をご存知でなければ存じていないという旨だけでありがたいので大丈夫です。

だったら最初から質問に「質問で求めている自動生成、インテリセンスの手法をご存知でなければ回答・レスは結構です。代案等は不用です」とはっきり書いておきましょう。

お互い手間が省けます。

[fana]

継承関係に無い状態においてシグニチャがそのまんまな移譲コードが欲しい的な…？
当該機能が欲しそうな場面は…？と考えると pImpl とか書く場面かなぁ，とか．（この質問は C# だから該当しないけど）
（「pImplの実装作業って，何か機械的にやってくれるようなのは無いのかなぁ」とか思って調べたことはありますが，見つからなかったです）

Answer 1

試しにRoslyn Code Refactoring（拡張機能）で作ってみました（もう見てないような気がしますが^^;

日本語でまともな情報は、ほぼこちらしかありません。
neue cc - VS2015+RoslynによるCodeRefactoringProviderの作り方と活用法

記事当時と変わっているところは「下準備」くらいです。
今は「Visual Studio 拡張機能の開発」ワークロードを入れるだけでいいはずです（おそらく^^;

あと「Code Refactoring(.NET Standard)」テンプレートがVisual Studio 2022向けになっていないので、2022用にするにはCodeRefactoring1.Vsixプロジェクトを2点変更が必要でした。

• Microsoft.VSSDK.BuildToolsのバージョンアップ
  16.8.3038から17.2.2186へ。
• source.extension.vsixmanifestのInstallationTargetを変更
  Visual Studio の拡張機能を更新する - Visual Studio (Windows) | Microsoft Docs

using System.Composition;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.CodeAnalysis;
using Microsoft.CodeAnalysis.CodeActions;
using Microsoft.CodeAnalysis.CodeRefactorings;
using Microsoft.CodeAnalysis.CSharp;
using Microsoft.CodeAnalysis.CSharp.Syntax;
using Microsoft.CodeAnalysis.Formatting;

namespace CodeRefactoring1
{
    [ExportCodeRefactoringProvider(LanguageNames.CSharp, Name = nameof(CodeRefactoring1CodeRefactoringProvider)), Shared]
    internal class CodeRefactoring1CodeRefactoringProvider : CodeRefactoringProvider
    {
        public sealed override async Task ComputeRefactoringsAsync(CodeRefactoringContext context)
        {
            var root = await context.Document.GetSyntaxRootAsync(context.CancellationToken).ConfigureAwait(false);
            var node = root.FindNode(context.Span);

            if (node is VariableDeclaratorSyntax varDecl)
            {
                var model = await context.Document.GetSemanticModelAsync(context.CancellationToken).ConfigureAwait(false);
                if (model.GetDeclaredSymbol(varDecl) is IFieldSymbol fs)
                {
                    var action = CodeAction.Create("Generate Wrapper Methods", c => GenerateWrapperMethod(context.Document, root, varDecl, fs.Type));
                    context.RegisterRefactoring(action);
                }
            }
        }

        private Task<Document> GenerateWrapperMethod(Document document, SyntaxNode root, VariableDeclaratorSyntax varDecl, ITypeSymbol typeSymbol)
        {
            var val = varDecl.Identifier.Text;
            var methods = typeSymbol.GetMembers()
                 .OfType<IMethodSymbol>()
                 .Where(x => x.MethodKind == MethodKind.Ordinary && x.DeclaredAccessibility == Accessibility.Public && !x.IsStatic)
                 .Select(ms =>
                 {
                     var ret = ms.ReturnType.ToString();
                     var r = ret == "void" ? "" : "return ";
                     var name = ms.Name;
                     var pdef = string.Join(", ", ms.Parameters.Select(x => $"{x.Type} {x.Name}"));
                     var para = string.Join(", ", ms.Parameters.Select(x => $"{x.Name}"));

                     return SyntaxFactory.ParseMemberDeclaration($"public {ret} {name}({pdef}){{{r}{val}.{name}({para});}}")
                                         .WithTrailingTrivia(SyntaxFactory.CarriageReturnLineFeed)
                                         .WithAdditionalAnnotations(Formatter.Annotation);
                 }).ToArray();

            var oldClass = varDecl.FirstAncestorOrSelf<ClassDeclarationSyntax>();
            var newClass = oldClass.AddMembers(methods);

            var newRoot = root.ReplaceNode(oldClass, newClass);
            var newDocument = document.WithSyntaxRoot(newRoot);

            return Task.FromResult(newDocument);
        }
    }
}

CodeRefactoring1.Vsixプロジェクトのbinに、CodeRefactoring1.Vsix.vsixができているのでダブルクリックしてインストールします。

注意

• 変数名の頭か中間にカーソルがないと反応しません
• パブリックなインスタンスメソッドをすべて生成します（選べたりはしません）
• 親クラスのメソッドは見ません
• usingの追加はしませんし、あったとしても型はフルネームです（名前の単純化をドキュメントで実行してください）
• Hoge2とintくらいしかチェックしてません
• 何度も生成できてしまいます

---

参考記事では「非常に簡単」とおっしゃっていますが、かなりめんどかったですｗ
なぜかデバッグで変数がうまく見れなくて、手探りが非常に多かった（コードは短いですが^^;

Roslynに慣れてくれば楽々なのかもしれませんが、慣れる前に力尽きそうです（「効率のためならどんな苦労も厭わない」心意気が必要ですね^^;

Comments

[concern12]

返信が遅くなり申し訳ありません。
Roslynを用いて実装することも考えていましたが、あまりの情報の少なさに手が出ずにいました。
情報が少ない中、わざわざ実装してくださり、ありがとうございました！

Answer 2

Hoge2 を継承して Hoge を定義すべきです。そうすれば「自動生成かインテリセンスで補完」などということは必要ないでしょう？　オブジェクト指向プログラミングの基本に沿ったやり方でもありますし。

Comments

[concern12]

ご回答ありがとうございます。
もちろん継承関係が成り立つ場合であれば継承を用いますが、継承の関係が成り立たない場合にラップしたメソッドの定義が面倒という理由で継承することは、コードが汚くなるため厳しいです。

[退会済みユーザー]

> 継承の関係が成り立たない場合

具体的にはどういうことでしょうか？