ラーメンの製作過程をOOPするスレ

　中
( ´谷｀)ヨロシク

そもそも製作過程を知らない

１の名前欄から「マン」を取る

>>3
見事、完成しましたね。

>>1 は中谷さん。
…
誰だよ。

ラーメン = 職人.ラーメン作る();

カップメンと出前一丁しか作ったこと無い。

class CRaamen:public IRaamen{
protected:
　CFactroy<CYasai> hatake_;
　CFactory<CNiku> noujyou_;
};

わかんねぇ…

class Noodle { }
class RamenNoodle : Noodle { }

まず、分析しろよ、おまいら、、、、

ラーメンの構成要素は何か
スープ、麺、トッピング、どんぶり

スープには何があるか
しょうゆ、みそ、しお、とんこつ

麺には何があるか
細麺、太麺

トッピングには何があるか
チャーシュー、シナチク、ナルト、コーン、もやし、焼き海苔、

どんぶりには何があるか
普通、大盛り

中谷美紀ﾀﾝのスレですねええええええええええええええええええええええ＠＠！！！！


うっぅぅぅうううううううううううううううううううわっほぅぅ！！

とりあえず具材のクラスでもつくってみるか。

まずなると

class @
{
}

めんま
class |

焼き海苔
class ■

煮玉子
class ◎

もやし
class ∬

いけませんね。
それぞれの具に、茹でるインタフェースが実装されてません。

茹でるとは限らないから、下ごしらえインターフェースが必要かな。

ところで>>1の中谷ってだれ？

美紀ﾀﾝ

とりあえず俺は食う係

てかインタフェースとしてはトッピングじゃねーか？
そのサービスの一つに下ごしらえがあると、、、。

interface トッピング
{
　下ごしらえ()
}

ラーメン本体にも下ごしらえはあるだろう

カップにお湯入れて3分待つだけだろ。

>>24 にとっての「ラーメン」は、だろ?

なにげにウケるスレなんだがｗ

>>23
ラーメン本体は、麺、スープにわけて考えるべきだべ。

環境依存にならないように、調理器具も抽象化しようぜ

NoodleFactoryクラスに原材料であるWheatを渡すとか。

惑星環境に依存しないように、素粒子レベルまで抽象化しようぜ

とりあえず、なんでもいいから化学調味料いれとけ。

調味料に頼ったラーメンは三流なんだよ。

ラーメンライスとかどうするよ？

プラグイン化しようぜ。

>>33
ラーメンライスは、ラーメンとライスであって、ラーメンライスというものではないので、
SetCollectionにラーメンとライスを保持させて実現する。

とりあえず生ビール

ビールとラーメンってのは個人的には相容れない。

米沢らーめん愛愛では、主に定食を食べる。

class NoodleFactory {
static Noodle createNoodle(Material wheat);
}

実際はまずは麺から作るの？
それともスープ？

麺はたいがいは製麺所にたのんでるんだろ？
出来合いでいいんじゃない？

>>35
ラーメンの具にライスを投入する場合もあるだろう。

ラーメンの麺を食べた後にまだ食い足りなくて、そうめんを入れたり、マカロニを入れたり
ごはんを入れてラーメンおじやとかにするユースケースも想定しなくてはならない。

実はもれラーメンにライスぶっかけて食うの好き

漏れはライスにラーメンの汁をぶっかける派

おまいらひとつ教えてくれ。

目指しているのは、非の打ち所無く一部の隙も無駄も無い
輝かんばかりのラーメン「の製作過程」でつか？

汚れだが凄まじいパワーと推進力で事を進めるラーメン職人はこの際用なし？

Decoratorか何かでスープのダシの材料の
付け加えを容易にできるようにした方がいいな。

汎用ラーメンオブジェクト

class Ramen {
　public String shousai;
　public Ramen(String shousai) {
　　this.shousai = shousai;
　}
}

使い方

Ramen miso = new Ramen("みそラーメン、具は海苔２枚とチャーシュー１枚");
Ramen shouyu = new Ramen("しょうゆラーメン、具はメンマ３０g");

すげえ、どんなラーメンでも表現できるじゃん!!

汎用ラーメンマンオブジェクト

class RamenMan extends Ramen {
　public RamenMan(String shousai) {
　　super(shousai);
　}
}

使い方

RamenMan sono1 = new RamenMan("我こそはラーメンマンだ。");
RamenMan sono2 = new RamenMan("私こそラーメンマンだ。");

抽象的すぎるんだよ。


class Thing {
　public String details;
　public Thing(String details) {
　　this.details = details;
　}
}

使い方

Thing thing = new Thing("世の中で起こる事象、存在する物体、なんでもいいから、何か");

ラーメンマンはラーメンを継承してできるのか……。

モンゴルマンがラーメンマンを継承した場合に発生する脆弱性について

オブジェクト指向ではラーメンすら作れないってよく分かったよ

>>52
RemoveMaskExceptionでもcatchしとけ。

