回答編集履歴
2
文章のリファクタリング
    
        answer	
    CHANGED
    
    | @@ -1,11 +1,11 @@ | |
| 1 1 | 
             
            > 本質的に処理を追いにくくなるものなのでしょうか
         | 
| 2 2 |  | 
| 3 3 | 
             
            オブジェクトの本質は、ロジックを責務で細分化し、ファイルやディレクトリで分けて管理することにあります。
         | 
| 4 | 
            -
            システムが肥大化した結果、1万行を超えるようなものに成長 | 
| 4 | 
            +
            システムが肥大化した結果、1万行を超えるようなものに成長した場合どんな管理をしても立ちいかなくなります。
         | 
| 5 5 | 
             
            オブジェクト指向は**一定数のコストを支払う代わりにファイルの分割をロジカルに行う、ポピュラーな解決方法の一つ**と言い換えても良いでしょう。
         | 
| 6 6 |  | 
| 7 7 | 
             
            例題はあえて冗長に描いているように見えますが、
         | 
| 8 | 
            -
            実戦では適切なディレクトリ構造だと思いますし、メンテされてい | 
| 8 | 
            +
            実戦では適切なディレクトリ構造だと思いますし、メンテされている前提ですがかなり良いプロジェクトだと思います。
         | 
| 9 9 | 
             
            読み方はこんな感じですかね?
         | 
| 10 10 |  | 
| 11 11 | 
             
            1:doPrint()で問題(※)が起きていて、それはcreateRandomHage()で作られて、さらにそれはPrintFactoryで作られた、とさかのぼる。 
         | 
| @@ -20,6 +20,9 @@ | |
| 20 20 | 
             
            近年、別ルートで問題解決する関数型プログラミングや関数型言語が注目されています。
         | 
| 21 21 | 
             
            (Scala、Haskell、F#、Elixirが有名ですかね)
         | 
| 22 22 |  | 
| 23 | 
            +
            メッセージ指向でやり取りするオブジェクト指向は時間経過と状態に強く左右されるので、
         | 
| 24 | 
            +
            開発者の頭のメモリを食う量が半端じゃないのがデメリットですかね?
         | 
| 25 | 
            +
             | 
| 23 26 | 
             
            ただし、主流のオブジェクト指向でもそれなりに何とかやってこれていますので、
         | 
| 24 27 | 
             
            暫くはオブジェクト指向の天下は続きそうですね。
         | 
| 25 28 | 
             
            デザパタの勉強頑張ってください。
         | 
| @@ -28,17 +31,16 @@ | |
| 28 31 |  | 
| 29 32 | 
             
            > classはinterfaceに依存するように作られているため
         | 
| 30 33 |  | 
| 31 | 
            -
            認識が逆です。
         | 
| 32 | 
            -
            自分勝手でフリーダムな動作が出来るクラス達の手綱を握るために制約を課すための機能です。
         | 
| 34 | 
            +
            これは自分勝手でフリーダムな動作が出来るクラス達の手綱を握るために制約を課すための機能です。
         | 
| 33 | 
            -
             | 
| 35 | 
            +
            なのでどちらかと言えばポジティブなものです。
         | 
| 34 36 | 
             
            下記は使い分けの一例です。
         | 
| 35 37 |  | 
| 36 | 
            -
            - 継承: 一つのクラスをロールモデルとして採用して | 
| 38 | 
            +
            - 継承: 一つのクラスをロールモデルとして採用して子クラスは特化させる
         | 
| 37 39 | 
             
            - 抽象クラス: 既存のクラスのメソッドをまとめたい、だから一部の同じ動きするメソッドは共通化しておく、でもインスタンスとして動作はできない
         | 
| 38 40 | 
             
            - インターフェース: お前らのクラスは動きがバラバラ過ぎでロジックの共通化は無理!メソッドの保証だけするから、後は勝手にやってちょうだい
         | 
| 39 41 |  | 
| 40 42 | 
             
            実質、下に行けば行くほど単純に出来る事が減ります。
         | 
| 41 | 
            -
            一見不便でしかないのですが、継承は全ての親の存在を気にし続ける | 
| 43 | 
            +
            一見不便でしかないのですが、継承は全ての親の存在を気にし続ける必要があるので、
         | 
| 42 44 | 
             
            用途によって適切に使い分けるとリーディングが楽になります。
         | 
| 43 45 |  | 
| 44 46 | 
             
            これを知っていると、4の場面で太字のように軌道修正されます。
         | 
1
冒頭のou wo
    
        answer	
    CHANGED
    
    | @@ -1,7 +1,11 @@ | |
| 1 1 | 
             
            > 本質的に処理を追いにくくなるものなのでしょうか
         | 
| 2 2 |  | 
| 3 3 | 
             
            オブジェクトの本質は、ロジックを責務で細分化し、ファイルやディレクトリで分けて管理することにあります。
         | 
| 4 | 
            +
            システムが肥大化した結果、1万行を超えるようなものに成長いてしまったらどんな管理をしても立ちいかなくなります。
         | 
| 5 | 
            +
            オブジェクト指向は**一定数のコストを支払う代わりにファイルの分割をロジカルに行う、ポピュラーな解決方法の一つ**と言い換えても良いでしょう。
         | 
| 6 | 
            +
             | 
| 7 | 
            +
            例題はあえて冗長に描いているように見えますが、
         | 
| 4 | 
            -
             | 
| 8 | 
            +
            実戦では適切なディレクトリ構造だと思いますし、メンテされていれかなり良いプロジェクトだ)と思います。
         | 
| 5 9 | 
             
            読み方はこんな感じですかね?
         | 
| 6 10 |  | 
| 7 11 | 
             
            1:doPrint()で問題(※)が起きていて、それはcreateRandomHage()で作られて、さらにそれはPrintFactoryで作られた、とさかのぼる。 
         | 
