Q&A
>立場を明確にすることによって何を伝えたいのか
つまり、インターフェースとか抽象クラスとかを学ぶ際に、わかりやすいようにあえて「2種類の立場がいる」と記載されていると思うんです。しかし、（私が疑問に思っていることは）実際の開発現場には「立場1」とか「立場2」とかは実際に存在するんですか？ということです。
JAVAのオブジェクト指向を勉強・練習している者です。エンジニアとは関係ないような質問をしてすいませんが、
「スッキリわかるJava入門 第2版 (スッキリシリーズ) 」の（P445～P446）「（抽象クラスやインターフェースを学ぶ際に）新しい立場で考える」にて
高度な継承（つまり抽象クラスやインターフェース）を使うときの**「立場」が今までの「立場」とは全く違う**ということを意識せず学習を始めてしまうからなのです。
と書かれており、その立場には2種類の開発者がいて
立場1:現在、目の前のプログラム開発に必要なクラスを作る開発者（既存のクラスを継承し子クラスを作る）
立場2:未来に備え、別の開発者が将来利用するであろうクラスを準備しておく開発者（親クラスとなるクラスを作っておく）
と書かれており、さらに、
異なる「立場」で活躍する2種類の開発者がいることがわかります。
この章の内容をスムーズに理解するためにはこの2つの立場の存在を明確に意識・区別できるかがポイントです。
とこの書籍には書いておりますが、そもそも「立場1」はなんとなく話がわかるのですが、「立場2」の人は、実際に開発現場とかにいるんですか？
この書籍を読んでみると、（インターフェースとか抽象クラスとか）わかりやすいようにあえて「2種類の立場がいる」と記載されているように感じます。
つまり、「立場1」に該当する人は
・「一人で開発する人」
・「一度作って終わる（作った後一切変更をしない）アプリケーションの開発者」
・「レイヤ化（MVC等）する必要のないアプリケーションの開発者」
これらが該当すると思いますが、「立場2」に該当する人が思いつかないんです。
（例えばプロジェクトリーダーとか）
なんか私自身勘違いしているように見えますが、「立場2」に該当する人ってどんな人でしょうか？
回答5件
0
こんにちは。
正確ではないですが、ざっくり説明すると下記です。
立場１：アプリケーション・プログラムを開発する人達
立場２：ミドルウェアや汎用ライブラリを開発する人達
立場１の人達は、より「多くの人」が求められます。学習に時間がかかると新しく人材を投入できるまでに時間がかかるため望ましくなく、比較的学習が容易なスキルしか求められません。
立場２の人達は、１つのライブラリを多くの立場１の人が使うので人数は少なくてもOKですが、より言語機能の深い部分（習得が難しい部分）を使いこなせるスキルが必要になるケースが多いです。
抽象クラスやインターフェースは、習得が難しい部分として分類されていると言うことですね。この見解には私も賛成です。
投稿2017/04/05 02:55
総合スコア23272
0
二つのモジュールA,Bを二人の開発者で分担して開発するとします。AはBを呼び出す作りです。
Bが完成しないとAを開発しようにもコンパイルが通らないというのでは分担開発する意味が薄れます。B開発が終わるのをA担当者は待たないといけなくなるので。
そしたら、先にInterfaceBを定義してしまいましょう。A担当者はInterfaceBを呼び出すようにプログラミングすればいいですし、B担当者はInterfaceBの実装クラスを書き進めればよい、となります。並行開発ができるようになりました。
この場合Interfaceを書くのはどの立場の人か？ わりと誰でも良くて、A担当者とB担当者が話し合いながらメソッド構成を決めつつ書き下ろしていってもいいですしB担当者が一人でちゃちゃっと書いちゃうケースもあるでしょうし、A、B両担当者に仕事を振る上位エンジニアがinterfaceを書いて与えることで仕事内容を示すというやり方も有り得ます。
大事なのはどの立場の人が書くかではなく実装を分担するのに先だって定義する点である、と。
投稿2017/04/05 04:22
総合スコア5568
0
スッキリしない話ですね。
立場は明確に分かれないと思います。
たとえば、その時必要なクラスを作ったとします。
しかし、そのクラスはその時の状況に依存しすぎているので、リファクタリングしてもう少し一般的な親クラスを作ったとします。この人はどっちの立場も兼ねると思います。
これだけではその本が何を言いたいのかわかりません。
立場を明確にすることによって何を伝えたいのか、そのあたりを読んでみてください。
投稿2017/04/05 02:10
総合スコア28660
どこかにインターフェースと抽象クラス設計専門の人は存在するんじゃないですか？
いたとしてもいなかったとしてもどうでもいい話だとは思いますが。
(どうでもいいというのは、クラスの設計を教えるにあたってそれが何の助けにもならないという意味です)
ほとんどの人は「インターフェースと抽象クラスの設計<も>する」だと思います。
すべてのクラスがウォーターフォールモデルで設計されているわけではありません。
私は存在すると思います。
それが、一人なのか、二人なのか、三人以上なのかは不問だと思います。
・「目の前のプログラム」は「立場1」になって
・「未来に備え」は「立場2」になって
著者は、そういう意識で本書を読んで下さい。といって言いたいのではないのでしょうか？
0
ベストアンサー
立場1
- メリット：今必要な機能を作れる
- デメリット：負の遺産が増える
立場2
- メリット：負の遺産を返す事ができる
- デメリット：仕分ける為のコード量が増える、実装に遠のく
SIerの世界では、こんな風に分けられてるのだと想像します。
- PGと呼ばれる人種が立場1
- SEと呼ばれる人種が立場2
しかし、実際問題、立場1しか出来ないのはド素人でしょう。
両方やれってのが、実際の開発現場でエンジニアに求められるべき能力です。
実際の開発現場には「今動けばそれで十分」と考えるエンジニアが多く、
立場2の視点でディレクトリを切ったりクラスを整理出来るエンジニアが少ない印象はありますね。
投稿2017/04/05 03:25
編集2017/04/07 02:51
総合スコア21158
実際問題、立場2はリファクタリングする為だけに
ディレクトリ構造を変えたり、クラスを変えたりする権限が必要になります。
それなりに権限は必要で自社開発のプロジェクトでなければ厳しいかもしれませんね。
今は立場1しか出来なくても、立場2の考え方の練習はすべきだと思いますね。
権限が無くても上司や先輩に相談したり意見が言えるわけですしね。
こういった視点がある人は伸びますし、視点がない人は延々とその場しのぎの負の遺産を増やす人間でしかありません。
すいません。「負の遺産」とは何なんでしょうか？ バグ等の不具合のことでしょうか？
Javaはオブジェクト指向言語ですが、
最初のmainの中でforやif文だけを繋げておらーって全部書く事も可能ですよね。
この状態でデバッグやテスト工程まで全て終わって、バグ等の不具合を全て取り除きました。
しかし保守や改修がとても困難で、誰も触れない糞システムとなってしまいます。
上のは流石に極端な例ですが、ちょっと不具合を修正するのに既存のコードに条件文を幾つか付け足して対応…を繰り返すとすぐに例外対処用if文だらけの糞コードになります。
「有るべき状態に整理されていないシステム及びソースコード」を指して、「レガシーコード」や「負の遺産」と呼びます。
仕事ってのは納期が設定されているのが一般的なので、
プログラミングも時間との勝負という側面があります。
よって立場1の視点に寄る為、立場2が追いやられるケースが多いのです。
連続してすいません。立場2の「メリット：仕分ける為のコード量が増える、実装に遠のく」と書かれているのですが、
1.「仕分ける為のコード量が増える」っていうのは「共通部分探して、それを別に作るのにコードの量が増える」という解釈でよろしいでしょうか？
2.「実装に遠のく」というのは「共通部分探して、それを別に作る」のに時間がかかるという解釈でよろしいのでしょうか？
よろしくお願いします。
その通りです。
- 共通部分をまとめると、純粋にフォルダ、ファイル、コードの行数が増える
既存コードの重複箇所を削除しつつ動作に影響が出ない事をテストするのも立派なコストですよね
- 整理出来た状態を思い描くために頭の中で試行錯誤する
例えば1クラス1ファイルで管理しているなら、扱うファイルは増えるでしょう。
共通部分を抜き出して新しく作った抽象クラスは、依存している子クラスから見て同じディレクトリにあるのが適切でしょうか？
これはその場その場でどうするべきかは考える必要があります。
理解できない無駄な仕分けなら始めからしないほうがマシです。
ワンルームのマンションに何十個の本棚をぶち込んでも本を管理出来ないのと同じで、
必要最小限で綺麗に収める事が重要です。
なので、有るべき形に上手く収まるように考え抜いて考え抜いて、
ようやく納得の行くフォルダ名・ファイル名・クラス名になるのです。
これはどうしても時間やコストが掛かる作業になります。
ただ、これをしておくと、後々の作業が楽になるので空き時間で是非やっておくべきだと思いますね。
すいません。今さらになって気づいたのですが、
立場2のところの
メリット：仕分ける為のコード量が増える、実装に遠のく
デメリット：負の遺産を返す事ができる
↑メリットとデメリットの内容が逆になっていませんか？
正しくは
メリット：負の遺産を返す事ができる
デメリット：仕分ける為のコード量が増える、実装に遠のく
↑こっちの方が正しいと思うのですが・・・
ありがとうございます！
確かにそうですね。修正しました。
0
プロジェクト固有のフレームワークの開発者じゃないんでしょうか？
投稿2017/04/05 02:50
総合スコア559
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。