template<typename I, typename RO, typename HA> class Ramen : public Pasta<Japan, I, RO, HA, NI>
{
};

モンゴルマンはラーメンマンの薄いラッパークラスでしかありません。

>>52
左頭部にセキュリティホールが見つかりました。

oyaji.chumon("ramen", 1, "katame")

IkkonoChumon
├KatasaType katasa;
└RamenType ramenType;

Chumon
└IkkonoChumon[ ] chumonList;

bokunoChumon : IkkonoChumon
bokunoChumon.katasa = KATAME
bokunoChumon.ramenType = RAMEN

mamanoChumon : IkkonoChumon
mamanoChumon.katasa = YAWARAKAME
mamanoChumon.ramenType = MISORAMEN

papanoChumon : IkkonoChumon
papanoChumon.katasa = HARIGANE
papanoChumon.ramenType = TONKOTURAMEN

bokutatinoChumon : Chumon
bokutatinoChumon.chumonList = [ bokunoChumon, mamanoChumon, papanoChumon];

oyaji.chumonWoUkeru(bokutatinoChumon);

public class Oyaji
{
　public void make(String order)
　{
　　System.out.println("へい、" + order + "お待ちどう!!");
　}
}

>>60
Oyaji.make() からは Ramen 型の返り値とか欲しくね？

Noodle{
Soup soup;
Men men;
Gu[ ] gu;
}
Ramen : Noodle{
RamenSoup soup;
RamenMen men;
RamenGu[ ] gu;
}

Soup{
Mizu mizu;
Dasi dasi;
Enbun enbun;
}
Soup SHOUYUSOUP, MISOSOUP, SIOSOUP, TONKOTUSOUP;
RamenSoup : oneof [ SHOUYUSOUP, MISOSOUP, SIOSOUP, TONKOTUSOUP ];

Men{
Real Futosa;
Real Nagasa;
Real TidireGuai;
MenKiji kiji;
}
Men HOSOMEN, FUTOMEN, HIRAMEN, TIDIREMEN;
RamenMen : oneof [ HOSOMEN, FUTOMEN, HIRAMEN, TIDIREMEN ];

注文は注文だから、Oyajiはファクトリだよな。
リフレクションでいくのだ。
Javaわすれたので、こんな感じか？

public class Oyaji {
　private Properties menu;
　
　public Oyaji() {
　　//メニューをファイルから初期化
　}
　
　public Ramen make(String order) {
String name = menu.get(order);
　　if (name == null)
　　　System.out.println("うちはそんなのねーぜ、ばかやろー!");
　　Ramen r = (Ramen)Class.newInstance(name);
　　System.out.println("へい、" + order + "お待ちどう!!");
return r;
　}
}

Menu.properties
しょうゆラーメン=rairaiken.ShouyuRamen
しおラーメン=rairaiken.SioRamen
みそラーメン=rairaiken.MisoRamen
とんこつラーメン=rairaiken.TonkotsuRamen
これらのクラスは、Ramenを継承してできてる。
プロパティを変えれば、他の店用にカスタマイズ可能。

>>62
それじゃ甘いよ
ラーメンの初期化をどうやってやるんだい？
ここは、２段構えのファクトリじゃないとね

String recipeName = menu,get(order);
Recipe recipe = (Recipe)Class.newInstance(recipeName);
Ramen ramen = recipe.create();
return ramen;

プロパティファイルは、
しょうゆラーメン=rairaiken.ShouyuRamenRecipe
しおラーメン=rairaiken.SioRamenRecipe
みそラーメン=rairaiken.MisoRamenRecipe
とんこつラーメン=rairaiken.TonkotsuRamenRecipe

>>62
ばかやろーのあとはOyajiRuntimeExceptionなげろよw

>>63
CommandPatternですか
でもレシビだけあってもつくりようがないよ
材料をどうするのさ

>>65
個別のRecipeが知ってる。

ramen = Oyaji.make("ramen");
Kyaku.taste(ramen) => "マズッ"

んな無茶な、、、材料が在庫管理されてたらどうすんのさ
魔法のレシピじゃないんだから、、、

つか、ラーメンの製作過程をOOPすんなよ

Recipe.create()は無理だよな
レシピをもっと分析してみろよ

レシピは
材料の種類と分量
作成手順
から構成されるだろうね

レシピは、スープや麺のサブレシピから構成されることもあるから
入れ子にできた方がいいね
作成手順は順番にとれるといいので、イテレータ的にとれるといいね
同時に並行してやる作業もあるだろうから
作成手順の入れ子にできたほうがいいだろうね

まあいずれにしてもレシピの役割はここまでだね
材料集めとかはこのレシピを渡されたオブジェクトがやるだろ

recipe = oyaji.get_recipe(order);
zairyo = oyaji.get_zairyo(order);
ramen = oyaji.make(recipe, rezairyo);
return ramen;

でどうよ

どんな材料を使うか知ってるのはレシピだから
こうのほうがいいんじゃね？

