オブジェクト指向の呪いと、その避け方 - mizchi's blog
このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(
近代的タスクシステムの構築 - やねうらおブログ(移転しました)
いつか本に書こうと思っていたが、多忙につき、本を書くどころではない状況なので、内容が風化する前に誰かの参考になればと要点だけでも書き残しておく。 いまの視点(2009年)で見たときに拙著(ASIN:4798006033)にて不足している部分を補足するためのものである。この本自体はすでに絶版になりプレミア価格で取引されているが、もし参考文献を探しているなら、出来ればこの本は買わずに次に出すゲームプログラミング本のほう参考にして欲しい。 ■ タスクシステムの定義 ここで言う「タスクシステム」とは、ゲームプログラミングの教科書に出てくるものである。(cf. 「本格的なシューティングゲームを実現するタスクシステム」 http://codezine.jp/article/detail/297?p=1 ) 「タスクシステム」は初期のビデオゲームで、V-SYNCをイベントトリガとして画面を描画するときに
タスクシステムにコルーチンを組み込むには
型を継承する以上はis-aであるべき ではコルーチンを使おうが何だろうが、java.lang.Iterable(C#ならSystem.Collections.Generic.IEnumerator)であるからには その型としての機能性を全うすべきだと主張しました。 では、本題のタスクシステムでコルーチンを扱うケースでどのように設計するべきかを考えてみましょう。 そもそもタスクシステムって？ ゲームにオブジェクト指向の考えを部分的に取り入れたのがタスクシステムと言えるでしょう。 タスクシステムでやっていることは、 キャラクタを表現する構造体を作る その構造体には関数ポインタによって挙動の違いを表現できる機能性を持たせる 構造体は双方向リストなどの構造で複数のデータを管理できるようにする といったところです。 これは、非オブジェクト指向であるC言語では「システム」と称するだけのものかもしれませ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
