6

Go (GoLang) を使い始めたばかりで、素晴らしい言語だと感じています。しかし、長年の UML とオブジェクト指向メソッドの後で、Go プログラムのモデリング (リバース エンジニアリング) には少し問題があることがわかりました。Go 構造体にはプロパティ/状態が含まれますが、メソッドは含まれず、構造体をパラメーターとして使用するメソッド/関数は含まれません。 (Struct をオブジェクトのように見せるために魔法をかけるものでさえ)、メソッドや状態は含まれません。

これは、Go プログラムをモデル化するために別の方法論を使用する必要があるということですか、それとも UML が言語構造を十分にモデル化するということですか?

はい、構造体でメソッドを使用すると、UML のオブジェクトの動作を構造体と構造体メソッドの組み合わせを介して Go にマッピングできることはわかっていますが、これは間違っていると思います。ソートします。

動作がオブジェクトによって制御されなくなった素晴らしい新しい世界のために、新しい (考えを滅ぼす!) 作図技術の時が来ましたか? 影響している状態を参照せずに行動をモデル化できますか?

アップデート：

データ フロー ダイアグラムを試して、パラダイムにより適しているかどうかを確認しています。ここまでは順調ですが、Struct のメソッドをモデル化すると行き詰まることになると思います。DFD の妥協点は、メソッドが関数として扱われることです。:(

Go は継承をサポートしています!!! ああああ!!! （頭が吹き飛ばされます。）サブ構造体が継承するメソッドを持つ別の構造体で構成される構造体を作成できます...これを取得しますか？私の心は吹き飛ばされます。UML が有効であることを意味します...完全にですが、汚い感じがします。

Go は継承をサポートしていません。:) それならDFDだ！

4

4 に答える 4

4

UML は、コンポーネント、インターフェース、およびデータの分析と設計に役立つツールを引き続き提供します。Go は OO 言語ではないため、継承、ポリモーフィズム、メソッドなどを使用することはできません。新しいパラダイムは必要ありません。古いパラダイムが必要になる場合があります:構造化分析と構造化設計。

于 2013-07-30T19:51:04.527 に答える
0

Go Structs にはプロパティ/状態が含まれますが、メソッドは含まれません。また、Struct をパラメーターとして使用するメソッド/関数 (Struct をオブジェクトのように見せるために魔法をかけるものも含む) には、メソッドや状態は含まれません。

ご存知かもしれませんが、C++ では構造体でメソッドを宣言することもできます。クラスと同様に、アクセス修飾子を使用できないという唯一の違いがあります。

OOP 言語では、クラス定義内でクラスのメソッドを宣言し、これらのメソッドがクラスの一部であるかのように感じさせます。これはほとんどの言語には当てはまりませんが、Go はこれを明確にします。

従来の OOP 言語で次の擬似コードのようなものを宣言すると:

class Foo {
    public function bar(x int) {
        // ...
    }
}

リンカーは、次のような関数をエクスポートします。

Foo__bar(this Foo, x int)

次に行うと（fが のインスタンスであると仮定しますFoo）：

f.bar(3)

あなたは実際に（そして間接的に、後で詳しく）やっています：

Foo__bar(f, 3)

クラス インスタンス自体には、実装および/または継承するメソッドへの関数ポインタを持つ、いわゆるvtableのみが含まれます。

さらに、少なくとも現代のプログラミングの世界では、メソッドには状態が含まれていません。

これは、Go プログラムをモデル化するために別の方法論を使用する必要があるということですか、それとも UML が言語構造を十分にモデル化するということですか?

UML で十分です。

動作がオブジェクトによって制御されなくなった素晴らしい新しい世界のために、新しい (考えを滅ぼす!) 作図技術の時が来ましたか?

いや。

影響している状態を参照せずに行動をモデル化できますか?

はい、それがインターフェースの目的です。

データ フロー ダイアグラムを試して、パラダイムにより適しているかどうかを確認しています。ここまではうまくいっていますが、構造体のメソッドをモデル化すると行き詰まることになると思います。DFD の妥協点は、それらが関数として扱われることです。:(

抽象化で迷子にならないように、それらを壊してください。完璧なパラダイムはありません。

于 2013-07-31T09:03:45.690 に答える
-1

プログラミングよりも計画とモデリングのほうが好きなら、Java を使い続けるべきです。

実際のコードと動作するシステムを構築して維持するのが好きなら、一枚の紙やホワイトボードに Go プログラムを計画して、プログラミングを始めてみてください。

于 2013-07-30T19:24:21.250 に答える