#paper #wip [Comparing techniques by means of encapsulation and connascence](https://dl.acm.org/doi/abs/10.1145/130994.131004) (ACM会員なら見れる) Meilir Page-Jones, Communications of the ACM Volume 35Issue 9Sept. 1992, pp147–151 # なぜこの論文を読んだか コナーセンスという概念を [[Fundamentals of Software Architecture: An Engineering]] を読んでいたら見つけた。 [https://connascence.io/](https://connascence.io/) というコナーセンスに関するコミュニティーページもあり、[https://connascence.io/pages/about.html](https://connascence.io/pages/about.html) によれば、 > The Origins of Connascence > Connascence is a software quality metric that attempts to measure coupling between entities. The term was used in a computer science context by Meilir Page-Jones in his article, Comparing techniques by means of encapsulation and connascence, Communications of the ACM volume 35 issue 9 (September 1992). > > In 1996, Meilir Page-Jones included a large section on connascence in his book "What every programmer should know about object-oriented design". The book can still be found on amazon.com. とあり、"Comparing techniques by means of encapsulation and connascence" がオリジナルだったので読んでみることにした # メモ > The ideal of stuctured design is to minimize the coupling of a system's design and to maximize the cohesion of the design 凝集度が高く結合度が低いような設計が理想である > However, to do so would be to overlook a chance to generalize coupling and cohesion into single measure of connascenece 凝集度と結合度はそれぞれうまい測定の仕組みがなかったが、 Connascenece を導入して1つのメトリクスで「凝集度の高さと結合度の低さ」を測定できるようにしたい。 Connascenece は、`born together` という意味を持つラテン語から命名していて、以下のように定義している > two software elements A and B to be connascent if there is at least one change that could be made to A that wouls neccessitate a change to B in order to preserve overall correctness すなわち ソフトウェアの要素 (クラスやメソッドやモジュールなどなんでも) A に対して変更を行う際にソフトウェアの要素Bにも変更が及ぶ場合に A と B は Connascenece の関係にあるということ。 例えば、以下のときに A で `a` の型を `String` に変更すると B でも `7` ではなく例えば、`"7"` を代入するなどの変更が必要になる。これらは、Connascenece in Type という関係にある。 kotlin ``` var a: Int // ソフトウェア要素 A // ... a = 7 // ソフトウェア要素 B ``` このように Connascenece には、いくつかの形式が存在していて、軽度な Connascenece もあれば 強度 な Connascenece もある。 > Eliminate any unnecessary connascenece and then minimize connascenece across the encapsulation boundaries by maximizing connascenece within encapsulation boundaries 基本的には、Connascenece をカプセル化の中で最大にすることでカプセル化した要素 (クラス、パッケージ、モジュールなど) 間では最小にすることで、「凝集度が高く、疎結合な設計」になると主張している。 Connascenece の種類 この辺りからは、 [https://connascence.io/](https://connascence.io/) の方が詳しい。 [https://www.youtube.com/watch?v=22vYwcfQnk8](https://www.youtube.com/watch?v=22vYwcfQnk8) これも詳しい What Every Programmer Should Know About Object-Oriented Design という本にインスパイアされている この本自体は、Connascenece が最も詳細に紹介されている (というか論文の著者が書いた本) (Connascenece は コネイセンス みたいに発音するらしい) ## Static Connascenece ### Name kotlin ``` class Customer { fun email() {} } fun sendEmail(customer: Customer) { customer.email() } ``` 命名に基づいた結合いたのこと。 メソッドに限らず例えば Rails で DBのカラム名とメソッド名が依存しているみたいな場合なども命名に基づく Connascenece になる。 現代では、IDEによるジャンプやリネーム機能があるしそこまで困らない気もする。 ### Type ### Meaning ### Position 順番に依存した実装による connascenece 順番を変更する場合には、その順番に依存している実装も含めて変更が必要になってしまう。 kotlin ``` val conditions = ["lastname = ?", "Werich"] // 0番目は xx とか 1番目は yy という意味みたいなのを知らないといけない ``` 引数の順番による依存などもこの connascenece に該当する ruby ``` def find(conditions, ordered_by, limit, offset, selected) ... end ``` 順番を覚えないといけない or 知らないといけないようなものはすべて該当する 例えば、マジックナンバーに名前をつけることで Connascenece by Name に変換することもできる。 ### Algorithm ## Dynamic Connascenece ### Execution ### Timing ### Value ### Identity ## Properties of Connascenece ### Locality > Aa the distance between software elements increases, use weaker forms of connascenece 例えば、メソッド内でのローカル変数の Connascenece by Name は、クラス間の Connascenece by Name よりも軽度 ### Degree > Convert high degrees of connascenece into weaker forms of connascenece # 感想 ref [Connascence, why is it so important?](https://programhappy.net/2020/06/22/connascence-why-is-it-so-important/) [Connascence:コードの結合度を測るもうひとつの指標 - snoozer05's blog](https://snoozer05.hatenablog.jp/entry/2020/12/11/150913)