質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.53%

  • オブジェクト指向

    284questions

    オブジェクト指向プログラミング(Object-oriented programming;OOP)は「オブジェクト」を使用するプログラミングの概念です。オブジェクト指向プログラムは、カプセル化(情報隠蔽)とポリモーフィズム(多態性)で構成されています。

  • オブジェクト

    91questions

    オブジェクト指向において、データとメソッドの集合をオブジェクト(Object)と呼びます。

「抽象クラス」や「インターフェース」を開発する側(利用する側ではない)に立つ人ってどんな人が該当するんですか?

解決済

回答 5

投稿

  • 評価
  • クリップ 2
  • VIEW 487

mr0237

score 143

JAVAのオブジェクト指向を勉強・練習している者です。エンジニアとは関係ないような質問をしてすいませんが、
「スッキリわかるJava入門 第2版 (スッキリシリーズ) 」の(P445~P446)「(抽象クラスやインターフェースを学ぶ際に)新しい立場で考える」にて

高度な継承(つまり抽象クラスインターフェース)を使うときの「立場」が今までの「立場」とは全く違うということを意識せず学習を始めてしまうからなのです。

と書かれており、その立場には2種類の開発者がいて

立場1:現在、目の前のプログラム開発に必要なクラスを作る開発者(既存のクラスを継承し子クラスを作る

立場2:未来に備え、別の開発者が将来利用するであろうクラスを準備しておく開発者(親クラスとなるクラスを作っておく

と書かれており、さらに、

異なる「立場」で活躍する2種類の開発者がいることがわかります。
この章の内容をスムーズに理解するためにはこの2つの立場の存在を明確に意識・区別できるかがポイントです。

とこの書籍には書いておりますが、そもそも「立場1」はなんとなく話がわかるのですが、「立場2」の人は、実際に開発現場とかにいるんですか?

この書籍を読んでみると、(インターフェースとか抽象クラスとか)わかりやすいようにあえて「2種類の立場がいる」と記載されているように感じます。

つまり、「立場1」に該当する人

・「一人で開発する人」
・「一度作って終わる(作った後一切変更をしない)アプリケーションの開発者」
・「レイヤ化(MVC等)する必要のないアプリケーションの開発者」

これらが該当すると思いますが、「立場2」に該当する人が思いつかないんです。
(例えばプロジェクトリーダーとか)

なんか私自身勘違いしているように見えますが、「立場2」に該当する人ってどんな人でしょうか?

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 5

+4

こんにちは。

正確ではないですが、ざっくり説明すると下記です。

立場1:アプリケーション・プログラムを開発する人達
立場2:ミドルウェアや汎用ライブラリを開発する人達

立場1の人達は、より「多くの人」が求められます。学習に時間がかかると新しく人材を投入できるまでに時間がかかるため望ましくなく、比較的学習が容易なスキルしか求められません。

立場2の人達は、1つのライブラリを多くの立場1の人が使うので人数は少なくてもOKですが、より言語機能の深い部分(習得が難しい部分)を使いこなせるスキルが必要になるケースが多いです。
抽象クラスやインターフェースは、習得が難しい部分として分類されていると言うことですね。この見解には私も賛成です。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+2

二つのモジュールA,Bを二人の開発者で分担して開発するとします。AはBを呼び出す作りです。
Bが完成しないとAを開発しようにもコンパイルが通らないというのでは分担開発する意味が薄れます。B開発が終わるのをA担当者は待たないといけなくなるので。

そしたら、先にInterfaceBを定義してしまいましょう。A担当者はInterfaceBを呼び出すようにプログラミングすればいいですし、B担当者はInterfaceBの実装クラスを書き進めればよい、となります。並行開発ができるようになりました。

この場合Interfaceを書くのはどの立場の人か? わりと誰でも良くて、A担当者とB担当者が話し合いながらメソッド構成を決めつつ書き下ろしていってもいいですしB担当者が一人でちゃちゃっと書いちゃうケースもあるでしょうし、A、B両担当者に仕事を振る上位エンジニアがinterfaceを書いて与えることで仕事内容を示すというやり方も有り得ます。

大事なのはどの立場の人が書くかではなく実装を分担するのに先だって定義する点である、と。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+1

スッキリしない話ですね。
立場は明確に分かれないと思います。

たとえば、その時必要なクラスを作ったとします。
しかし、そのクラスはその時の状況に依存しすぎているので、リファクタリングしてもう少し一般的な親クラスを作ったとします。この人はどっちの立場も兼ねると思います。

これだけではその本が何を言いたいのかわかりません。
立場を明確にすることによって何を伝えたいのか、そのあたりを読んでみてください。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/04/05 11:16

    >立場を明確にすることによって何を伝えたいのか
    つまり、インターフェースとか抽象クラスとかを学ぶ際に、わかりやすいようにあえて「2種類の立場がいる」と記載されていると思うんです。しかし、(私が疑問に思っていることは)実際の開発現場には「立場1」とか「立場2」とかは実際に存在するんですか?ということです。

    キャンセル

  • 2017/04/05 11:26 編集

    どこかにインターフェースと抽象クラス設計専門の人は存在するんじゃないですか?
    いたとしてもいなかったとしてもどうでもいい話だとは思いますが。
    (どうでもいいというのは、クラスの設計を教えるにあたってそれが何の助けにもならないという意味です)

    ほとんどの人は「インターフェースと抽象クラスの設計<も>する」だと思います。
    すべてのクラスがウォーターフォールモデルで設計されているわけではありません。

    キャンセル

  • 2017/04/05 11:32

    私は存在すると思います。
    それが、一人なのか、二人なのか、三人以上なのかは不問だと思います。
    ・「目の前のプログラム」は「立場1」になって
    ・「未来に備え」は「立場2」になって
    著者は、そういう意識で本書を読んで下さい。といって言いたいのではないのでしょうか?

    キャンセル

checkベストアンサー

0

立場1

  • メリット:今必要な機能を作れる
  • デメリット:負の遺産が増える

立場2

  • メリット:負の遺産を返す事ができる
  • デメリット:仕分ける為のコード量が増える、実装に遠のく

SIerの世界では、こんな風に分けられてるのだと想像します。

  • PGと呼ばれる人種が立場1
  • SEと呼ばれる人種が立場2

しかし、実際問題、立場1しか出来ないのはド素人でしょう。
両方やれってのが、実際の開発現場でエンジニアに求められるべき能力です。

実際の開発現場には「今動けばそれで十分」と考えるエンジニアが多く、
立場2の視点でディレクトリを切ったりクラスを整理出来るエンジニアが少ない印象はありますね。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/04/05 12:27

    実際問題、立場2はリファクタリングする為だけに
    ディレクトリ構造を変えたり、クラスを変えたりする権限が必要になります。
    それなりに権限は必要で自社開発のプロジェクトでなければ厳しいかもしれませんね。

    キャンセル

  • 2017/04/05 12:31

    今は立場1しか出来なくても、立場2の考え方の練習はすべきだと思いますね。
    権限が無くても上司や先輩に相談したり意見が言えるわけですしね。
    こういった視点がある人は伸びますし、視点がない人は延々とその場しのぎの負の遺産を増やす人間でしかありません。

    キャンセル

  • 2017/04/06 10:57

    すいません。「負の遺産」とは何なんでしょうか? バグ等の不具合のことでしょうか?

    キャンセル

  • 2017/04/06 17:16

    Javaはオブジェクト指向言語ですが、
    最初のmainの中でforやif文だけを繋げておらーって全部書く事も可能ですよね。
    この状態でデバッグやテスト工程まで全て終わって、バグ等の不具合を全て取り除きました。

    しかし保守や改修がとても困難で、誰も触れない糞システムとなってしまいます。
    上のは流石に極端な例ですが、ちょっと不具合を修正するのに既存のコードに条件文を幾つか付け足して対応…を繰り返すとすぐに例外対処用if文だらけの糞コードになります。
    「有るべき状態に整理されていないシステム及びソースコード」を指して、「レガシーコード」や「負の遺産」と呼びます。

    仕事ってのは納期が設定されているのが一般的なので、
    プログラミングも時間との勝負という側面があります。
    よって立場1の視点に寄る為、立場2が追いやられるケースが多いのです。

    キャンセル

  • 2017/04/06 17:24

    連続してすいません。立場2の「メリット:仕分ける為のコード量が増える、実装に遠のく」と書かれているのですが、

    1.「仕分ける為のコード量が増える」っていうのは「共通部分探して、それを別に作るのにコードの量が増える」という解釈でよろしいでしょうか?

    2.「実装に遠のく」というのは「共通部分探して、それを別に作る」のに時間がかかるという解釈でよろしいのでしょうか?

    よろしくお願いします。

    キャンセル

  • 2017/04/06 19:38

    その通りです。
    - 共通部分をまとめると、純粋にフォルダ、ファイル、コードの行数が増える
     既存コードの重複箇所を削除しつつ動作に影響が出ない事をテストするのも立派なコストですよね
    - 整理出来た状態を思い描くために頭の中で試行錯誤する

    例えば1クラス1ファイルで管理しているなら、扱うファイルは増えるでしょう。
    共通部分を抜き出して新しく作った抽象クラスは、依存している子クラスから見て同じディレクトリにあるのが適切でしょうか?
    これはその場その場でどうするべきかは考える必要があります。

    理解できない無駄な仕分けなら始めからしないほうがマシです。
    ワンルームのマンションに何十個の本棚をぶち込んでも本を管理出来ないのと同じで、
    必要最小限で綺麗に収める事が重要です。

    なので、有るべき形に上手く収まるように考え抜いて考え抜いて、
    ようやく納得の行くフォルダ名・ファイル名・クラス名になるのです。
    これはどうしても時間やコストが掛かる作業になります。

    ただ、これをしておくと、後々の作業が楽になるので空き時間で是非やっておくべきだと思いますね。

    キャンセル

  • 2017/04/07 11:36

    すいません。今さらになって気づいたのですが、

    立場2のところの
    メリット:仕分ける為のコード量が増える、実装に遠のく
    デメリット:負の遺産を返す事ができる
    ↑メリットとデメリットの内容が逆になっていませんか?

    正しくは
    メリット:負の遺産を返す事ができる
    デメリット:仕分ける為のコード量が増える、実装に遠のく
    ↑こっちの方が正しいと思うのですが・・・



    キャンセル

  • 2017/04/07 11:51

    ありがとうございます!
    確かにそうですね。修正しました。

    キャンセル

0

プロジェクト固有のフレームワークの開発者じゃないんでしょうか?

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.53%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る

  • オブジェクト指向

    284questions

    オブジェクト指向プログラミング(Object-oriented programming;OOP)は「オブジェクト」を使用するプログラミングの概念です。オブジェクト指向プログラムは、カプセル化(情報隠蔽)とポリモーフィズム(多態性)で構成されています。

  • オブジェクト

    91questions

    オブジェクト指向において、データとメソッドの集合をオブジェクト(Object)と呼びます。