staticおじさんに再利用の有効性をわかってもらうには？

Ryo Asai @ryoasai74

@kazumi007 分割統治という考え方はコピペによって実践されています。たとえば、銘柄の種別ごとにプロジェクトがコピーされて作成されている。

Ryo Asai @ryoasai74

@ebc_2in2crc @kazumi007 そう、だからなんでもやみくもに共有すればよいというものではない。staticおじさんの主張も一理あるところがあるのです。安定依存の原則（SDP）を守るアーキテクチャが重要ですね。

Ryo Asai @ryoasai74

そういって、いろいろ考えだすと、結局レイヤ化とか依存関係逆転（DIP）とかオブジェクト指向のアーキテクチャ設計の本質的な話になってしまうのですよね。もちろん、再利用のためのデザパタというのもある。再利用も考えてみると奥が深いなあと思います。

kazumi007 @kazumi007

@ebc_2in2crc 単純に考えてしまうと、staticということは、コンテキストを考えることを放棄してしまってるように感じますが、考えすぎですかね。

tt4cs @tt4cs

@ryoasai74 わたしはSIerじゃないので勘違いかもしれませんが、総原価（実態は人月？）に基づいて価格が決まるという前提を需要者も供給者も共有してしまった以上、供給者としては総原価を下げる（≒案件ごとの売り上げを下げる？）努力をしづらいという可能性はないですか？

Ryo Asai @ryoasai74

@kazumi007 @ebc_2in2crc staticということは、少なくともポリモーフィズムのない世界なので呼び出し元と共有先は一つに結合されるということですね。つまり、抽象度ゼロの世界。この場合、utilとか数学ライブラリ以外共有すると不安定なことになるのがミソかな。

GLAD!! @glad2121

SOA って OO というより、構造化的発想だと思う。SOA の文脈で OO を語られると違和感を感じる。SOA や構造化は機能の共通化は行うけれどどちらかというとステートレス。OO は状態を持ったオブジェクトがリッチに振る舞うイメージ。良し悪しの議論はとりあえず置いておいて。

Ryo Asai @ryoasai74

つまり、共有先に手が加わると影響が全呼び出し元に伝搬してしまうので、ちょっとでも変更される可能性のあるものは共有できないということになってしまう。そこで、staticでないJavaの場合、インターフェースの利用がカギになります。

🥔えび🦐➕️🍞➕️🔥➡️🍤 @ebc_2in2crc

@kazumi007 おっしゃるとおりですね…うへぇ(；´Д｀)

kentaro714 @kentaro714

@ryoasai74 自分は結局そこでもビジネスモデルと人の問題に突き当たりました。開発時には高スキルな人なんてそうそう集まらないし、保守時には開発時には参加していない、低スキルな人を充てないとペイしない。それでもその設計はできるのか、役に立つのかと言われまして。前提が…。

t_yano @t_yano

「なぜ再利用が有効か」を、わざわざ説明しなくちゃいけないのは辛そうだ

Ryo Asai @ryoasai74

@glad2121 SOAは構造化的側面もありますが、サービスにはDBの状態更新などべき等でない操作も含まれますし、IFと実装が切り離されているためポリモーフィックに呼び出されるという側面もある。広い意味でサービスはファサードのような特殊なオブジェクトととらえた方がしっくりきます

Ryo Asai @ryoasai74

@t_yano これを考えてみるのは、結構いい勉強になるという考え方もできますねw

みよひで画伯 @miyohide

再利用の有効性なんて自明だと思ってたんだが、それを説明せんとあかんっていうのは何か前提が全然違うんだろうか。

みよひで画伯 @miyohide

COBOLだってcopy句って仕組みあるし、コピペ万歳って訳やないと思うんだけど。

GLAD!! @glad2121

@ryoasai74 C言語で実装しても DB 更新があれば同じことだし、ふつう .h と .c に分けて実装するから、リンク時に実装を切り替えることも可能。ポリモフィックって、運用時にサービスの実装を動的に切り替えることはあまりないと思います。

VM持田 @mike_neck

Javaのプログラマーが会話をするときCOBOLが分かっていないとCOBOLの人が何を嫌っているのかがわからないし、COBOLのプログラマーがJavaを分かっていないと何故Interfaceが美味しいとかがわからないのだろうな。オレCOBOL知らないけど…orz

GLAD!! @glad2121

Agile 開発には高スキルな人材が必要とか、お客様や上司が無理解／無能だとか言ってるうちは Agile 開発なんてできないと思う。ホントに低レベルな人は別として、普通の人にちゃんと理解してもらって（相手の意見も尊重して）一緒に取り組んでいく姿勢でないと。

Ktz @ktz_alias

@ryoasai74 第一に部品化。ただの関数の集合ではなく、状態を管理できるようにすることが大事。第二にコピペヘルの抑制。そしてデバックを容易にする事。ってとこじゃないの？

Tadayoshi Sato / 佐藤 匡剛 @tadayosi

@glad2121 @ryoasai74 概ねGLADさんに同意。SOAが扱うようなエンタープライズのレベルになると、OOのテクニック（継承、多相性、etc.）は細かすぎるように思います。

Ryo Asai @ryoasai74

@tadayosi @glad2121 僕がいいたいことは、SOAではインターフェースによって実装が抽象化されるという点ですね。staticおじさんにはその発想はないはずです。その点において、ポリモーフィックであるし、サービスは究極のレイトバインドと言えると思うのです。

Ryo Asai @ryoasai74

つまり、デザパタなどOOのテクニックではないが、インターフェイスと実装の分離など、staticおじさんがサービスを理解するためには、やはり乗り越えなくてはならない壁があると思うのです。

HARADA Kiro @haradakiro

@tadayosi Kay流 の OO は、SOA と相性いいと思いますけどね。

GLAD!! @glad2121

@ryoasai74 @tadayosi 機能やサービスの共通化を理解してもらいたいのなら構造化の文脈で十分なんじゃないですか？ そこでポリモフィックとか言いだすから話が返ってややこしくなる。あと、自分と意見の違う人にレッテル貼って dis るのいいかげんにやめません？

🥔えび🦐➕️🍞➕️🔥➡️🍤 @ebc_2in2crc

今まで努力せず楽してきたんだから壁が高く厚いのは当然かも。 RT @ryoasai74: つまり、デザパタなどOOのテクニックではないが、インターフェイスと実装の分離など、staticおじさんがサービスを理解するためには、やはり乗り越えなくてはならない壁があると思うのです。