（・Ａ・）「OOPできますか？」
（＾ω＾）「はい」
数日後
（＾ω＾）「できた」
class God {
void main(){
if(条件1){
//
//数百〜数千行のコード
//
}
else{
//
//数百〜数千行のコード↑でやってることとほとんど同じ
//
}
}
}（・Ａ・）「仕様追加で。xxの時はXXしてyyの場合はYY、それ以外はZZ」
（＾ω＾）「はい」
数日後
（＾ω＾）「できた」
class God {
void main(){
if(条件1){
//
//数百〜数千行のコード
//
//仕様追加で分岐必要な部分
switch (jouken){
case xx:
//条件xxでの処理
case yy:
//条件yyでの処理
default:
//それ以外
}
//
//数百〜数千行のコード
//
//仕様追加で分岐必要な部分
switch (jouken){
case xx:
//条件xxでの処理
case yy:
//条件yyでの処理
default:
//それ以外
}
}
else{
//
//数百〜数千行のコード↑でやってることとほとんど同じ
//
switch (hoge){
//以下略
}
}
}
}（・Ａ・）「バグってる」
（＾ω＾;```「はい」
...
上記のように、OOP可能な言語で書く・書けることはOOPができることとイコールではないです。
OOPのことはとりあえず置いといて、かように生み出されたスパゲッティコードは早晩破綻します。 理由は簡単で変更に弱い構造になってしまっているから。
変更の内訳はバグの修正だけとは限らず、要求仕様の変更、依存しているプラットフォームの変更等々、様々でしょう。
それらに対応できないあるいは対応するのに死ぬほど時間がかかる＝使えないシステム とレッテルを貼られてしまうのも時間の問題と思われます。
話がそれた。
OO: Object Oriented
OOP: Object Oriented Programming
要求仕様をオブジェクト(データとそれにひもづく操作(メソッド))という概念に落とし込んで設計・プログラミングする、ということになっている。
自分が新人の時はまだOO全盛期で、最初はJavaでプログラミングを勉強して、継承だとか抽象クラスだとか付随する概念も覚えて... で、実務でのプログラミングでは使いこなされている場面を見たことがなくて、という状態だった。
そういう中でデザインパターンを知り、じゃあそれを実際どう使いこなしていけばよいのか、色々試行錯誤していた。
そうこうしている間に関数型言語がバズり、気がついたら自分が使っている言語にも関数型言語由来の機能が取り込まれていたりして..
＼(^o^)／
ぐだぐだ考えていても進まないので..以下は自分のポリシー
- 汚いコードを見つけたらリファクタリングする(リファクタリングだけでまたパターンができてしまうが...)
- OOで出てくる用語に囚われることなく、シンプルなコードを書くように努める(リーダブルコード参照)
- 関数型言語も触ってみる、あるいはOO系言語に取り入れられた関数型言語由来の機能(c#だとlambdaとかlinq to objectとか、javaだとstreamとか？)を積極的に使ってみる
プログラミングあるあるをデザインパターン+OOPでどう解決してくのか、よくわかる
きれいなコード=リーダブルコードの書き方
時間があれば読みたい(自分が)