recipe = oyaji.get_recipe(order);
zairyo = oyaji.get_zairyo(recipe);
ramen = oyaji.make(recipe, zairyo);
return ramen;

>>72
そのほうがいいな

大量の注文をさばくにはマルチスレッドにすればいい

バカだなぁ
そのまえにサービス（業）は最初からマルチスレッドだろ普通

Deshi登場？

パイプライン実装しないと。途中で注文キャンセルされた場合のフラッシュも含めて。

Oyaji oyaji = MazuiRamenya.enter();
PrintWriter ord = null;
try {
　ord = new PrintWriter(oyaji.getEar());
　ord.println("豚骨ラーメン");
　ord.println("オレンジジュース")
catch(MenuNotFoundException e) {
　ord.println("許して下さい");
} finally {
　ord.close();
}

>>77
なるほど、さすがだな
FiFOの伝票スタッカーは必要だな

例外はスローしろバカヤロ

>>77
メッセージキュー使って、JMSでアクセスしようze

>>75
実装のことを言ってるわけ
実装しなかったらラーメン屋の親父でさえシングルスレッドだ

>>82
いや、ぜったいとなりに母ちゃんはいるから
かならずマルチスレッド

>>82
アルバイト募集すればいいだろ？

ラーメンが一つ出来上がるまで注文を受けつけないこだわりのシングルスレッド親父

そもそも客は非同期でやってくるんだからイベントだろ
イベントハンドラ登録しとけ

店員が複数居るのはマルチプロセスだと思う。
店員が親父1人でも基本的には複数注文を受けられるからこれでマルチスレッド。

そしてOSにあたるのが店長。

interface ShopListener {
public void customerEntered(ShopEvent ev);
public void customerOrdered(ShopEvent ev);
public void customerPayed(ShopEvent ev);
public void customerExited(ShopEvent ev);
}

public class Oyaji implements ShopListener {
public void customerEntered(ShopEvent ev) { System.out.println("いらっしゃい！！"); }
public void customerOrdered(ShopEvent ev)
{ make(ev.getOrder()); }
public void customerPayed(ShopEvent ev) { System.out.println(ev.getOrder().getPrice() + "円になります"); }
public void customerExited(ShopEvent ev) { System.out.println("まいど！！"); }
}

>>88
店長はオヤジが兼ねている場合が多いんじゃないだろうか。
OyajiはShopManagerも実装すべきでは。

スレ上がりっ放しだけどなんで？
見たところ糞スレにしか見えないんだが？

良スレが上がりっぱなりになるわけ(ry

かなりの確率で店長は人間だと思うので interface Human を実装してくれ。

経営者だが、店長なんて信用ならんので食券制にして
「チケット販売機」を追加してくれたまへ。

kappu_ra_men.insert(kona_su_pu);
kappu_ra_men.insert(kayaku);
kappu_ra_men.insert(oyu);
kappu_ra_men.wait(3);
this->eat(kappu_ra_men);
if(this->isDelicious()){
this->shout("ｳﾏｰ");
}else{
this->shout("ﾏｽﾞｰ");
}

このスレは、マ板にいくべきだと思いますが。

if(soup.taste() == ﾏｽﾞｰ)
{
delete soup;
return EXIT_TODAY_HEITEN;
}

らぁ麺屋の経営しみゅれぃしょんでっか？

OOスレに来るのはバカばっか。
一人消しても、また一人・・・
おまえらスライムか？
なんでOOPL扱えないくせに、OOについて語ってるんだよ。
Cでポリモーフィズムできるようになってから出直して来い。
Vectorなどのコンテナークラスは、オブジェクトを格納できるわけだけど、
明らかにポインタを格納するバグはでないだろ？
それから、最近2chのレベル低くなりすぎ。
数値計算やアルゴリズム、データ構造それから
少なくても、２つ以上の言語についてしっかり知っとけ。
OSやらハードウエアに関する本も少しは読め。
数学の本も少し読んどけ。

サーバーサイドプログラミングはレベル低い。これ事実。
覚える事はいっぱいあるかもしれないけどレベル低いんだよ。
DB周りは特に勘違いしてる奴が多い。
SQL使えるからなんだっつーの？
SQLサーバー自作してから言え。
サーバーサイドの奴は、少し視野を広げろ。

最後に、仕事でプログラムやってるやつは
趣味でなんか作れ。

それなりに面白い。あげ

そろそろ地球シュミレーターはできまつか？

気が早いんだけどさ、トッピングとか、麺固、とか微妙なカスタマイズや
限定メニューみたいなイベントに対応できる柔軟なパラメータ設計が大切
と考えていて気がついたんだけど、運用していくと馴染みの客が「いつもの」
って言ったりしても通じるDBは必要じゃないかな。
もっとも、sinasoba_sanoパターンならそういうのは一切不要か。
ここまで見た限りでは、oyajiはsanoである事を前提にしてる感じだけど。