設計もしくはデザインという行為についてのいくつかの対話

処理をどのクラスに置くべきかは、本当はその処理の内容を見て判断しなきゃいけないことなのに、getterを使っているという字面（じづら）で判断できるという幻想を与えてしまう。そのことを指して「害悪」と言っています。

2019-09-18 23:20:23

これはそのとおりですね。蛇足ですが経験上それを判断できてない現場が圧倒的に多かったですね(SI現場)。というかそれ以前にフレームワークとの相性でトランザクションスクリプト前提になることが多くこれならgetterは不可欠ですが結局ロジックの分散・重複に対処不能という典型的な辛さはありました twitter.com/sugimoto_kei/s…

2019-09-19 10:42:20

ならば抽象データ型のようなアプローチをとれば？というのも選択肢ですが、頭でわかっていてもできない現象が起きている気がするんですね。getterを適切に使えるかの問題に限ったことではないですが。

2019-09-19 10:42:20

ADTとかオブジェクト指向の議論、GUIとかが分かりやすいし、アスセサもありなんだけど、業務アプリ開発するとき、設計のポイントが変わるんだよな。

2019-09-20 07:26:50

@masatsugumatsus ADTの発展形で考えるなら、GUIもアクセサも出てこないでしょうね。 ADTはGUIとは無関係だし、アクセサは、GUI由来の規約(Java Bean)かクラスを使った手続き型プログラミング(EJB)由来ですからね。 ADT、型、クラスの議論は手続きやGUIとは別の領域の議論なんですけどね。

2019-09-20 08:12:07

@masuda220 コードコンプリートの例ではgetterやsetterが抽象的振る舞いとして出てますね。ADTが利用される例として。 getter、setterが内部構造を直接露出しないものであるという前提があると思います。その前提がGUIという利用シーンでははまるな、という意見です。

2019-09-20 08:29:40

@masuda220 個人的にはADTとして扱う場合はgetterなしの方がいいと思いますが、それはname（）みたいな名前にしようと同じことです。

2019-09-20 08:33:57

@masatsugumatsus コードコンプリートは全体としては手続き的プログラミングの本なので、そういうとらえ方なんでしょうね。

2019-09-20 08:35:53

@masatsugumatsus name()を、誰がどう使うか次第でしょうね。名前を使って何か演算したいなら、そのロジックは型に閉じ込めることを検討したい。そういう発想とスキルを磨くことがたいせつ。

2019-09-20 08:40:03

@masuda220 その話はそれがgetterと命名されても同じことですよね。もう一つはデータ構造としてのモジュールがアプリケーション全体からみて不要か、という点がありますが作った方がより上手く構造化できるとは今は思ってます。ここは明確に増田さんは不要派かな、と。

2019-09-20 09:05:28

@masatsugumatsus 不要じゃないですよ。 DTO的なクラスは、私も今でも時々書いていますよ。ただ、主要な関心事じゃないし、設計の主たる課題じゃないと思って、軽く見ているだけです。気がつけばgetterを書いていることもあります。その時、これはコードの嫌な臭いなんで、なんとかしたいな、と思っているだけです。

2019-09-20 09:24:42

@masuda220 なるほど

2019-09-20 09:32:13

コードで表現していない言葉をいくらかき集めても、ユビキタス言語とは呼ばない。実装と詳細レベルで結びついたモデルと、コードとの結びつきがないモデルでは、価値がまったく違う。パッケージ名、クラス名、メソッド名。この名前の集合だけで、どのくらい問題領域を語ることができるか？

2019-09-22 08:54:57

あと分析とか設計とかいくら言ってもいいけど、コードとして形を示せない言説は信用ならない。頭や言語で表現されることで真意や違いが分かったとしても、コードで評価できないと僕らの仕事では意味をなすかどうか判定できないのでね。最終的にはコードで語ろうというのはそういう意味がある

2019-09-23 01:45:46

ファウラー曰く、”概念モデルは実装(クラス)ではなく、インターフェイス(型)につながっている” この定義からすると、実装とインターフェイスを分離できない言語は概念モデルを表現しづらいということになりますね

2019-09-24 16:18:35

僕らエンジニアはコードを重視する。それはそうなんだけど、ユーザーとの対話もコードと同じくらい大事なんだな。そして、ユーザーとの対話はコードに先行する。最終的にはコードで語ろうと言っても、コードを書く前に、しかもユーザーとどう語るのか。僕らがそこを避けて通ると、有象無象が介入する。

2019-09-24 21:18:00

設計＝デザインにおいては、やはり、ビジョンが先行するんだと思います。ビジョンというのは、問題領域をこのように変容させようという目論見といてもよい。それが先行する。だってそれが無ければ、設計という営為がそもそも立ち上がらないやん。...

2019-09-24 21:25:01

...ただ、ビジョンは言いっ放しではいけない。実装=コードに落とさなければいけない。これは設計者の責任／倫理の問題。しかし一方で、ソフトウェアの多くの革新は、非現実的なビジョンから生まれてきた。コードで書けないことは語れない、と言って済ましてよい話じゃないと思いますよ。

2019-09-24 21:30:28

...バランスを見出すことが重要であるということの、ひとつの例かと思います。

2019-09-24 21:32:08

「要件定義こそ肝！あとは非属人的に実装するだけ！」、「コードを書くことこそ設計！コード書けない奴が要件定義するな！」こういうコドモじみた二分法こそ、まっとうな設計＝デザインから、もっとも遠い所にあるような気がします。

2019-09-24 21:35:57

Kaz@🇦🇪ドバイのDX経営総合代理店＆炎上プロジェクトの火消し屋 @Victoria_Peak_

これ。この中間にモデリングやデザインやらを織り込んで流動的に行き来して開発する。 twitter.com/sugimoto_kei/s…

2019-09-24 21:38:53