我刚开始使用Go(GoLang),我发现它是一种很棒的语言.但是,经过多年的UML和面向对象的方法,我发现建模Go程序(逆向工程)有点问题,因为Go Structs包含属性/状态,但没有方法,以及使用Structs作为参数的方法/函数(即使那些做魔法使它使一个Struct看起来像一个对象),也不包含方法或状态.
这是否意味着我应该使用另一种Methodology来模拟Go程序,或者UML是否对语言结构进行了充分的建模？
是的我知道如果你在Structs上使用方法,可以通过结构和结构方法的组合将UML中对象的行为映射到Go,但我发现这是错误的,在范例中阻抗不匹配排序.
对于一个行为不再受物体控制的勇敢新世界,是时候采用新的(消亡思想!)图表技术了吗？行为可以建模而不参考它正在影响的状态？
更新:
我正在尝试数据流图,看看它们是否更适合范式.到目前为止一切都那么好,但我认为当我对Struct的方法进行建模时,我将会失败,DFD中的折衷方案是它们被视为函数.:(
Go支持继承!arghhh!(头被吹干净.)你可以组成一个由另一个结构组成的结构,它有方法,子结构现在继承了......你得到了吗？我的思绪被吹了.意味着UML有效......完全但感觉很脏.
Go不支持继承,它就是这样.:) DFD就是这样!
方法在结构本身定义之外声明的事实不应该是重要的; 它只是一个小的语法差异.这些方法属于结构类型,就像它们在大括号内一样.(它们在括号之外声明,因为方法不限于结构.)
使用UML和Go的真正潜在问题是UML通常与传统的面向对象设计(即类层次结构)一起使用,而Go采用不同的方法来继承和多态.也许UML可以适应Go的类型系统 - 我对UML不太熟悉 - 但是你的设计方法可能需要在某种程度上改变,无论你是否继续使用UML.
Go不打算用于Smalltalk和Java的所有对象样式.惯用Go程序通常包含很大比例的程序代码.如果您的设计过程侧重于对象建模,那么Go将无法正常工作.