■

オブジェクト指向設計実践ガイド

読んでない

筋トレ

20 PushUp 20 KickButtJumpSquats 20 SidePlankObliqueCrunch 20 Dips 20 LowPlankArmReach 6セット

■

オブジェクト指向設計実践ガイド

インターフェースについて学ぶ

class MacBookPro
  def turn_on
    hardware_detect
    farmware_initialize
    bios
  end

  def hardware_detect
    puts 'detect cpu, memory, disk...'
  end

  def farmware_initialize
    puts 'initializing firmware...'
  end

  def bios
    puts 'processing boot sequence...'
  end

end

class Programmer

  def work
    computer = MacBookPro.new
    computer.hardware_detect
    computer.farmware_initialize
    computer.bios

    puts 'start working!'
  end

end

Programmerインスタンスは仕事を始める際にパソコンが必要になる。パソコンの電源を入れないと仕事ができない。だからといって、ProgrammerインスタンスがMacBookProインスタンスの起動処理を全て知っている必要やそれを呼び出す必要はない。むしろそれをProgrammerインスタンスが知っていることは依存性が増すことになってしまう。MacBookProのブートシーケンスにもう１つ処理が追加されてしまった場合、MacBookProクラスだけでなくProgrammerクラスにもその増えたシーケンスを追加しなければならなくなってしまう。その時に必要になるのがインターフェース。この場合であれば、MacBookProクラスはturn_onのみをpublicにして、それ以外はprivateメソッドとすべき。Programmerクラスへの依存性は最小限になる。 インターフェースを考える上での肝は「How」と「What」。この場合、Programmerは「何」がほしいのか？自分の使うパソコンの電源が入って欲しいのだ。電源が入ったパソコンがあれば、あとはProgrammerが勝手に色々してくれる。どうやったらパソコンが起動してくれるのかは知ったことではないし、知っておくべきでもない。「What」を明確にし、それをオブジェクト間のメッセージにして通信させるのが重要となる。そしてその「何」が提供できるかがそのクラスの責任範囲になるため、その責任範囲の提供口としてインターフェースというかpublicなメソッドが出て来る。依存する側、つまりMacBookProクラスのpublicなメソッドを呼ぶProgrammerは、そのインターフェースを受け入れてそれ以上は踏み込まないように、相手の責任を尊重し呼び出すオブジェクトを信頼しながらそのpublicなメソッドを呼び出せるように設計しなければならない。

筋トレ

30 PushUP 30 JumpingSquats 30 LegRaise 30 CrapJack 30 BicycleCrunch 6セット

■

オブジェクト指向設計実践ガイド

読んでる

オブジェクト指向設計実践ガイド　?Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

class MacBookPro
  attr_reader :maker
  def initialize
     @maker = 'Apple'
  end
  def put
     put maker
  end

end

class Programmer
  attr_reader :computer

  def initialize
     @computer = MacBookPro.new
  end
  def machine
    put "I use #{computer_maker} 's PC"
  end
  
  def computer_maker
    computer.maker
  end
end

computer_makerメソッドは冗長な感じもするけど、もしこれをなくしてmachineメソッドの中からcomputer.makerを呼ぶとなると、依存が発生する。ProgrammerクラスというかmachineメソッドはMacBookProクラスのインスタンスがmakerというゲッターを持っていることを知っていなければならない。この例だと1ヶ所しかそのゲッターを呼ぶ場所はないからいいものの、複数箇所から呼んでいるとなると依存性は更に増す。ゲッターの名前を変えることになったら悲惨なことになる。だから冗長とも思えるcomputer_makerメソッドに全てを集める。

こういうのを見てみて思ったのは、クラス設計は対象クラスに徹底的に自分のやってることに責任を持たせなければいけないんだなということ。MacBookProインスタンスがいくらメソッド1つでちゃんとmaker名を返しますよと言っても、いくら簡単にMacBookProインスタンスが処理をこなそうとも、簡単に呼べようとも、直接叩くことはせずに自分のやり方を通して呼び出す。受注者が電話一本で午後イチには納品しますよ！なんていくら軽い事を言っても、いやこっちにはこっちの事情があんねんと言いながら発注元で稟議をかけて社内規定に則った上で発注する、みたいな。

筋トレ

100 JumpingJack 15 Burpee 15 PikePushup 20 JumpSquats 60s HighPlank 60s LowPlank

■

coursera

パイプライン処理、シーリング分析について学ぶ。全部課題をクリアして講義も終わったけど、まだまだ機械学習を活かせそうにはない。

筋トレ

30 LegRaise 30 HighPlankJack 30 KneeTuckCrunch 30 LowPlankArmReach 90s LowPlank

国語

読んでない