【綺麗】デザインパターンは美しい！【究極の美】

>>184
そりゃ公開するような独り立ちするクラスならファイルわけるだろうさ。
だがこれは公開しないクラスだぞ？
あるクラスの内部でひっそりと使われるクラスをなんでわざわざ別ファイルに書くよ？

>>185
簡単な、そこだけで使う関数オブジェクトとか普通に定義しまくってるが？
クロージャ感覚だな。関数内で定義したいがそうするとテンプレートに渡せないからムカツクが。

・・・デザインパターンって、設計パターンだよな。

>186
だからバカ。
どこが？ではなくて全文バカ。

>>188
お前は全レスがバカだよなｗ

「あるクラスの内部でひっそりと使われるクラス」や「簡単な、そこだけで使う関数オブジェクト」
の話をしてるのはお前だけだということに気づいたほうがいいぞｗ

クラスが10あったら、そのうちの一個ぐらいは、cppの中に定義されていたり
クラス内クラスだったりすると言いたいのかな？

そういう統計的な話は、全くしていないわけだが

内部クラス沢山作る奴って協調性なさそう。

インターフェイスとかパッケージングとか知らんのか(-_-;

内部クラス＝inner class
インターフェイスとかパッケージングとかは別次元の話

>>192,194
こういうヤツラが構造化言語いじると
関数全部公開モジュールとか作り込むんだろうな。

>>195
うちのプロジェクトでは、hoge.c で static int foo() を定義して、hoge.h で
static int foo(); と宣言している。

まともなプロジェクトでhogeとかfooとか使う奴はパターン以前の問題。
あ、>>196じゃなくてウチの先輩ね。

ヲイヲイ。そこは実際には別の名前に置き換わってるだろ？普通。

・・・ハッ
釣られたか？

>>198

バカだなぁ…。

＞・・・ハッ
＞釣られたか？

↑これがなかったらお前がツリをしたことになってたのに。
なんか一言、保険のための言葉なんか書いちゃって…、チキンハートだな。（笑）

>>196の本質は名前ではなくて static だと思うのだが。

>>200
他のソースから呼び出せない関数ね。
これが分かる椰子はC厨。JAVA厨では指摘できないとこだな。

>>196
何を自慢したいんだ？
それともツッコミ入れちゃってもいいのかな？？

>>200
でわからない人もも一回勉強しなおせ〜

>>202
うちのプロジェクトには「プロトタイプ宣言は .h に書く」というコーディング規約が
いにしえよりあって、もうどうしようもなくなっている。

くだらない規約は廃せ。
英雄になれるぞ。

定期的に改訂しなければ「規約」の名に値しない
のであるが

ヴィバ！　デザインパターン！

>>203
プロトタイプ宣言は他のモジュールというかソースから参照するためのものを
書くものではないのか？違うのか？
# あ、〜.h に書くプロトタイプ宣言の事ね。

>>207
次の現場入る前にstatic関数について調べておけ

>>208
だーかーらーたとえ規約でプロトタイプ宣言は〜.hに書くことになってても、
staticなんかは普通適用外でしょ？って言いたかったんだが…

なんでstaticについて知らんことになるんだ？

【GoF】デザインパターン 3＠プログラム板
http://pc5.2ch.net/test/read.cgi/tech/1095388499/l50

とりあえず>>203の会社はバカ会社のひとつということで

プロトタイプといえば
GoFデザインパターンの一種ProtoTypeパターンのことだな

デザパタスレっていつも厨ばかりだな。

じゃあどんなスレが厨が少ないスレだというのだ？
そもそも、お前みたいな厨が邪魔をしてばかりいるから
厨ばかりのすれに見えてしまうのだ。
いい加減にしろ

C厨ばかりって意味ではマ板は厨ばかりだけどね

とりあえず下の問題を解いてください(別のスレから拝借)
------------------------------------
次のプログラムは、食事をする人を表現しています。
このプログラムのEatingMan#eat()メソッドは、if〜elseが連続していて長い上に、
新しい種類のFoodクラスを作成する度にコードを付け加える必要があります。
この問題を解決するように、プログラムを書き換えなさい。
なお、すべての食べ物について、その食べ方は1通りしかないものとします。
------------------------------------
class EatingMan{
　　void eat(Food food){
　　　　if(food instanceof Rice){
　　　　　　// お箸を使ってfoodを食べる
　　　　}
　　　　else if(food instanceof Bread){
　　　　　　// 手づかみでfoodを食べる
　　　　}
　　　　else if(food instanceof Steak){
　　　　　　// ナイフとフォークを使ってfoodを食べる
　　　　}
　　}
}
abstract class Food{}
class Rice extends Food{]
class Bread extends Food{}
class Steak extends Food{}

>>216
でも、スレ違いですから。

おれはプログラマー
オブジェクト指向は大得意
パターンだってお手の物
俺が設計すればコードもすっきりだ　って言うじゃない？
でもあんたの会社　4層の下請けの最下層ですから！　残念！
規約でインターフェース作れない　斬り！

ギター侍ネタにはほんとにイライラ
うんざりさせられたここ数ヶ月だったが
218は面白いです。

そうだね。どうせソースコードの中身なんて

会　社　は　評　価　し　て　く　れ　な　い

他人の三倍の速度で作っても、作業を追加されるだけで
給料にはあんまり反映されないしな。
それより上司と喫煙室で仲良くなって、飲み会でお世辞言ってる
方が100倍得になる。

ぱたーん

>>216の様に解くのって、実に自然だよな。
「食べ方」って言うのは、「食べ物」毎にあるんじゃない。
食べ物と、食べる人の「狭間」に存在するんだ。

そして、その狭間に存在する「食べ方」の内、どれを選択するのかは、
完全に食べる人にのみ、依存するのだ。

interface EatingMethod {
    void perform(EatingMan man, Food food);
}
class ChopstickMethod implements EatingMethod {
    public void perform(EatingMan man, Food food) {
        System.out.println(man + " はお箸を使って " + food + " を食べる");
    }
}
class HandMethod implements EatingMethod {
    public void perform(EatingMan man, Food food) {
        System.out.println(man + " は手づかみで " + food + " を食べる");
    }
}
class KnifeForkMethod implements EatingMethod {
    public void perform(EatingMan man, Food food) {
        System.out.println(man + " はナイフとフォークを使って " + food + " を食べる");
    }
}
class MethodUnknown implements EatingMethod {
    public void perform(EatingMan man, Food food) {
        System.out.println(man + " は " + food + " の食べ方が分からない");
    }
}
class EatingMan {
    Map eatingMethods = new HashMap();
    MethodUnknown unknownMethod = new MethodUnknown();
    void eat(Food food) {
        if (food == null) {
            unknownMethod.perform(this, food);
            return;
        }
        Object o = eatingMethods.get(food.getClass());

        EatingMethod method;
        if (o instanceof EatingMethod) {
            method = (EatingMethod) o;
        } else {
            method = unknownMethod;
        }
        method.perform(this, food);
    }
    void teachHowToEat(Class foodClass, EatingMethod method) {
        eatingMethods.put(foodClass, method);
    }
}
public class Main {
    public static void main(String[] args) {
        //誕生
        EatingMan man = new EatingMan();
        //教育
        man.teachHowToEat(Rice.class, new ChopstickMethod());
        man.teachHowToEat(Bread.class, new HandMethod());
        //man.teachHowToEat(Steak.class, new KnifeForkMethod());
        //料理
        Food rice = new Rice();
        Food bread = new Bread();
        Food steak = new Steak();
        //食事
      man.eat(rice);
      man.eat(bread);
      man.eat(steak);
      man.eat((Food) null);
  }

>>216
RatingManに以下のメソッドを追加。
void eat(Map foodMap){
　Iterator iterator = foodMap.iterator();
　Food food;
　while(iterator.hasNext()){
　　food = (Food)iterator.next();
　　food.eat();
　}
}

Foodクラスにabstract void eat()メソッドを追加。
それに従ってFoodのすべてのサブクラスにeat()メソッドを実装させる。
食べ方はif文内書いたものを書く。
これで、クラスを追加するたびにEatingManクラスにif文を追加する必要がなくなる。

必要に応じてwhileステートメント内にif文とbreakを付け加えよ。

Mapにはiterator()メソッドはない。
ここでは、Iterator iterator = foodMap.values().iterator() かな。

と書いてから、そもそもがMapじゃなくてCollectionが来るべきところのような気がしてきた。

STLみたいにキーと値のペアが取り出せるイテレータがあっても
いいのにね。

map.entrySet()
でMap.Entry (KeyとValueのペア)の集合が取れる。

>>223
>>216の
＞なお、すべての食べ物について、その食べ方は1通りしかないものとします。
っていうのは、言い換えると
「食べ方は、食べ物の種類ごとに決められていると考えてください」
っていうことを言いたいんだと思う。

>>230
てことは、>>224-225はオーバースペック？

>>228-229
> STLみたいにキーと値のペアが取り出せるイテレータがあっても
> いいのにね。
Jakarta Commons Collectionsにあるコレクションクラスを使うってのもありかもね

デザインパターンを首尾よく使えない言語は糞

いい本がない

age