smalltalk信者： 変化する環境に適応出来なかった絶滅種
デザパタ厨： 煽ることしか出来ない無能
次の患者、どうぞ
無能な煽りは逆効果だとも分からないほど無能なんだな。
デザパタなんてイラネな俺がいくら無能でも、
デザパタを勉強する価値がある事にはならんだろ。
肝心のデザパタ厨が無能なんだから。
お前ら当たり前の論理も組み立てられないのな。
結局はデザパタ厨もやりすぎて手段が目的になってる。
上級者の実装パターンを学び、実装時にそれを生かすのが目的なのに、
デザパタの暗記が目的になり、undoすら実装出来ないのでは意味無いだろ。
しかも自分がその程度だと気付けてないのも救えない。
全スレ>>945は訂正しておく
・933の実力>>>デザパタ厨＝自分がundoの実装すらマトモに出来ない事に気づけない
布教したいのなら、お前らがやるべき事は、
実装方式を悩んでいる初心者に対し、「そこは○○パターンで(ｷﾘｯ」と丁寧に教えることであって、
いくら俺を叩いても意味無いだろ。
まあお前らにはこれをやる実力すらないわけだが。 前スレ見てきた
> デザパタの暗記が目的になり、undoすら実装出来ないのでは意味無い
とか言ってる人がいたから、デザパタ厨とアンチデザパタ厨で実装対決してたのかと思ったら、誰もなにも実装してなかった
なるほど、undoすら実装できない人同士で設計論を争ってるのか
デザパタの持つ意味も理解してなければ
デザパタとundoの関係も理解してない人が
デザパタイラネと言ってたのが前スレ
undoするものがないのに何を実装するんだ
こいつundoさえわからないのか
どんなコンテナ概念も全部「それは構造体だから～」にする
いつもの「自動車は馬なし馬車だから」さんが居たのは憶えてる。
「注文」っていう動詞があったときに、
「振る舞い」と「操作」って何が違うんかな。
>>19
主体が違うし、それがOOPの基礎でもある。
詳しくは優秀なつもりのデザパタ厨が説明してくれるのを待て。 order.cancel() -> 注文の振る舞い
cancel(order) -> 注文に対する操作
ただしメソッドのことを操作と呼ぶ場合もあるから文脈による
>>19
注文のように振る舞うオブジェクトを他のオブジェクトが操作するんだよ だからデザパタってなんだよ
デザインパターンすら打つのが面倒くせえ奴はプログラミングなんかやめちまえ
オブジェクト指向ができなくて悩んでいるのですが、アドバイスお願いします
例として商品は10種類まで、今はつり銭の概念が入ってくるとややこしくて考えられないので投入金額 = 価格のみ購入可能というすごいシンプルな飲料自動販売機を想定しています
フローとしては購入する()内で飲料型の商品変数のメンバ価格と投入金額を比較し、イコールだった場合在庫数を減らす()を呼ぶというふうに考えているのですがどうなのでしょうか？
また自販機がわかりづらい場合、他の例を出して頂ければそちらで設計しますのでお願いします
クラス図を貼っておきます
![オブジェクト指向システムの設計 174 [無断転載禁止]©2ch.net ->画像>10枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/0Sthq5O.png)
どうなのって、正解があるわけじゃないから好きに作れよ
複雑そうなところはクラスの数を増やす、そうでないなら無理にクラス化しない
そういうことでどこまで作るかにもよるし
ユースケース図でも書け
デザパタ デザパタ デザパタ デザパタ デザパタ デザパタ デザパタ デザパタ
デザパタ デザパタ デザパタ デザパタ デザパタ デザハタ デザパタ デザパタ
デザパタ デザパタ デザパタ デザパタデザパタ デザパタ デザパタ デザパタ
デザパタ厨はこういう時こそ「○○パターンで！」とやるべきだろ。
そもそもデザパタ厨ですら全く使わない（＝見かけない）から最初の質問、
「本当に使われているのか？」が発生するのであって。
ねーよ
デザパタは使おうとすると
適応根拠が説明しきれない
>>31
それだとデザパタは使い物にならない＝ゴミ、ってことになるだろ。
てか君はどっち派よ？
まずはデザパタ厨に説明する機会を与え、様子見すべきだろ。 >>33
どっちとかじゃない
デザパタはどのくらいクソって議論しか取り合わない >>37
外国人にはデザインパターンじゃないと
通じなかったよ >>26
オブジェクト指向かどうかに関係ないが
内部構造を考える前にシステム境界の内側と外側のインタラクションをまず考えること
システム境界の内側と外側のインタラクションを定義するためには
各インタラクションを自然言語で明確に記述することからはじまる
それができれば一番外側のクラスのインターフェースを考える（慣れるまで内部状態は一緒に考えない）
次に一番外側のクラスのインターフェースをサポートするために必要な状態やクラスを考える
で新しく必要だと考えたクラスのインターフェースを考える
これを繰り返す >>26
- 「お金の投入」と「商品の購入」を別インタラクション？ お金はどうやって投入するの？
- 「購入する()」は何も渡さず何も返さない？
↑こういう点が必要なインタラクションを把握できてないと感じるところ デザパタなんてまだマシだろ
外人なんてDPって書く奴ざらにいるぞ
>>26
出庫(商品id, 出庫日, 個数)
入庫(商品id, 入庫日, 個数)
在庫管理 {
在庫数を取得する(p_商品id) {
a = (select sum(個数) from 入庫 where 商品id = p_商品id)
b = (select sum(個数) from 出庫 where 商品id = p_商品id)
return a - b
}
入庫する(商品id, 入庫日, 個数) {
insert into 入庫 (商品id, 入庫日, 個数)
}
出庫する(商品id, 出庫日, 個数) {
if (個数 > 在庫数を取得する()) throw 例外("在庫数が足りません")
insert into 出庫(商品id, 出庫日, 個数)
}
}
自販機 {
ボタンクリックイベント() {
商品id = 押されたボタンに紐付く商品idを取得する()
在庫管理.出庫(商品id, 現在時刻, 1)
押されたボタンに紐付く商品を取り出し口に落とす()
}
}
グローバル例外ハンドラ {
未処理例外イベント(例外) {
エラーログを出力する(例外)
}
} >>43
- 無限に入庫できるの？
- ボタン押せばお金入れて無くても商品出してくれるの？
- 在庫数取得中にラスト1個の出庫が発生すると商品出てこないね
早まった詳細化はよくあるデスマーチパターン >>45
要件に無いので無限に入庫できる
金銭の問題は質問者が別途考えることであり現在のコンテキストにはそぐわない
自販機において商品購入の並列処理は考慮しなくてよい
あまりにも馬鹿馬鹿しい指摘は今後スルーします 結局デザパタは自販機クラスを構成する時の説明に使えないのか？
ならばデザパタは存在価値が無く、デザパタ厨はゴミだって事になるが。
俺の見立てでは、デザパタはセンスがない奴の勉強してますアピール時のアリバイ程度にしかならない。
肝心の構造実装を説明する時にも他の用語の方が適切だって時点でゴミ確定。
使い物にならないから誰も使わず、「本当に使われてるんですか？」という質問が発生する。
デザパタ厨は老害だよ。
デザパタが有用だと主張するなら、デザパタ用語でより分かりやすい説明を提供できないといけない。
そもそも俺はデザパタ厨は実装能力が全くなく、非デザパタ用語での説明すら出来ないと見ているが。
ついでに言うとsmalltalk信者もこういう時こそメッセージング指向(ｷﾘｯで
素晴らしい実装を披露するべきであるんだがな。
>>43
ところでそれは何言語で何指向なんだ？
(なお俺も>>45は揚げ足取りで、現段階で必要な議論ではないと思う) >>48
自販機クラスの構成の説明に使えないものはゴミなら、プログラミングの世界ってゴミばかりだねw >>49
そもそもお前らデザパタ厨は「『何に役立つから』デザパタを学ぶべきだ」という主張なんだ？
当然だが俺は、何にも役に立たないからゴミだ、という主張だ。
実際ここで使わないで、いつ使うんだ？という状況だろ。
> プログラミングの世界ってゴミばかりだねw
他に何がゴミだと思っている？ >>50
> そもそもお前らデザパタ厨は「『何に役立つから』デザパタを学ぶべきだ」という主張なんだ？
デザパタ本を最初に読んだ時、
俺がそれまで悩んでいたり自分で考えた設計が
紹介されていたから、やっぱりちゃんとした
本で勉強したほうが時間の節約になると
実感したから学ぶべきだって主張
あんたの世界が狭いんだろ？
フレームワークを使って、その中身だけを書いてる人は使わないだろうさ
自分の作ったアプリにプラグインの仕組みを取り入れようとしたり
テキストエディタなんかを作ろうと考えたら、必ずと行っていいほど使うよ。 >>51
そりゃ>>26への回答だろ。
つか、俺は君の>>40-41よりも>>43の方が直接的で分かりやすいと思うが。
全部実装する必要もないし。
>>43
俺は48で何指向かと聞いたがこれは間違いだった。
これはOOPだね。見落とした。すまん。 >>53
> 自分の作ったアプリにプラグインの仕組みを取り入れようとしたり
> テキストエディタなんかを作ろうと考えたら、必ずと行っていいほど使うよ。
ほう。何パターンを使うんだ？
前者は「DLL」、後者は前回も言ったがundoなら｢逆方向履歴｣等で、デザパタ用語は不要だろ。
これ以上に明快な説明をデザパタ用語でやってみろよ。 要件定義をきちんとすれば自然に辿り着くことだけど
自動販売機をモデル化する場合に核になるのはステートマシン
それを理解せず設計したりコードを書いたりすれば
>>45で指摘したような問題が後から後から出てくる
設計時もコーディング時も
事前/事後/不変条件を常に意識することが大事 >>55
「デザパタ」が必要ないんじゃなくて
「デザパタ用語」が必要ないって
お前書いてるよね？ｗ 逆方向履歴という機能を実装するのに
デザインパターンが使われている
>>57
それは当たり前。
デザパタは登場時の時点で「既に頻出」な物に名前を付けただけ。
何も新しい物はない。普通にコード書けば使っている。
だから俺は「デザパタを別に勉強する意味はない」という立場。
>>59
> 逆方向履歴という機能を実装するのに
何パターン？
これにはパターンは無いはずだが。
（ただし俺は全て押さえているわけではないが） デザインパターンだっつってんだろ
馬鹿なの死ぬの？
>>56
> 自動販売機をモデル化する場合に核になるのはステートマシン
これは多分違うぞ。
どのレベルからステートマシンと称するかにもよるが。 > デザパタは登場時の時点で「既に頻出」な物に名前を付けただけ。
たしかに世界にとっては頻出だろう？
だが勉強中の人にとっては知らない知識だ
だからその人が世界に追いつくために
勉強しなければいけないってことだ
なぜ頻出なものを自分で考え出さないといけないのか
それこそ時間の無駄だ
>>62
そこはステマシじゃねぇのかよ
中途半端な野郎だな 結局デザパタを認めないやつは
自分で考えだしたものが
実は教科書に乗っているようなものと
認めたくないんだろうな。
>>63
> なぜ頻出なものを自分で考え出さないといけないのか
> それこそ時間の無駄だ
使える物は全て言語機能に採り入れられてるから、言語を学べば「使い方」は理解出来る。
そしてせっかく覚えた「デザパタ用語」は使い道がない。
中途半端に抽象化した結果、「ストラテジーバターン」＝動的に対象関数を切り替える
とした場合、実装は「継承/委譲/関数ポインタ」等になり、実装時にはこれらの区別も重要な為、
「継承/委譲/関数ポインタ」が使われ、「ストラテジーバターン」が使われることはない。
だったら最初から言語機能をきっちり押さえた方がいい、というのが俺の立場。
(ただしJavaみたいな制限がきつい言語だと、言語だけ学んでも駄目だが) > 使える物は全て言語機能に採り入れられてるから、言語を学べば「使い方」は理解出来る。
言語を学ぶの中にデザパタを学ぶが含まれているんだが？
なにを言ってるのだろうこいつは
ストラテジーバターンは継承/委譲/関数ポインタを応用して
作り出すパターン
単体の道具（継承/委譲/関数ポインタ）を
複数組み合わせて構造を作るのがパターン
やっぱりデザパタ分かってないんだなｗ
>>68
> 言語を学ぶの中にデザパタを学ぶが含まれているんだが？
これは初耳だが、どの言語のことだ？ >>71
どの言語でも
継承ってなんですか？
→ 親クラスの機能をサブクラスが受け継ぐことです
継承を使うと何ができるんですか？
→ 応用例はいくつもあります。例えば～のような使い方が出来ます。
このような使い方を○○パターンといいます。
っていうように道具を使った応用例として
デザパタがでてくるだろ
お前は継承という道具を勉強するだけで
その継承のいろんな応用例まで勉強中のやつが思いつくと思ってんのか？ >>69
> 単体の道具（継承/委譲/関数ポインタ）を
> 複数組み合わせて構造を作るのがパターン
これは俺は無駄なバリエーションで名前の数を増やしているだけという立場。
お前らはテンプレートメソッド＝継承という立場だったはずだが、
その場合、テンプレートメソッド、ストラテジー、コンポジットを別々にする意味はあるのか？
そして、この程度の差異で無駄に名前を増産する意味があるのか？
何の為にストラテジーパターンを抽象化したんだ？ >>72
> → 応用例はいくつもあります。例えば～のような使い方が出来ます。
> このような使い方を○○パターンといいます。
ねーよアホ。
デザパタが書かれる前から継承はあったし、使われてる。
継承は継承としか書いてない。
お前はデザパタ洗脳用の教科書を掴まされたんじゃないのか？ > その場合、テンプレートメソッド、ストラテジー、コンポジットを別々にする意味はあるのか？
使い方が違うからな。
第一な、無駄なリエーションで名前を増やしているというのなら、
言語なんて実は
・順次実行
・メモリ（I/O)読み書き機能
・演算機能
・（条件付き）ジャンプ機能
これだけの用語で十分。関数とか例外とかそんなものすらいない。
実際機械語はこのぐらいしか機能がない。
それ以外の機能は、これらの基本的な機能の応用例でしか無い。
だが、それだけじゃあまりにも基本的な機能すぎて
他の人と知識を共有できないから名前を増やすことで
短い単語で言いたいことを表現してるんだろうが
>>74
> デザパタが書かれる前から継承はあったし、使われてる。
だからなんだ。
使われてるその応用例をカタログ化したのが
デザインパターンなんだろ
プロが長年かけて最適なパターンを教科書に乗せて
初学者がすぐに追いつけるようにしたんだよ。 > 継承は継承としか書いてない。
当たり前過ぎ・・・
基本と応用の違いも理解できんのか。
初学者に継承を教えるだけで、
すぐに応用例が思いつくわけ無いだろ
基本（継承）を教えてから、基本機能を組み合わせて
応用（パターン）を学ぶんだよ。
継承とパターンが違うんだから、
継承のストラテジーパターンって書くわけ無いだろｗ
継承＝ストラテジーパターンではない。
色んなパターンの中で継承が使われてる
ストラテジーパターン以外でも継承が使われている。
この２つの単語は同一ではない
>>75
> 短い単語で言いたいことを表現してるんだろうが
おう、だからやってみろと>>55で俺は言ったはずだが、
お前も不都合なことは見えなくなる病気なんだな。
デザパタ用語は抽象度が中途半端すぎて、何にも使えない、というのが俺の立場。
まあ、>>55の回答を待つ。 >>69
> 単体の道具（継承/委譲/関数ポインタ）を
> 複数組み合わせて構造を作るのがパタ
これは俺は無駄なバリで名前の数を増やしているだけという立場。
お前らはテンメソ＝継承という立場だったはずだが、
その場合、テンメソ、スト、コンポジを別々にする意味はあるのか？
そして、この程度の差異で無駄に名前を増産する意味があるのか？
何の為にストパタを抽象化したんだ？ >>77
俺は>>72の
> どの言語でも （中略）
> っていうように道具を使った応用例として
> デザパタがでてくるだろ
についてダウト！と言ってるんだよ。
理由は「継承」は「デザパタ」よりも古いから。
これに対する回答は？ >>79
> おう、だからやってみろと>>55で俺は言ったはずだが、
そこがお前ずれてるんだよ。
デザパタは「やること」ではない
（誰かが）やったことの知識だ
すでに「やってる」ことに過ぎない
何をやれと言ってるのかさっぱりわからない。 >>81
> 理由は「継承」は「デザパタ」よりも古いから。
古いから何なんだよ・・・
最初に継承が生まれ、それを使って
いろんなパターンが生み出された。
継承はパタ－ンよりも古くて当然だよ。
で「継承」は「デザパタ」よりも古いからなに？ >>78
> 初学者に継承を教えるだけで、
> すぐに応用例が思いつくわけ無いだろ
いやストラテジーパターンは応用例ですらない。使用例だ。
誰でも思いつくというか、この使い方をする為に設計された言語機能が継承だ。
そして使い方なら言語の説明で一通り為されて居るものだ。
> 継承＝ストラテジーパターンではない。
(意見としては)違うね。
継承を使った場合、ストラテジーパターンに該当しない物を作れない。
抽象度が異なる為、これらは確かに単語としては同じではないが、しかし、
「ストラテジーパターン」という単語を使って説明する適切な場合がない。
要らない単語をいたずらに増やしただけだ。 >>80
> その場合、テンメソ、スト、コンポジを別々にする意味はあるのか？
応用例の説明見れば分かる通り
使い方が違うんだから意味あるだろうな。
シチューとカレーなんてどちらもほとんど同じ材料が使われてるが
別々の料理になってるだろ。
お前が言ってるのはそういうこと
いろんなパターンで継承が使われてるが、その継承の
使い方の違いでパターンの違いになるんだよ。
どっちも同じ材料が入ってるから、
「にんじん＋たまねぎ＋じゃがいも料理」だ！
じゃないの >>82
> 何をやれと言ってるのかさっぱりわからない。
お前は本当に馬鹿なのか？
日本語が通じないようならこの辺で打ちきりにするが。
俺は、
> 他の人と知識を共有できないから名前を増やすことで
> 短い単語で言いたいことを表現してるんだろうが (>>75)
について、>>55で求めた、
> 前者は「DLL」、後者は前回も言ったがundoなら｢逆方向履歴｣等
よりも簡単な説明をデザパタ用語でやれ、と言ってるんだが。 >>84
> 誰でも思いつくというか、この使い方をする為に設計された言語機能が継承だ。
最初にストラテジーパターンというパターンがあって
継承が生まれただと？
ハハハ
逆
なぜなら
> 理由は「継承」は「デザパタ」よりも古いから。 >>83
なるほどお前は池沼なんだな。
> で「継承」は「デザパタ」よりも古いからなに？
デザパタ(1995)以前の「継承」を実装していた言語の仕様書、
例えば「プログラミング言語C++」(1983)において、
> どの言語でも （中略）
> っていうように道具を使った応用例として
> デザパタがでてくるだろ (>>72)
があり得ない、と言ってるんだが。 >>86
> 前者は「DLL」、後者は前回も言ったがundoなら｢逆方向履歴｣等
DLLはダイナミックリンクライブラリ
動的にリンクするライブラリと言うだけで、
それだけではどんなものかがわからない。
> undoなら｢逆方向履歴｣
逆方向履歴という機能を実現するにはいろんなやり方がある。
それだけではどんな設計を使うのかが決まっていない
その設計にどんなパターンを使うのが良いのか？
そこでデザインパターンの中から適切なものを探そう >>88
あ、お前今が2017年だってわかってなのか？ｗ
そりゃデザインパターンとしてカタログ化されてない
昔(1995)以前では、言語の勉強の中で
デザパタが登場するわけ無いだろｗｗｗ
昔（お前の時代）にはデザパタ出てこないの当たり前だよーーーーｗ
今は言語の勉強の中で基本の応用として
デザパタを学習するんだよ。 いや、まかさ
俺の子供の時代にはそんなこと習わなかった
が根拠になっていたとはなｗｗｗ
草ｗｗｗ
>>87
> 最初にストラテジーパターンというパターンがあって
> 継承が生まれただと？
お前は本当に馬鹿だな。
継承の典型的な使用例に「ストラテジーパターン」という名前を付けただけだ。
だけど実際は「継承」で全く問題なくて、しかも無駄に抽象化したから使いどころもなくなった。
というかどうやらデザパタ厨はマジで馬鹿で議論が出来ないのは分かった。
他の言葉が通じる連中が出て来たら再開する。 >>87
> 最初にストラテジーパターンというパターンがあって
> 継承が生まれただと？
お前は本当に馬鹿だな。
継承の典型的な使用例に「ストパタ」という名前を付けただけだ。
だけど実際は「継承」で全く問題なくて、しかも無駄に抽象化したから使いどころもなくなった。
というかどうやらデザパタ厨はマジで馬鹿で議論が出来ないのは分かった。
他の言葉が通じる連中が出て来たら再開する。 > 継承の典型的な使用例に「ストラテジーパターン」という名前を付けただけだ。
継承の応用例の一つとして「ストラテジーパターン」がある
応用例の一つであるということからもわかるように
継承を使った応用例はいくつも有るから
継承と言っただけで「ストラテジーパターン」を意味することにはならない。
だから「使い方」を言いたいときには「ストラテジーパターン」という必要がある。
継承はベースとなる機能
その継承の使い方がパターンなのである
>>89
> その設計にどんなパターンを使うのが良いのか？
> そこでデザインパターンの中から適切なものを探そう
それも俺は要求済みだ。早く答えろ。
> > 逆方向履歴という機能を実装するのに
> 何パターン？ (>>60)
お前は典型的な「都合が悪い物は見えない病気」だな。
まあこの議論を見れば、デザパタ厨がどれだけゴミか分かるだろうから、お前らの布教も捗るだろうよ。 > 継承の典型的な使用例に「ストパタ」という名前を付けただけだ。
継承の典型的な使用例と何度も言っていることからわかるように
ストラテジーパターンは継承の使用例の一つでしか無い
だから継承といっても使用例が定まるわけではない。
何度も言うぞ
継承の「典型的な使用例」がストラテジーパターンである
>>94
だから
・継承を使っているがストラテジーパターンには非該当
の例を出せるか？多分無理なんだよ。だから、
> だから「使い方」を言いたいときには「ストラテジーパターン」という必要がある。
この分離は必要ないんだよ。
この言い方では通じないとは思うが。 何度も言うぞ
継承の「典型的な使用例」がストラテジーパターンである
継承の使用例の一つがストラテジーパターンであるが
継承の利用例は他にも有る。
では聞こう
継承とは何パターンか？
答えるわけがない。
継承の使用例の一つがストラテジーパターンであるが
継承の他の利用例は別のパターン名がついているからである。
継承は道具。使用例がパターン。
使用例であるパターン名を言わないと、
どんな使用例かは答えられない
何度も言うぞ
継承の「典型的な使用例」がストラテジーパターンである 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)
もうそろそろ、継承の「典型的な使用例」がストラテジーパターンである
という言葉の意味が理解できたことだろうか？
そう使用例がパターンなのである
>>94
だから
・継承を使っているがストパタには非該当
の例を出せるか？多分無理なんだよ。だから、
> だから「使い方」を言いたいときには「ストラテジーパターン」という必要がある。
この分離は必要ないんだよ。
この言い方では通じないとは思うが。 >>94,96,98,99
>>97読め、そして以下の例よろしく
・継承を使っているがストラテジーパターンには非該当 >>94,96,98,99
>>97読め、そして以下の例よろしく
・継承を使っているがストパタには非該当 >>100
> ・継承を使っているがストパタには非該当
> の例を出せるか？
だせるが？
継承を使っている他のパターンはいくつも有るだろ？
だが、そのほかのパターンまで必要ない
継承の「使用例」がストラテジーパターンだ。 一つのクラスが複数のパターンを使っているってことは有るが
有るパターンが有るパターンを内包しているってのはない。
継承を使ってる他のパターンがストラテジーパターンを内包していること無い。
なぜそんな愚かな勘違いをするのか？
それはストラテジーパターンという使用例を
基本機能である継承と同一視しているからだ。
継承を使っているパターンはあるが
それはストラテジーパターンとして使っているわけではない。
継承とストラテジーパターンを同一視しているから、
そんな馬鹿な結論に至る。
これこそが、継承（基本機能）と応用（使用例）を
別々にしておくべきだという回答の一つでも有る
> Strategy パターンは、コンピュータープログラミングの領域において、アルゴリズムを実行時に選択することができるデザインパターンである。
と説明してあるように
アルゴリズムを実行時に選択しないのであれば
それはストラテジーパターンではない
継承を使っているからと言って実行時に選択するとは限らないからな
アルゴリズムを実行時に選択したい（使用例）ときに使うのが
ストラテジーパターンである
>>105
だから、継承を使っていて、
> アルゴリズムを実行時に選択しない
例を挙げてみろ、と言ってるんだよ。 例えばRailsアプリだと一般的にモデルはActiveRecordクラスを継承して作るが
実行時にアルゴリズムを変えたりはしない
ActiveRecordクラスで実装されている
機能を利用するために決まってるだろｗ
蛇足だが
ActiveRecordクラスを使わないモデルもあって
その場合は例えばActiveModelを使う。
だが面白いことに、ActiveRecordクラスは継承するが
ActiveModelは継承ではなくinclude（MixIn）する
実際の所コードを再利用することが目的なので
継承以外にもやり方はあるということだ。
そう考えるとActiveRecordも継承するのは必須ではないということになるな。
まあ蛇足だがｗ
>>109
> そう考えるとActiveRecordも継承するのは必須ではないということになるな。
当たり前だ。
virtualに対して全くoverrideしないのなら継承の意味はない。
それはある意味、典型的な間違った使い方だ。
そしてお前はそれも分からない馬鹿だということ。 トーンが明らかに下がってきたなｗ
ようやくこのバカも理解出来あってことか。
デザインパターンは使用例（応用例）であって
そこで継承を使っているからって
継承が使用例（応用例）になるわけじゃない
ストラテジーパターンはアルゴリズムを実行時に
選択することができるようにするためのデザインパターン
そこで継承が使われていることは重要ではない。
継承を使うパターンは他にも有る。
使用例（応用例）が論点なのであって、何を使っているかは
デザインパターンとして考えるときには重要な事ではない。
>>110
> virtualに対して全くoverrideしないのなら継承の意味はない。
（そこからかーｗ） >>111
は？下がってないぞ。
俺はデザパタ＝ゴミ、デザパタ厨＝ゴミ、で変わりない。
ただしお前が馬鹿すぎて議論は無理だからフェードアウト気味なだけ。 >>113
でも、継承の「典型的な使用例」がストラテジーパターンである
という言葉に反論できてないじゃないですかーｗ
所詮、継承は使用例の一つなんですよ。
ストラテジーパターンを継承と言ってしまうと
他の継承を使っているパターンは、すべてストラテジーパターン
アルゴリズムを実行時に選択することができることが重要
だってことになるじゃないですかーｗ
意味不明ですよね
これはデザパタがゴミなんじゃなくて、
すべてはあんたのストラテジーパターンを継承と呼ぶから
こういう意味不明な結論にいなるわけですよ。
そうならないように、基本機能（継承）とその応用例（パターン）
きっちり分けて考えましょうって話なるわけ
何度も言いますよ？
継承の「典型的な使用例」がストラテジーパターンである
「典型的な使用例」です。 >>115
間違った使い方はいくらでも出来るんだよ。言い換えれば、
・継承の正しい使用例は常にストラテジーパターンになる
でいいか？
overrideしないで継承するってのは典型的な「便利関数置き場」であって、
駄目だろこれは。
というか、これがありならパターンにあるべきだが、無いだろさすがに。 >>115
間違った使い方はいくらでも出来るんだよ。言い換えれば、
・継承の正しい使用例は常にストパタになる
でいいか？
overrideしないで継承するってのは典型的な「便利関数置き場」であって、
駄目だろこれは。
というか、これがありならパタにあるべきだが、無いだろさすがに。 > ・継承の正しい使用例は常にストラテジーパターンになる
> でいいか？
継承の正しい使用例は常に「アルゴリズムを実行時に選択することができる」
ためのも。
うん。明らかに間違いだなｗ
実行時に選択できる必要ないし
>>117
> overrideしないで継承するってのは典型的な「便利関数置き場」であって、
> 駄目だろこれは。
だめでもなんでもない。
有るクラスが、有るクラスを踏まえているならば
（is-a関係）それを表現するために継承を使うべき
継承っていうのは「便利関数置き場」じゃないのよ？
それらの関数を使わなかったとしても
継承関係にあれば継承を使うんだよ。 overrideしない使い方として例えばRuntimeErrorみたいなのがあるな
その他の実行時エラークラスはRuntimeErrorを継承して作る。
そうすることで、全ての実行時エラークラスをRuntimeErrorとして
みなすことができるし、一部のクラスだけは例外的に
その他の情報をエラークラスに格納することができる。
>>119
それはまた違う話だ。
1本道で複数継承している場合は、将来的に分岐したり交換される可能性等を踏まえているだけ。
絶対に分岐しないと分かり切っている場合に継承する意味はないだろ。
例えば、メソッド一つ一つ全部バラして継承させて、メソッド20個で継承20階層も出来るが、無駄だろ。
将来的にも絶対にoverrideされないのなら最初から継承構造なんて必要ないんだよ。
ベタにクラス作って終わりだ。
>>120
それはoverrideと同じ、というか、メソッドではなくメンバのoverrideになる。 >>121
お前さ、基本
1. 自分が○○にたいして馬鹿なことを言う
2. 自分が言った馬鹿なことの対して馬鹿だと自分でツッコむ
3. そのツッコミを根拠に、○○はダメだという
というやり方やってるよね？
○○がだめなんじゃなくて
お前がダメなんだよｗ が、まあ、これらは通常は区別されているから、以下としよう。
・メソッドの継承の正しい使用例は常にストラテジーパターンになる
・メソッド/フィールド等全てについて（将来的にも)全くoverrideしない場合は継承する意味がない
これでいいか？
> ・メソッドの継承の正しい使用例は常にストラテジーパターンになる
ならないって何度も言ってるんだがｗ
> ・メソッド/フィールド等全てについて（将来的にも)全くoverrideしない場合は継承する意味がない
意味はある。その例も出した。
結局さぁ、お前、実装のことしか考えられてないんだよ。
設計能力が圧倒的に不足している。
どんな設計を見た所で、その実装が継承使っていれば、
これは継承と呼ぶべきだーって叫ぶつもりだろ？
設計とはかならず「何のために」そういう設計をするのかという
目的が有る。それがデザパタの使用例や応用例なんだよ。
継承は「何のために」ではなく実現技術
だから継承といっただけでは何をしたいのか全くわからない。
だからデザインパターンで定義されている名前が必要
が、まあ、これらは通常は区別されているから、以下としよう。
・メソの継承の正しい使用例は常にストパタになる
・メソ/フィー等全てについて（将来的にも)全くoverrideしない場合は継承する意味がない
これでいいか？
> ・メソッドの継承の正しい使用例は常にストラテジーパターンになる
ならないって何度も言ってるんだがｗ
> ・メソッド/フィールド等全てについて（将来的にも)全くoverrideしない場合は継承する意味がない
意味はある。その例も出した。
>>122
おれはRuby使いではないからチラ見ではよく分からんが、
見る限りrescueの仕様によるものであって、
Exceptionは派生しまくってるし、特に変だとも思わないが。 >>130
メソッド/フィールド等全てについて（将来的にも)全くoverrideしない
継承の正しい使い方だって言ってる >>129
とりあえずID見る癖付けろ。
俺のレスは粘着により複製されてるから。 >>126
> どんな設計を見た所で、その実装が継承使っていれば、
> これは継承と呼ぶべきだーって叫ぶつもりだろ？
そりゃそうだろ。
お前は継承使ってても「これは継承ではない！」というのか？ >>131
いや派生しまくってんだから、既にoverrideされまくっているはずだが。 >>133
> お前は継承使ってても「これは継承ではない！」というのか？
いや？ 継承使っていてもストラテジーバターンでなければ
ストラテジーパターンではないと言うつもりだよ？
お前はストラテジーバターン＝継承と呼ぶべきだって言ってるんだから、
お前はストラテジーパターンでないパターンを見ても、
ストラテジーバターン（＝継承）だって言うんでしょ？
っていう話をしてるんだが？ >>132
あんたが表現のロジックを統一しないから代弁してやってんだよ >>134
え？ なに？
世界中の何処かで誰かがオーバーライドしていれば
それは継承使っていいって言ってるわけ？
その理屈だと継承が適切じゃないものなんてないだろうな。
世界中の何処かで誰かはオーバーライドしてるだろうさ
たとえそれが便利関数であったとしても >>135
> お前はストラテジーバターン＝継承と呼ぶべきだって言ってるんだから、
そうとは言ってない。俺は、
・（正しい用法で）メソッドを継承した場合、ストラテジーパターンは自動的に適用されるから、
わざわざ「ストラテジーパターン(ｷﾘｯﾂ」なんて言う機会も意味もない
という立場だ。
抽象度は違うが、分離不可能だし、分離する意味もないから通常は「継承」という言葉が使われる、ということ。 >>135
> お前はストラテジーバターン＝継承と呼ぶべきだって言ってるんだから、
そうとは言ってない。俺は、
・（正しい用法で）メソを継承した場合、ストパタは自動的に適用されるから、
わざわざ「ストパタ(ｷﾘｯﾂ」なんて言う機会も意味もない
という立場だ。
抽象度は違うが、分離不可能だし、分離する意味もないから通常は「継承」という言葉が使われる、ということ。 >>137
意味不明。
RubyのExceptionは派生しまくっている＝メソッド/フィールド等が既に追加/上書きされているはずであり、
これは正しい継承の使い方である、ということ。 >>138
> ・（正しい用法で）メソッドを継承した場合、ストラテジーパターンは自動的に適用されるから、
されない。
されると思っているのはお前がストラテジーバターン（設計用語）を
勝手に継承（実装用語）と読んでいるから、
何度も言うが設計は使用例（応用例）、つまり目的が有る
「アルゴリズムを実行時に選択することができる」
という目的があってこそストラテジーバターンと呼ぶことができるのであって
この目的がなければ、継承を使っていたからと言ってストラテジーバターンにはならない
設計用語を使わないからお前は「継承を使っているものはすべて継承だー！」という
意味不明なことをいうつもりだろって言ってんの。
設計用語を使っていれば「継承を使っているものはすべてストラテジーバターンだー！」
という事になって言葉的には意味不明なことにはならない。
もちろんこれが間違っているのは先に言ったとおり。
設計能力が足りないよ？ >>140
> RubyのExceptionは派生しまくっている＝メソッド/フィールド等が既に追加/上書きされているはずであり、
いや上書きされてない。
上書きする必要ようもないしな。 >>142
メンバは追加されてるだろ。（多分）
全く同じで階層だけ与えてエントリポイントをずらしているのか？
走だとしたらかなり奇妙な使い方だとは思うが。 >>142
メンバは追加されてるだろ。（多分）
全く同じで階層だけ与えてエンポイをずらしているのか？
走だとしたらかなり奇妙な使い方だとは思うが。 >>143
> メンバは追加されてるだろ。（多分）
オーバーライドの話だっただろ。アホめｗ
例外クラスは、クラスの階層構造を表現するのに
継承が適切だから継承を使ってる。
すべてのErrorはExceptioであり、実行時に発生するのは
StandardErrorであり、ファイルIOに関するエラーはIOErrorである
という風にだ。
これは設計として正しい。
オーバーライドするかどうかは些細な問題にすぎない。
重要なのは各クラスにどういう関係があって（これが設計）
それをどう言語で表現するか（これが実装）だ
お前がずっとやってるのは、実装だけしか見てないってことだよ。 >>146
お前は言いたいことがわかる（俺が言ってることを理解した）
俺はお前が言いたいことがわからない
平行線ではない >>146
すべてはお前が
ストラテジーバターンは継承を使ってるから
設計用語ではなく実装用語の継承と呼びましょう
そうするとストラテジーバターンなんて用語はいらないですよね？
ってことはデザパタ用語は全ていらないんじゃないですか？
使う目的なんか気にせず、実装に継承を使っていれば
全部継承と呼びましょうよ
だからデザパタは意味がない。ゴミ
というばーかな。理屈を言い出したのが悪い。 >>147
> 俺はお前が言いたいことがわからない
じゃあ全部読み直せ。
それで分からないのなら、俺かお前の日本語が駄目駄目なだけであり、
どちらにしてもこれ以上は無理だ。 >>150
お前の日本語がダメダメだってことだろｗ
お前はコンテキストを理解してない。
設計の話をしている時に実装の話をすんな 使う目的が違うのに、実装に継承が使われているだけで
全部継承と呼ぶな。それは実装用語だ
ストラテジーバターンの目的として使ってない時に
ストラテジーバターンは継承♪
継承を使っていればストラテジーバターン♪
だから全部ストラテジーバターン♪
とか言い出すなボケ
ストラテジーとは別のバターンとして使っているときは
実装に継承が含まれていようが別のパターンだ
>>149
>>66,79,84読め
現実的に使えないから使われてないのだと思うぞ。
これも平行線ならそれでいいが。
>>153
そんなことは言ってないんだが、そう読めたのならそれでいい。 > 現実的に使えないから使われてないのだと思うぞ。
現実的に使われてるから、使われてるとしか言いようがない
>>154
ストラテジーパターンって何？
ストパタのこと？ 例えば、Railsのモデルに使われているActiveRecordというのは
もともとPoEAAのActiveRecordパターンという
パターンを実装したものだ
あまりにもRailsが有名になりすぎてRailsのものだと
勘違いしている人がいるぐらいにな。
これだけでも有名で大規模な利用例と言えよう
>>155
> 現実的に使われてるから、使われてるとしか言いようがない
これって前から聞いてるけど、お前のリアルなの？ >>158
あぁ、レスが遅かったな。
すでにデザインパターンが使われてる例を一つ出したところだ
デザインパターンが使われていない証拠を出せ
デザインパターンが使われている証拠を出せ
これは
幽霊がいないという証拠を出せ
幽霊がいるという証拠を出せ
という話と似ている。幽霊がいないことを証明するのは難しいが
幽霊がいるという証明をするのは簡単
一匹でも幽霊を見つけてくればいい。
だから俺はデザインパターンが使われてる例を一つ出した。
お前は難しい方から攻めてくれ。デザインパターンが使われていないという証明をしろ。 >>157,159
そうだとしてさ、その場合、
「AcriveRecordオブジェクトを継承しといてね」とは言うけど、
「AcriveRecordパターン使ってね」とは言わないだろ、普通。 #define パターン パタ
#define デザインパターン デザパタ
#define ストラテジーパターン ストパタ
#define メソッド メソ
#define フィールド フィー
これでだいぶコード量が小さくできる
他に入れとくべきものある？
>>160
だからお前は実装のことしか見れてないっていってんだよｗｗ
視野が狭すぎ
「AcriveRecordオブジェクトを継承しといてね」は実装の話だ
「AcriveRecordパターン使ってね」は設計の話だ。
（実際には誰かに頼まれて使ったのではなくRailsの生みの親のDHHが
考慮した結果AcriveRecordパターンを使っわけだが）
お前は設計がすんだあとの立場からしか見えてないんだよ。
お前の書き込み自体が「○○しといてね」と指示を出される側から見てるのがその証拠
お前は誰かがやった設計の通りに、実装することしかしたことがないんだろ？ 実装は思想やモデル、指針を定義するパターンを実現する手法のひとつにすぎない
それだけのことだよね
>>164
ソフトウェア設計者ならパターンくらい覚えるものだろう
仕様書を元に実装するコーダーなら別だが >>165
むしろ覚えるべきは「O/Rマッパー」（一般用語）であって、
「ActiveRecord」（Rails方言）ではないだろ。 普通、設計は「○○パターンを使ってね」なんて言わないからなぁ。
言うとしたら「○○パターンを使いましょう」だ
なにもない所から使うパターンを考えることが設計作業なんだから。
設計者が実装者に指示を出すとしたら
「○○パターンを使いますから、必要なクラスを実装してください」か
もしくは「○○パターンを使います。そのために必要なクラスの一部を作りましたから、
あなたは○○オブジェクトを継承しといてね」になるだろう。
そう実装の話。実装の立場からしか物事を見れてないから
設計をすることの意味すらもわからず
設計に実装と同じような指示が存在すると墓穴をほってしまう。
>>166
O/RマッパーとActiveRecordは同じ意味ではない。
まずそこから勉強することが大事だよな？ >>166
Active Recordというワードで鬼の首取るしかなくなってるように見える
議論の本質はそこではないともうひと方は言っていることがはたから見てても汲み取れる まあ、ご教授してさしあげると（笑）
O/Rマッパーは設計を意味する用語ではない
なにかのオブジェクトとデータベースをマッピングする
という目的のためにライブラリ・フレムワークの種類のことだ。
O/Rマッパーと言ってもそこにどんな設計が使われているかはわからない。
ActiveRecordパターンを使ってるかもしれないし
Table Data Gatewayパターンを使ってるかもしれないし
Row Data Gatewayパターンを使ってるかもしれないし
Data Mapperパターンを使ってるかもしれない
RailsのActiveRecordは
その名前の通りPoEAAのActiveRecordパターンを
実装したO/Rマッパーである
別にO/Rマッパー全てがActiveRecordパターンというわけではない
>>168
はいはい、「O/Rマッパー」と「ActiveRecord『パターン』」な。
つかこの辺は普通に脳内補完しろよマジで。
>>167
それ前から疑問で何度も聞いているのだが、お前のリアルでは
> 「○○パターンを使いましょう」
と言っているのか？
これも何度も言っているが、ストラテジーパターンに該当するとして、
その際、継承/委譲/関数ポインタのどれにするかで大違いなので、
現実的に「ストラテジーパターンで行きましょう」なんて議論は無理で、
「ここは委譲にしとく？」みたいなことにならないか？ まとめると、基本設計(パターン)とそれを実現するために使う道具(ライブラリ等の具体的な実装)の区別をちゃんとつけて設計しましょう
ってことでFA？
>>172
O/Rマッパーの実装として
ActiveRecordパターンを使ったRailsのActiveRecordと
DataMapperパターンを使ったJavaのHibernateを紹介した
ここからもO/Rマッパーという用語では
設計がわからんという話に納得できただろ？ｗ >>170,171
それくらいは分かるが、と言うより、
・O/Rマッパー＝OとRをマッピングするもの
であって、それ以上でも以下でもないんだよ。
ただし、中身の実装を知らなくていいというのがOOPであって、それで終わり。 > ただし、中身の実装を知らなくていいというのがOOPであって、それで終わり。
ア、ハイ、実装者側の立場からしか見えてないんですよね？ｗ
中身の設計ぐらい知らなきゃｗ
少しずつ主張を変えていって最初からそう言ってるんだがってことにする論法って俗に何て言うの？
ちょっとまてｗ
終わった話を蒸し返す論法も使ってるぞｗ
>>174
そのURL読んだけど、それって多分単純にその実装をそう呼んだだけであって、
いわゆるデザパタ(GoF)とはだいぶ主旨が異なるぞ。
まあそれを有り難がるのも自由だが。 実装者は使うライブラリ・フレームワークの設計をしらないと
めちゃくちゃになるからな。
例えば昔、トランザクションスクリプトパターンと
単なるSQLライブラリばかり使ってきた人が
別プロジェクトでPythonのDjango（これもActiveRecordパターン）を
使ったんだが散々な結果だったよ。
フレームワークとしてActiveRecordパターンを要求されるが
そこにActiveRecordパターンではやらないようなコード
（SQLを実行するだけのようなメソッド）をクラスに生やしたりして。
Djangoフレームワークの実装の中身は見なくてもいいけど
そこで使われている設計はちゃんと理解していなければダメだ。
あるOOPベースのライブラリを使うことで結果的にあるデザインパターンに沿うことになるライブラリと、いろんなデザインパターンを実現するのに使えるより純粋な道具としてのライブラリがあると思うの
そこはちゃんと分離して話をしないとダメだと思うの
>>180
お前（今までの流れから明らかに力不足）の
感想なんていらんがなｗ 一応俺のスタンスは最初から変わってないつもりだぞ。
・デザパタはゴミ
・デザパタ厨もゴミ
・デザパタ用語は使い道がないからゴミ
>>184
そうだろうね
そしてそれはソフトウェア設計者としては二流以下だというのがこれまでの話の流れだと思うの >>184
もう一つ。
・俺は無能なバカ
これも加えとけｗ
今までの流れで明らかになったしな >>181
それはある。
しかしそれは「フレームワークの中身を知っておけ」であって、「デザパタを知っておけ」ではない。 >>186
というより
・俺はデザインパターンとかめんどくさいから勉強したくないの
だと思う >>182
一応それは世間的には区別されているらしいぞ。(wikiだと思ったが、今探したがない)
・自分が思うように使うのがライブラリ
・フレームワークの場合は、自分が合わせる >>187
> しかしそれは「フレームワークの中身を知っておけ」であって、「デザパタを知っておけ」ではない。
「フレームワークで使われてるデザパタを知っておけ」だ
俺はDjangoは当時知らなかったがActiveRecordパターンを知っていたから
使い方が間違っていることにすぐに気づいたぞ
特定のフレームワークに縛られない知識が重要という話だ。
あくまで実装者として立場からしか見れないお前は
今使ってるフレームワークの使い方で精一杯なんだろうけどな。
そしてフレームワークから呼び出されるコードしか書かないから
お前の世界にはデザパタがでてこないわけだよ。
全て理屈が通ったなｗ >>190
だからそれは「フレームワークがActiveRecord前提で組まれている」からであり、
それを「ActiveRecordパターン」と呼ぶのは自由だが、GoFの言う「デザパタ」とは違うって。
まあ平行線ならそれでいいが。 >>184
そうだな
デザインパターンをデザパタと呼称する奴はゴミな場合が多い ちなみにJava の Hibernate という O/Rマッパーは
ActiveRecordパターンとともに紹介されている
Data Mapperパターンを使っているが
Hibernate はフレームワークではない。ライブラリである。
むしろお前らが何故そこまで必死なのか分からん。再度言うが、>>172の後半、
>>167
それ前から疑問で何度も聞いているのだが、お前のリアルでは
> 「○○パターンを使いましょう」
と言っているのか？
これも何度も言っているが、ストラテジーパターンに該当するとして、
その際、継承/委譲/関数ポインタのどれにするかで大違いなので、
現実的に「ストラテジーパターンで行きましょう」なんて議論は無理で、
「ここは委譲にしとく？」みたいなことにならないか？
デザパタ厨の皆様、これに答えてくれよ。 デザインパターンは不要の長物といってる人はデザインパターンを理解してないと思われる
何かしらのソフトウェアをゼロから作り上げるにあたっては必ず何かしらの大枠となる基本設計思想や基本構造を構想して行われる
それがGoFのデザインパターンに一致するかもしれないし、新しい独自のデザインパターンかもしれない
デザインパターンという言葉は両者含めての言葉である
つまり、デザインパターンを持たないソフトウェアなど本来は存在しない
>>196
お前がなんでそんなことに必死になってるのか？
みんなそう思ってるよｗ
ストラテジーバターンでしか
お前はデザインパターンを否定できないってね。 >>196
> これも何度も言っているが、ストラテジーパターンに該当するとして、
> その際、継承/委譲/関数ポインタのどれにするかで大違いなので、
> 現実的に「ストラテジーパターンで行きましょう」なんて議論は無理で、
ここはいろんなアルゴリズムを実行時に切り替えられるようにしよう
であればストラテジーバターンで行きましょう。という議論になる。
アルゴリズムを実行時に切り替えられるようにしようという設計の話で
委譲にしておく？なんて実装の話は出てこない。 むしろお前らが何故そこまで必死なのか分からん。再度言うが、>>172の後半、
>>167
それ前から疑問で何度も聞いているのだが、お前のリアルでは
> 「○○パターンを使いましょう」
と言っているのか？
これも何度も言っているが、ストパタに該当するとして、
その際、継承/委譲/関数ポインタのどれにするかで大違いなので、
現実的に「ストパタで行きましょう」なんて議論は無理で、
「ここは委譲にしとく？」みたいなことにならないか？
デザパタ厨の皆様、これに答えてくれよ。 ほらなｗ
答えたのに無視するもんなー
こういうやつです
>>196
デザインパターンとは設計の大枠となる構造や指針であって、それを決めてからより具体的な実装を検討していくってだけなんだが… >>202
お前もどういう神経なのか分からんが、議論したいのなら普通に入ってこい。
邪魔したいのもお前の自由だが、だったらさらっと入ってくるな。
普通に迷惑行為をしてるんだぞお前は。 >>205
デザパタっていうなら省略ポリシーをちゃんと守って書きなって言ってるだけ >>205
デザパタと言ったかと思えばストラテジーパターンと言ってみたり、中途半端なんだよ
そういうやつが書くコードは、ところどころポリシーが違ったりしてるいい加減なコードを書きそうだ
そんな調子だからデザインパターンも軽視するのだろう デザパタと略すならストラテジーパターンも
ストパンと略すべきだろうな
>>198
ストラテジーパターン以外についても前スレでさんざん
○○＝△△パターン、って書いたろ。
まあいいが。
undoすらまともに実装出来ないデザパタ厨が、
何をどう勘違いしたら設計出来るつもりになれるのか不思議だったが、
だいぶ喋ってくれたので何となく分かったような気がする。
まあ後日読み返してみることにするよ。これについてはありがとう。 undoとかundoとかundoとか自分がやったことあるところは自信あるもんな
>>211
まあ今日はもうやり合う気はないんだが、多分お前らは設計を根本的に勘違いしている。
例えば、>>174内URLで言うなら、
> Table Data Gateway は J2EE の DAO に代表されるパターンで、
> ひとつのインスタンスがテーブルの全部のレコードを扱うというもの。
> SQL を一箇所に集めることで保守性を上げましょうね、というもの。
普通の人の設計＝後半部分を考えること
お前らの言う設計＝この全文を覚えること
になってる。
ただしこれがお前らみたいに考える能力がない連中にとって現実解になり得るのかもしれん。
これは前にも言ったが。
> 自分がやったことあるところは自信あるもんな
これがお前らの世界観を端的に示している。
経験済みならパターンとして暗記しているから出来るが、やったこと無いと何も出来ない。
最初の卵は絶対に産めないわけだ。
実はお前らがundoをさも難しいと思っていること自体がかなり滑稽なんだがな。
とはいえ新しい意味での「コピペプログラマ」が跋扈する時代でもあるから、
お前らのやり方でもある程度通用するのは事実なのだろう。
デザパタ厨＝コピペプログラマのようだし。 まあとにかく俺は、
「動的に対象関数を切り替える」と言えば済むだけのところで
「ストラテジーパターン」と言い換えるのは、厨二以外の意味はないと思うけどな。
そして「AcriveRecordパターン」なんて言っちゃうのは厨二過ぎて付いていけない。
「Rails標準O/Rマッパーの実装方式」と言えば誰にでも通じるのに。
とはいえこういう状況も割とよくあるのも事実だが。
なんども使う処理は関数化して名前を付けるだろ
デザインパターンもそれと同じだよ
この考え方を理解できない人ってめちゃくちゃ長い関数を書きそうだよね
仕事では絶対に付き合いたくないタイプ
>>178
とくに名前ついてないと思うけど
頭の悪い子が無自覚に食い下がるときって、いつもこうなってると思う
だから、いつもの展開だなって思うだけ
おまえら、バターン君これ以上いじっても何の利も無いぞ
もうそっとしておいてやれ >>215
それは君らが枝葉に対してしか反論しないからなんだがな。
とはいえこの意味も分からないのだと思うが。
君らのやり方については名前が付いていたはず。 ああ、捕捉しておくと、
ID:H5Asg8Dcは頭が悪くて、多分短期記憶領域が非常に狭い。
だから論理的に筋立てるのではなく、言葉尻を掴んで反論してくる。
というかそれしか出来ない。
だがまあ、それでも話す気はあるみたいだから相手してみた、というところ。
最初からちゃんと議論してくれればこの展開にはなってない。
とはいえ、今のID:H5Asg8Dcにこれを求めるのは無理だ。
ただ、こういう、お前らに問題があるのに相手のせいにするというのはゆとりに多いし、
ゆとりは本当に馬鹿だから他のゆとりもそう思ってしまってみんなで同調する事も多い。
今まさにそうだが。
で、そういうのにも上の世代はブチ切れているから、そこら辺は自覚した方がいい。
今デザパタ勉強中だけど、undo実装のパターンも二つぐらいなかったか
メメントとあともうひとつぐらい
よくわからんけど、なんでそんなに否定したがるかわからん
ほらな？ 個人攻撃を始めちゃったｗ
これが記憶能力が少なくて名前を覚えられなくて
2分ヒープ木を用いて並び替えする方式でも
隣り合う要素の大小を比較しながら整列する並び替え方式でも
あらかじめ順番通りに並んだバケツを並び替えを行う要素分用意して順番に格納された要素をバケツから取り出し並び替えする方式でも
10進数の0以上の整数値の場合、0?10のバケツを用意しソートを行う要素の下1桁目に対応するバケツに格納する方式でも
バラバラになっている配列データを再帰的に最小限まで分解を行い分解し終わった後、結合を行う並び替える方式でも
動的に対象関数を切り替えるようなやり方をしよう
っていうやつなんやでｗ
>>219
デザインパターンな
リアルで恥ずかしい思いしないように今のうちから直しといた方がいいよ PGは基本キチガイだよね
まともな奴だと逆に珍しい
もともとプログラム好きなオタクはもれなくキチガイだし
他の就職先なくてプログラマになったやつも内定取れないだけあって人間性のおかしなキチガイばかり
パターン名が覚えられない
だからデザパタは使えないってことにしたいんだ
>>225
身の程知らず、も初学者にありがちなパターンだよなｗ
コンパイラがバグってるだの
言語がゴミだのOSがカスだの
俺だけが正しくて世界の全員が間違ってるだの
なにか、自分が無敵に思えるタイミングが、学習の初期の初期に存在するんだろうな >>220
前スレ>>813読め
基本的に君は相手が何を言ったのか全く覚えてない。
だから話がループする。
それは君の問題だが、君の場合はそれが常である為に、その異常性に気付けない。
それはマジでヤバいぞ。リアルだったらブチ切れられて終わりのはず。
>>219
俺は、デザパタは役に立たない、デザパタ厨は全員undoすら実装できないのが証拠、という意見で、
それでも君が勉強するのは君の自由。
ただここら辺も前スレ818で言ったし、話は完全にループしてる。
結局俺は前スレ812の意見からほぼ修正されてない。
デザパタ厨はデザパタを暗記することが目的になっている。
GoFのはデザパタ厨が主張するように「設計用語」としては多少は意味があるが、（ただし使いどころがないからゴミ）
ActiveRecordとかのただの「実装の一例」を抽象化無しで「パターン」として取り扱うからおかしな事になる。
ただし、デザパタ厨＝コピペプログラマにとってはこれが彼等なりの現実解なのだと思う。
これも前スレ927で言ったとおり。 > 俺は、デザパタは役に立たない、デザパタ厨は全員undoすら実装できないのが証拠、という意見で、
根拠が無いな。
世界中を調べてみたのか？
まさかこのスレだけで判断してないよな？
>>229
>デザパタ厨＝コピペプログラマ
これもよくわからんな
デザインパターンを把握してないプログラマほどありもののコピペのつなぎ合わせでしのぎそうだが 世界中を調べてみればデザパタが使われているのは
明らかだろう。
>>232
正解。
アルゴリズムはコピペできるが
デザイン（設計）はコピペできない。
なぜならコピペ元（デザパタのサンプル）は
名前もサンプルだからそのまま使えることはない >>236
ごめん
現場で一度も見たことない
派遣で結構たくさん大手まわったけど
マジで１回も見たことないよ >>237
フレームワーク作ってるなら
コマンド、テンプレートメソッド、ストラテジー、アブストラクトファクトリー
は鉄板でしょ >>238
掻い摘んで言うと
消滅したんだよねｗ
それでいいじゃん
何にこだわってるの？ ちなみに俺も>>241と同じで、
・デザパタ用語を敢えて使う状況がないから自然消滅した
という気がしている。
だから何度もデザパタ厨に「お前らのリアルで使ってるのか？」と聞いている。 知らないことを誇るのってすごく恥ずかしいと思う
数学なんて役に立たねーってわめいてるバカ学生みたい
>>243
使ってるし使われてる。
お前はフレームワークを使うことしかやってないんだろ？
実装の立場でしか見れてない、
お前の仕事は設計が終わった後で設計にたずさわっていない。
そりゃ知らんはずだわｗ >>245
あんたつくづくお人好しだなｗ
数学なんて社会に出ても役に立たない！
って主張はたまに聞くが
その反論は意外と耳に届いてこない
なぜなら、反論しうる層の人々は
そこまでヒマでもないし、お人好しでもない
真顔のままで見下ろしてる >>241
消滅？
なぜそういうことに思考が繋がるのかわかんないっすね >>245
まあundoすら実装出来ない馬鹿がフレームワークの設計とか、あり得ないけどな ネット上でも当たり前にデザパタが使われて解説してるサイトとか無いの？
msも使ってないし
デザパタサポートしてるフレームワークとかも聞かないし
> デザパタサポートしてるフレームワークとかも聞かないし
言ってることがおかしい。
デザインパターンは設計なのだから
「サポートしている」という言い方はしない
よくある設計をサポートしているフレームワークと言い換えれば
おかしいのがわかるだろう？
その時点で間違っているというのがわかる。
設計は使うものなので、デザインパターンの設計が
使われているフレームワークはいくつもある
GUIライブラリはデザインパターンをよく使う場所だし
プラグイン的な仕組みにも使われてる
面白いことにデザインパターンへの批判には
矛盾する二種類の批判が有る。
一つは
・誰でも普通に使ってるものにわざわざ名前をつけるな
もう一つは
・誰もそんなものを使っていない
おもしろいやろ？
デザインパターンを批判している人同士で
対立してるんやでｗ
>>253
え？ボタン押してパターン選択したら必要なクラスが勝手にできるんでもいいんじゃないの？
でも誰も使ってないからそういうのできないんだよ >>254
矛盾してないじゃんｗ
両方成り立つ
大事なのはデザパタのパターンでのやり取りを誰もしてないってこと >>256
明らかに矛盾してるよ
・誰でも普通に使ってるもの
・誰もそんなものを使っていない >>255
> え？ボタン押してパターン選択したら必要なクラスが勝手にできるんでもいいんじゃないの？
あははｗ
それは「デザインパターンを使って設計したもの」
つまり「設計が終わった段階」から
コーディングの仕事をお前にさせる時に
クラスの枠組みを自動生成しているだけだ。
UMLツールがそういったことをやってくれる
お前は設計が終わった後の
実装を振られているだけなんだよ
お前は設計をしたことがない >>257
話の内容を理解しないで言葉だけ捕まえてるじゃん
使ってるって言ってる人はデザパタの構造だけの話でしょ？
使ってないって言ってる人はデザパタのパターンでのやり取りの話じゃん
結局、下の状態でなければデザパタの主旨から外れてるんだから
デザパタは使われてないんだよｗ 上の方でも「デザインパターンをコピペ」とか
意味不明なことを言ってるやつがいたが
デザインパターンはコピペしても意味がない。
なぜなら設計（＝構造）だからだ
自動生成したとしてもファイルや
クラスのインターフェースぐらいしか作成できない
アルゴリズムなどコピペするような処理は含まれていない
あくまで構造だけなんだからコピペしようがない
>>259
> 使ってるって言ってる人はデザパタの構造だけの話でしょ？
そもそもデザパタは構造のパターンですが？
> 使ってないって言ってる人はデザパタのパターンでのやり取りの話じゃん
「デザインパターンのパターンでのやり取り」ってなんですか？
パターン♪パターン♪ >>260
雛形作ってくれてもいいだろ
デザパタを使ってるなら楽だと思うぜ
シングルトンって押したら勝手にやってくれてもいいしね >>261
だからパターン名で設計のコミュニケーションを取ってないって言ってるの > 雛形作ってくれてもいいだろ
UMLツールで雛形は自動生成されてますね？
>>264
え？
デザパタが指定できるの？
見たことないよ >>263
そらデザパタ勉強してないひとらにあわせてるんでね？
一番レベル低いところに合わせるって日本的じゃない >>266
だからデザパタが指定できるっていうのが意味不明
何を指定するんだ？
デザインパターンにはクラス名もメソッド名も
決められていない。（説明用サンプルは実際に使う名前じゃない）
クラス名もメソッド名も決まってないのだからコピペしようがないのがわかるだろ？
UMLツールなどで、デザインパターンを使って
設計者が設計していくんだよ。つまり
デザインパターンを表現するのに必要な
クラスとメソッドを書いていく。（クラス図）
そこから自動生成する。
デザインパターンを使うっていうのは、
コードの再利用じゃねんだよ。
設計レベルの話なんだから
いい加減、実装の世界からしか見れないのは卒業した方がいいよ
本当に技術力不足だから まあ別にデザパタ知らんでも仕事はできるだろうけどさ
知っとくと便利ってだけで
>>270
だからボタン一発で作ってくれればいいじゃん
visualstudioみたいに
馬鹿だなお前ｗ
まあ、この世に無いものの話だから理解できなきゃいいけどｗ >>272
だから何を作るんだよ？
ファイルならファイル作成ボタンから作ればいいだろ >>272
お前が思っているよりも遥かに
高次元レベルでデザインパターンは言語・ライブラリ・フレームワークと
融合していることが>>275からわかるぞ。
この上なにを自動生成したいのか？ > PostSharpは現在、次のデザインパターン用の既製の実装を提供している。
>
略
>
> これで、デザインパターンの既製の実装を使って、チームはAOPを学習せずに、AOPの恩恵に浴することができる。
まさにこの現象だろうな。
実装担当者は、すでにフレームワークなどの含まれてるデザインパターンを使うだけだから
デザインパターンを学習せずに、知らずに利用している。
そういうやつら（デザパターンの恩恵を受けてるやつ）が
デザインパターンは（実装者よりも前の設計者が担当が使うものだから）
使わないというのだろう。
視野の狭い事だ。視野っていうか、所詮コーダーって言えば良いのか
ジュニア開発者ｗ
> デザインパターンの自動化の使用は、一般的に政治的に敏感な問題である 。
> なぜならそれは、チーム内で関心の分離を対処するからである。
> 典型的には、上級開発者は、デザインパターンを選択し、アスペクトを実装する。
> そしてジュニア開発者は、それらを使用する。上級開発者が検証ルールを記述し、
> 手書きのコードがアーキテクチャを尊重することを確実にする。
> ジュニアの開発者が全体のコードベースを理解する必要はないという事実は、実際には意図された効果である。
>
> この議論は、シニアマネージャーの視点を取り、ジュニアの開発者のプライドを
> 傷つける可能性があるので、一般的に取り組むにはデリケートものである。
ジュニアにはデザパタは不要だよｗｗｗ
このスレ誰も使ってないのにやたら頑張るなｗ
ぶっちゃけ、三○もN○Tもニ○ンもコニカミ○ルタもpana○onicもス○エニもシ○ープもN○Cも沖○気もク○タも富○通も
富士○機も東京○力も関西○力もS○NYも
使ってないから
使ってない証拠を>>280が出してくれるまで
誰も信用しないように >>282
見たことねーｗ
連徹過ぎて記憶が飛んだ覚えしかねーわｗ
俺が関わったとこはまともな資料なんて無かったな
俺が実践で使えると思ったのは
N○Cだけだけどね
ここは１回行ってみる機会があれば
いい勉強になると思うな >>283
> ぶっちゃけ、三○もN○Tもニ○ンもコニカミ○ルタもpana○onicもス○エニもシ○ープもN○Cも沖○気もク○タも富○通も
> 富士○機も東京○力も関西○力もS○NYも
> 使ってないから
> ここは１回行ってみる機会があれば
> いい勉強になると思うな
派遣の仕事って楽しい？ >>287
そんなんじゃねーよ
ちゃんと要件定義書から設計、実装までルーチンワークで作れるマニュアルがあるんだよ
見てねー奴も多いんだけど
作った奴天才だと思ったわ ルーチンワークしてるやつには
考える必要がある設計は不要だよ
お前は何も考えなくていい
ルーチンワークで十分な仕事しかしてないだけだし
ルーチン化できると言う割に自動化はしないあたり本当はルーチン化できてないんだろうなぁ
>>290
考えないとわからないところなんて俺らの仕事の範囲ではないのかもな >>291
> 考えないとわからないところなんて俺らの仕事の範囲ではないのかもな
だから設計は、俺ら＝お前の会社の同僚 の
仕事の範囲でないんだろ？ いやまじ、使わないというのは正しいんだろうよ
使わないから必要ないと思ってる時点でおさとが知れるというだけなのでは
伝言ゲーム理論を使えば三段論法で
デザパタが使われていないことを証明できる
デザパタは
俺は使わない
↓
それは使わない
↓
どれも使わない
↓
だれも使わない
↓
使わない
↓
故にデザパタだ誰も使っていない
>>296
マジ書いてあんなｗ
多くのCocoaアプリケーションでは、モデルオブジェクトの状態が変化すると、
その通知はコントロー ラオブジェクトを 経由して ビューオブジェクトに伝わります。
図 7-2にこの様子を示します。2つの基 本的なデザインパターンが関与していますが、よりすっきりとしています。
図 7-2 複合パターンとしてのMVC（Cocoa）
User action
Update
Update
Notify
Mediator Strategy Controller
ModelView
Command Composite
Observer
この複合デザインパターンでは、コントローラオブジェクトはMediatorパターンと
Strategyパターンを 包含しています。モデルとビューの間でやり取りされるデータフローを、
両方向とも仲介していま す。モデルの状態変化はコントローラオブジェクトを経由して
ビューオブジェクトに伝わります。さ らに、ビューオブジェクトには、ターゲットアクション
機構の実装という形で、Commandパターン も含まれています。 もう一つ
複合デザインパターンとしての
MVC「Model-View-Controller」は、より基本的なデザインパターンをいくつか組み合わせた形のデザインパターンです。
基本パターンどうしの組み合わせにより、MVCアプリケーションを特徴づける、機能の分割や通信経路を定義しています。
しかし従来型のMVCは、組み合わせる基本パターンが、現在のCocoaのそれとは違っていました。その違いは主として、
コントローラオブジェクトやビューオブジェクトに与える役割に関するものです。
当初の（Smalltalk流の）考え方では、MVCはComposite、Strategy、Observerというパターンから成っていました。
Composite：アプリケーションのビューオブジェクトは、実際には入れ子になったビューの
複合体（composite）であり、このビュー群が協調して（ビュー階層の形で）動作します。この表示コンポーネントは、
ウインドウを頂点とし、その下にテーブルビューなどの複合ビュー、さらにその下にはボタンなどの分割できないビューがあります。
ユーザ入力や画面表示の処理は、複合体を構成するどのレベルでも可能です。
Strategy：コントローラオブジェクトは、いくつかのビューオブジェクトに対する戦略（strategy）を実装しています。
ビューオブジェクトの機能は（視覚的）表示に関わる範囲に限定し、インターフェイスの振る舞いが当該アプリケーションに
おいてはどのような意味を持つか、の判断はすべてコントローラに委譲します。
Observer：モデルオブジェクトは、自分自身と直接的な関わり合いがあるオブジェクト（一般にビューオブジェクト）の
状態が変化すると、その通知を受け取ります。
デザパタ使えないアピールするモチベーションが、デザパタ使ってない自分肯定でしかないのが見え見えだから、つまんない議論だよ
優越コンプレックスを抱えてる人は苦しいだろうなぁ
素直な心を取り戻せることを祈ってる
>>26
凝った設計にもできるけど（たとえばDDDのドメインサービスとかさらに突っ込んだDCIのコンテキストベースで）
このくらいの要件なら自販機オブジェクトだけ定義して
在庫管理と商品種別はRDBで管理し、金銭投入→購入のタイミングで
SQLを発行して該当する飲料を商品種別テーブルからピックアップし、その後
在庫管理テーブルで在庫減らしのSQL発行で十分なのでは？
O/Rマッパーの使い方を学びたいならクラス図のようにオブジェクト化するのも手だけれども 意味不明なウンチク垂れてないでコードを書けコードを
バターン君をいじめて
得るもんがあったのかどうか
各自寝る前に自問自答してほしい
デザインパターンがいらないって言ってるやつは
実装側の視点でしか考えることができないってのがわかった。
これが得たものかな
ん？これいつものあたまおかしいおじいちゃんでしょ。
>>308みたいに自演して
「結局キャットドアに戻ってきたな」とかだせえリセット図るの。
けっこうおっさん…つうより“じいさん”って歳で構造体から脳が進化してないから
オブジェクト指向側からのアプローチが歳で理解できない可哀想な初老 >>312
何の自演だよ？
どのレスと同じやつだと勘違いしたのか教えてくれ そろそろ設計の議論もやめるかって思う
プログラムってどう組んでも動くしね
正解なんてないんじゃないかなぁ？
って思うようになった
仮にあったとしてもそれをどうやって証明するのか？
非常に虚しい気がしてきた
デザパタ、オブジェクト指向使うだの使わないだの
どっちが正解もクソも組んで金もらえたらそれでしめーな話をグダグダうるせーよな給料安いくせに
今、組めている人間を否定することはできない
また、否定する必要もない
俺等が話してることは麻雀のどの牌を捨てたらいいか？みてーな話でどうでもいいんだよきっと
初っ端字牌がないから国士無双は狙っては駄目ですよ
って言ったところで実際に狙って来ちまったらそれを誰が否定できようか？
そんなくだらない内容なんだよ
> プログラムってどう組んでも動くしね
動くだけじゃダメでしょｗ
最低限じゃん。
動くだけの汚いコードたくさん見たこと有るよ。
「プログラムを組む」っていう表現って何となく手続き的な臭いを感じる
プログラムを組み上げるものとして見てるってことだよね
>>318
次の開発が無かったら保守にかけたお金は無駄だよね？
この辺は君等はトレードオフの問題を勝手にプラスサムの問題だと履き違えている
ぶっちゃけ馬鹿にしか見えないのであまりおおっぴらに言わない方がよい 汎用性はトレードオフのはずだ
なぜ君等はつければつけるほどお得みたいなアホな考えもってるんだ？
保守なんかねーよ（あるかどうかわからないじゃん）
改修の方向性も付けた汎用性が役に立たんようなもんだったらまるまる無駄であろ
でもこういう俺の確率が高い方もしくは損害が少ない方に倒す的考えも
所詮は麻雀の捨て牌議論と何も変わらないんだろうな
って話だな
やっぱ意味ねぇよな設計に拘るのはやめたほうがいいな
金にならねぇ
>>316
> でも客からしたらどうでもいいよね
いくらでもコストがかかってもいいなんて言う客はいないよ >>320
> 汎用性はトレードオフのはずだ
汎用性の話はしてない
同じコードを何度も書いたり
コピペするとコストがかかるって話をしてる 使い捨てのどうでもいいシステムは
使えない単価安い奴に
やらせとけって話じゃないの
まあ保守は作り始めた時点から始まってるから
リリースまで行けないかもしれないがな
>>326
運ゲの麻雀で例える意味がわからない
せめてオセロとか将棋で例えろよ >>329
出来るよ
どっちも定石があるじゃん
そう言うこと
まあ麻雀よりはイメージしやすいでしょ >>331
デザインパターンて、将棋における定石みたいなもんじゃん
定石覚えてなくても駒動かせれば将棋はできるけどねー 定石の有用性を証明してみろ
できなければ定石は役立たずのゴミということ
定石は役立たずのゴミ
飛車は移動して右下隅の王を金銀桂馬香車で囲う
って言ったほうがわかりやすいじゃん
そもそも定石なんて知らなくても将棋はできるし、
何十年もやっていれば定石なんて自然に思いつく
AIに以前からの定石がひっくり返されてるらしいなｗ
デザパタもAIにひっくり返される日も近いなｗ
将棋で言う定石はデザインパターンよりももっと粒度の大きいパターン
MVCかMVVMかみたいな
デザインパターンは手筋に近い
何十年もやってれば自然に思いつくことを
数週間から数ヶ月程度の断然短い時間で理解できるようになることや
より高い抽象度で物事を考えられるようになることに価値がある
おじいちゃんに何言っても無駄かもしれんが
>>335
AIで新しい定石（デザパタ）ができるってことか？
それは嬉しいことだがｗ そりゃあ常識はひっくり返されるためにあるからな
ひっくり返ってそれが有益ならそれでいいじゃん
>>336
> 何十年もやってれば自然に思いつくことを
> 数週間から数ヶ月程度の断然短い時間で理解できるようになることや
寿司学校に3ヶ月通っただけの店がミシュランになるなんて許せん
10年間下積みをしてやっと職人になれるんや。
寿司の修行ってのはなぁ、寿司の勉強じゃなねぇだよ そもそもこんなスレがあること自体おかしいんだよ
オブジェクト指向設計なんてやってればそのうちできるようになるし、それが人と比べてどうなのかなんて気にする必要もない
人それぞれのオブジェクト指向でいい
>>340
それをあーやこーや言い合うのが子のスレなんじゃないの
デザインパターンを学習することによる不利益を逆に教えてほしいんだが >>342
麻雀の捨て牌議論といっしょで別に国士無双狙ってもええで
誰も困らん >>339
ネタじゃなく本気で寿司屋と比べてるなら
ソフトウェアの世界から早めに足洗って転職したほうがいいよ >>343
せめて会話しようぜ
言葉のキャッチボールをさ 寿司屋の板前っていうより半完成品を卸してる問屋みたいなもんだろ
で、おまえらはひたすらごはんを詰め込む係
プロパー様がネタを乗せて最後に元請け営業様がたんぽぽ乗せる
スシローはIT化進んでるから寿司はオブジェクト指向で管理してるよな
インタフェース名はsushiと予想する
オブジェクト指向スレで寿司の話題だから、
シャリを基底クラスに例えてネタごとにシャリクラスを継承、
軍艦巻インターフェイスの実装とか、お子様にはワサビプロパティをtrueにとか、
そんな話かと思ったら全然違った。
わさびプロパティってtrueとfalseのどっちだったらわさびが乗ってるんだ？
寿司クラスのプロパティはシャリネタワサビだろ
スシローに関して言えばワサビのプロパティは不要
>>355
ワサビの状態は複雑だから真偽で取るなんてナンセンス わさびの量を調整したい場合はどう拡張すればいいの？
例えば罰ゲームで使うような山盛りわさび寿司
外国人向けの程よくわさび増量
あと、わさび巻の場合はわさびプロパティの内容はどう持つべきか？
というかあれか
寿司職人.putワサビ(寿司,量,状態)
かな
>>363
キャットドアはやめろ
オブジェクト指向云々とは別のところに問題がある
またこの手の話するならちゃんと要件定義してからやれよ >>365
１つ賢い意見が出たな
要件定義をしないとキャットドアは作れない!
他のものもそうでないかな？ どういう用途のソフトウェアかに関係なく
オブジェクト指向でモデリングできると思ってるやつが多々いるのはオブジェクト指向に密接に関係した問題
>>366
寿司屋はわかりやすくね？
キャットドアやるならまずドアを作ってから継承するなりで基礎がないと >>370
オブジェクト指向が間違っているのでは？（笑） オブジェクトという名前が悪い
責務指向とか役割指向の方が適切
>>359
enum ワサビ量 {なし, ちょっぴり, 少なめ, やや少ない, 普通, やや多め, 多め, メガ盛り, ギガ盛り, テラ盛り, ペタ盛り, ワサビのみ}; 処理の流れがあちこちに飛ぶし
あちこちから飛んでくるし
「これ誰が保守するんだ？」って気分になってる。
ちょっとした修正が今までならピンポイントでテスト合わせて30分位のところが
全体見るために3時間かかる感じ。
能力高くないと無理だと思うけど人手不足だし集められるかな？
もっと緩いオブジェクト指向でいいと思う。
こんなガチガチで上手くいったプロジェクトってあるの？
>>377
犬のしょんべんに当たっちまったな
自分以外の奴がソースコードを読めないようにする工夫だそれ
元凶がインターフェースで
継承してあるすべてのクラスのインスタンス作成箇所全部をチェックしないと処理がわからない チンポについて教えてください。
チンポをインスタンス化して、引き数にマンコを持つキンタマメソッドの戻り値
ザーメンを取得したいのですが、コンパイル結果がフニャチンになります。
どうしたらいいですか。
>>377
それガチガチなんじゃなくて設計や実装が下手なだけ >>377
ほんとにガチガチならそのクラスを作ったやつの後任者～お前の前任者までの間で間違ったクラスの使い方が広まったんだろうよ “これはこれをする奴”と一目でわかって
処理飛ばした後はそいつがよしなにやるから
細かいことは考えなくていい。
というのがオブジェクト指向の売りだから
「コイツはなにやってんだよ！」と処理追うのに混乱するようなのは
基本を履き違えてる気はする。
変なとこから流れてきた自称プログラムのプロがやりがちな
暗号みたいなクラス名とか
だいたいインターフェースが元凶だって
実行してみないとわかんねーし
インターフェースが現況って言ったってクラス名とメソッド名である程度目的はわかるようになってるんじゃねえの
それができてないなら単なる設計ミスじゃん
>>386
バカの作るインターフェースは思いつきで入れた汎用性を実現するものだからそもそも設計書に書かれない >>387
そういうもんか
そういう用途で使うべきではないわな >>384
手続き型みたいなのでバグ探すと、大体1ファイルの中見て
処理の流れもその中だけ追えば良くて
シンプルな流れだからチョイチョイってできるけど
完全なオブジェクト指向だと、
｢この値を設定してるのは、ここ、
…、
じゃなくて、コイツ他のとこで設定してるのか～、
ここ？
あ、もっと上か～｣
みたいにあちこち辿っていくから
あんまり良いことに感じないけど。
影響範囲も広いし。
考えなくていいのは、製造するときに何が何をすると
ハッキリと決められてる時で
どこにバグあるかとか見るときは
｢ここだろう｣と最初に思ったとこではなかったりしなくね？
設計が難しいなら、
バカでもできる簡単な設計で済む手続き型最強な気がする。 >>389は詳細設計書位しかなくて、クラス図とかもろもろないケースの話で。 >>389
ガチガチのオブジェクト指向ならその値がどこで設定されたなんか関係ないよ
今受け取った値に対しての動きをするだけ ワンインスタンス内ではメンバはグローバル変数みたいに振る舞うから
継承多くなるとっていうかある時点でクソ言語になるんだよね
>>389
＞>>384
＞手続き型みたいなのでバグ探すと、大体1ファイルの中見て
＞処理の流れもその中だけ追えば良くて
＞シンプルな流れだからチョイチョイってできるけど
これはむしろオブジェクト指向の特徴だね
＞完全なオブジェクト指向だと、
＞｢この値を設定してるのは、ここ、
＞…、
＞じゃなくて、コイツ他のとこで設定してるのか～、
＞ここ？
＞あ、もっと上か～｣
これは典型的な手続き型のデバッグだよね
もしかしてスレ加速を狙ってわざと間違えてる？ >>393
それ明らかに俺から見て逆だわ
処理に対して一旦オブジェクトで纏めるオブジェクト指向がそこの辺シンプルになるわけねーだろチンカス >>394
あ～
うん
まあそういう人も居るよね
存在を否定はしないよ
民主主義国家の人民は自由であるべきだ >>395
393で言いたいことはまぁわかる
けど自分が多数派であると思い込んでるのはおかしい
おまえの中の「～べき」って論は他人に通じないので押しつけないで >>396
いろんなコミュニティに顔だしてみなよ
リアルが無理ならネットコミュニティだけでもいい
>>393が常識的な認識だよ 呼び出し階層が深いだけで可読性が低いなら抽象化が下手なだけで、オブジェクト指向に限った話じゃない
呼び出し元や定義にジャンプする機能のないエディタ使ってると辛いとか
DIでコンフィグから実装を注入してると追うのが面倒くさいとかなら分かる
>>397
おまえの中ではそうなんだろうな
繰り返すが393で言いたいことはまぁわかる >>398
> どこにそんなの書いてあるんだよ
いろんなコミュニティ いろんな考えかたの人がいる
それは認めるべきだ
オブジェクト指向が好きなやつも手続き型が好きなやつもみんな自由と権利を持っている
でもここはオブジェクト指向のスレなので
手続き型に興味があるなら手続き型スレで議論を深めればいいんじゃないかな？
手続き型システムの設計 1 [無断転載禁止]©2ch.net･
http://mevius.2ch.net/test/read.cgi/tech/1500282714/
オブジェクト指向がわかりにくくて嫌いだからといってもオブジェクト指向のコミュニティを荒らしてもいい理由にはならないだろう
住み分けは大事だ >>401
なんだそのキチガイコミュニティ
2～3個リンク貼ってみろ
潰してくる ガチガチに手続き型で組んだプログラムなんて見とうないわ
あちこちに飛ぶから云々ってマジでいってんのか
あちこち飛ぶからいいんじゃねえか
飛ばなかったら全ての処理が一箇所に集まってパンクするだろw
飛び方がキレイな木の枝のようになっていればよい
枝から枝へモモンガのように飛ぶ処理が入っていたら地獄だ
というか、オブジェクト指向はクラスに責任を持たせることで
責任が遡ったり他へ波及するのを防ぎデバッグも局所化して容易にする思想なので
どこかで一目でわかるように「この値を設定する一意の責任を持つのはおまえ」と
責任を持った誰かがいて、正しく作ってればそこから周りにゴミが飛び散るはずがないので
＞｢この値を設定してるのは、ここ、
＞…、
＞じゃなくて、コイツ他のとこで設定してるのか～、
＞ここ？
＞あ、もっと上か～｣
とか、それのどこがオブジェクト指向だ。>>393と同じ感想 >>410
意味わからんけど
どんな使い方してんねん 素人がインターフェースを使うと実装に強く依存してしまうことがある
実装クラスの内部的な挙動を前提にするとかね
おまえらおしゃべりしたいだけだろ
リアルで交流しろや
>>408
なに？ お前、モモンガ先輩の事ディスってるの？ しっかり役割を分担しないとオブジェクト指向の利点をいかせないと言うことか
>>416
利点も何も役割分担できてないならそもそもオブジェクト指向じゃないよ >>418
いやだから、インターフェイスってそういうもんじゃん オブジェクト指向の設計の話をしてると
このクラスはこのことを知ってるべきだ、イヤ知らないべきだ
なんて話がよくあるが
アスペの代表的な特徴として自分の視点でしか考えられない
ということかあるのでアスペにOOは無理
>>421
確かにアスペに取り扱いは難しいな
だが言うなればオブジェクト指向はアスペクラスの集合体だからアスペ視点は大切 >>422
1人1クラスずつ作るのか
他の人のクラスを利用することがないからゴッドクラスが乱立するな
最悪だ そういう現場は多いよ
見積もりしやすいとかいう頭が悪い理由で、画面を作業単位にして割り振るから
神画面クラスがいくつも出来上がる
挙げ句の果てにその見積もりも根拠なしの適当な数字ときたもんだ
>>426
説明できないと何の論拠も無く相手をアスペで片付けるんだね >>425
あるな
メンテの費用たくさん取れるからいいんだよとか言い出す始末
勉強してるのがバカバカしくなる おまえらアスペとかADHDとか言ってるけど
せめてググってwikipediaや解説サイトぐらい見れば話が合うような言葉を選んでくれ
10人にADHDの説明させたら10通りの回答が出てくる現状では
技術的な議論に使う言葉じゃないと思うんだわ
見積もりは出したふりでいい
客も見積もりに意味ないことは分かってるから上司への説明など適当にうまくやってくれる
その辺は阿吽の呼吸ですよ
関わるのも面倒だからそういうのはメンバーにいない方がマシ
>>427
自分が誰よりも上位にあることを見せかける上で便利だからねアスペ認定は ここオブジェクト指向スレなんですが？
アスペがアスペを叩いていて笑う
>>436
オブジェクト指向にフックを仕込めれば十分であることがわかった
アスペクト指向は「指向」ではなく、オブジェクト指向設計に
組み込む一種のパターン そういや一時期流行ったな
実装のまずさを誤魔化す手段という認識しかなかった
デコレーター
属性バリデーション
シリアライズ
apiプロキシ
…
aopは意識しないだけで結構使ってるな
メッセージリソース管理クラスの素晴らしい設計を教えてください
void SomeAppMethod() {
// do something
view.AddMessage("MSG_0123")
// do something
}
こんな感じでリソースIDがシステム中にばら撒かれて制御不能状態になっています
メッセージリソースを管理するクラスを作って解消したいのですが良いAPIが決まりません
>>441
OOPではリソースIDのような物理的な情報は隠蔽しなければならない
public interface ILowLevelMsgManager {
string GetMsg(string msgId, params object[] placeHolderArgs);
}
public interface IMsgManager {
string GetHogeMsg(); // ほげええええ
string GetFugaMsg(int num); // ふがふが{num}ふがふが
}
public class MsgManager : IMsgManager {
private ILowLevelMsgManager llmm;
public MsgManager(ILowLevelMsgManager pllmm) { llmm = pllmm; }
public string GetHogeMsg() { return llmm.GetMsg("MSG_0001"); }
public string GetFugaMsg(int num) { return llmm.GetMsg("MSG_0002", num); }
} >>443
それになんの意味があるのかさっぱりわからんな
メッセージなんてでかいプロジェクトだと500個とか行っちゃって
詳細なんかわかんなくていいんじゃないの？
もうメッセージ一覧で確認することは諦めろよ的な メッセージでこれまで見た中で一番多いのは3000だった
そこまで構えろとはいわんけどそういう性質のものではある
ソースの該当箇所に一つ一つ置いていく手間は省略できない
メッセージリソースIDとメッセージが照合できればそれでその作業は終わりじゃねーのか？
後、何を管理してもらいたい？
>>444-445
ハードコードされた人間可読性ゼロの3000個のIDはそう簡単には管理しきれないと思うが
まあ君の人生だしどう時間を使おうと君の自由だね
私はしっかり管理して時間を節約するよ 客の都合でID体系変更になってリテラル全部調べて置き換えて再テストしたトラウマ
する価値ないと思ってもとりあえずでいいから抽象化しておいて損はない
>>446
いやぁ、だからさ
ソースのエラー箇所に自動配置なんかできないんだからそこは300だろうが3000だろうが30000だろうが手動じゃん
IDとエラーメッセージが組にさえなってたらどういう構造にしようがやることかわんねーよ的な visualstudioのjaファイルとかその辺の仕組み使えばいいんじゃないの？
ローカライズするならやっとかないと死ぬよ
rm = new ResourceManager(locale)
un = rm.get("property.name.user-name")
msg = rm.get("validation.error.max-length", un, 10)
print msg # ユーザー名は10文字以下で入力してください
スッキリ
>>449
それじゃ可読性が低すぎるって言ってるの
暗号みたいにIDばらまかれても保守できないよ
それに>>447のようにIDとメッセージの対応が変わることもある
手間が変わらないなら1つ抽象化層を設けてコードを保護すべき >>452
いやぁでもこの数やる気にはなんないなぁ >>452
体系が変わるのはまた別の話かな
もう完全に仕様変更なわけで落ち着いて対応できる このケースで余計に一層設けるのはメリット薄いんじゃない？
って言いたい
>>441
C#なら素直に.resx使う
少なくとも存在しないIDを使った場合に
コンパイルエラーになる仕組みを使う
種類ごとにグループ化(階層化)して管理しやすくする
メジャーなフレームワーク参照したら分かると思うがMSG_0123みたいな命名自体も悪手
もうどうしようもないのかもしれんが >>456
もう数からいってメッセージのうちのどれ？って判別できる量で終わらんと思うし
IDの命名規則なんて些細なことよｗ
俺の経験で言うと コードジェネレータがいいよ
メッセージID, メッセージテキスト, パラメータ数
Hoge, ほげ, 0
Fuga, {0}はふがです, 1
これをエクセルで管理してメッセージ管理クラスを出力
class MessageManager {
public static string Hoge() => "ほげ";
public static string Fuga(object p0) => string.Format("{0}はふがです", p0);
}
んでデータ数が増えてきたらエクセルをやめてデータベースで管理
エクセルを使えばお客様もお喜びになられるので一石二鳥
>>457
メンテナンス性を犠牲にしても
命名負荷を下げたいという意思決定をしてるんならいいんじゃないの
神クラス・神テーブルと同じアプローチだけど
物によってはそれが適切な選択の場合もあるんだろうから >>441
> メッセージリソース管理クラスの素晴らしい設計を教えてください
メッセージリソースなんてものを作らない。
view.AddMessage("あーがこーでどうなりました")
って日本語で書けばいい。
多言語化したいなら、gettextなどの言語やフレームワーク標準の
多言語化ライブラリを使えばいい話。
その場合は、英語でメッセージを書いて、日本語化するってことが
よく行われるが逆でもいいだろう。 >>373
責務指向良いね
ゲームはオブジェクト指向でしっくり来るかも知れんけど業務システムだとピンと来ない ゲームをオブジェクト指向で作ると作りにくいよ
相互作用の処理が多過ぎてオブジェクトに閉じない
それは設計どころかゲームそのものとしての落とし込みが不十分
ゲームとか一定のルールに則った動作をするだよ
>>462
メッセージ&イベントだらけになって死ぬな
ゲームは関数型が至高 「オブジェクト指向だからステージの俳優が全員なんか言ってきて
カントクは一人一人対応なんかしてたら死ぬな！！www」
…いや、間違った理解をした奴はまあそういうドマヌケやらかしがちだが
普通はステージステータスに集約されて、ディレクターは
そのステータスを見て上から必要な個々に指示が送られるように作るからね…
ゲームは油断するとすぐにキャストや型判定だらけになってしまう
特定のクラス同士の時だけ発生する相互作用とか
お客さんが属性バリデーションも他のバリデーションフレームワークも使っちゃダメって言うんだけど
どうすれば楽にバリデーションできる？
言語はC#
テキストリソースは全てDBで管理されている
ロケールによってエラーテキストを変えなければならいとする
>>468
普通に作る以外にない
ちなみにダメって言う理由は何なの？
あとバリデーション自体と
バリデーション結果に応じたエラーテキストの選択は
分けて考えたほうがいいよ >>469
属性やフレームワークは設定方法がよくわからないのでメンテナンスの時に困るから
ひたすら単調にif文をズラズラと書いてるんだけどシンドイ
項目数が100近いPageもあってそれぞれが何種類かのバリデーションを行うからバリデーションだけで数百行のメソッドになることもある >>470
xmlでルール書くやつは敬遠されるのは理解できなくもないが
単純な属性ベースは分かりやすいしメンテしやすいのにね
楽しようとすれば結局自前で簡易的なフレームワーク風のものを作ることになる
あまりにも数が多いならコード生成という選択肢も >>470
ライセンス的に問題がないものをコピーすればいい >>470
Frameworkを使わないc#ってどんだけマゾなの？ランタイム自分で書いてんの？ >>470
そんな理由にならない理由に従おうとする方がバカ 今回みたいな例だとライブラリを使わないで自作するとしたら
使った場合に比べて何倍ぐらいの金額を請求する？
バリデーションが全体の工数に占める割合がわからないとなんともいえないけど、数倍なんてなるわけないだろアホ
どんだけバリデーションばっかやってるプロダクトを想定してんだよ
客に費用の話をするとき、「通常この規模だと20人月ですが、バリデーションライブラリが使えないので+50人月かかります」とでも言うのか
はぁ？ 増えた分の請求は当然するだろ。当たり前のことを当たり前にするだけだぞ
>>476
なんでいきなりフレームワークじゃなくてライブラリの話になってんの？ >>476
既存のフレームワーク使わずに自作する方が工数膨らむに決まってんだろ
カプコンレベルじゃないとスキル的にも厳しい ごめん勘違い
工数の膨らみ方が半端なさ過ぎて非現実的ってのが言いたかった
ひとまず使って組んで元の処理コピーして置き換えちゃえばいいんちゃう？
バリデーションのソースってあんでしょ？
>>479
バリデーションのフレームワークなんてないでしょｗ >>483
フレームワークの一部としてバリデーションがあるやろ ごめん、何言ってんだかよくわかんないんだけど、
まず、>>468のバリデーションって、一体何に対するバリデーションの話してるの？ if (!validateRequired("#foo")) {
var msgFormat = getResource("error.required");
var label = getLabel("#foo");
addMessage(msgFormat, label);
addCss("#foo", "input-error");
}
以下100項目繰り返し
これ以上簡潔で保守性の高いバリデーションが存在しない件
OOPは物事を無駄に複雑化するばかりで役に立たん
>>487
バリデーションとメッセージとUIを一緒くたにするな
どこが保守性高いんだか、見づらいだけだろ >>487
それは普通に抽象化できるだろ
そんなん100個も繰り封ﾔしてたらサブャCボ出るわ バリデーションはYAMLで定義するのが一番だって最近気づいた
御託はいいからコード書いてみれば？
俺のコードより明確で保守性の高いコードをかけるとは思えんが
こーゆー上から目線なやつは自分の思い描くもの以外は全部クソって発想なのでめんどくさい
そもそも俺のコードは判定と表示が綺麗に分かれてるし
バリデーション処理はexcel表から生成するものだよ
素人は手書きするらしいけどね
プロはこんなめんどくさいコードは書かない
>>498
簡単だよ
|画面ID|セレクタ|コマンド名|ルール|
の一覧表をVBAマクロのループで回してjavascriptのコードを生成してjsフォルダに置く
それだけだ
うちの会社では20画面程度のシステムを扱うことが多いけど、このマクロのおかげで全画面の検証処理の実装が1人日でできてしまう
一覧性も高くそのまま仕様書やテストケースにも使える優れものだ コピペプログラマは余計なコードを増やしてくれるな
foreach(validate as entry){
if (!validateRequired(entry.name)) {
var msgFormat = getResource(entry.resource);
var label = getLabel(entry.name);
addMessage(msgFormat, label);
addCss(entry.name, entry.clazz);
}
}
簡単に100分の1になるだろ
validateもプログラムからデータにしたら保守性あがるだろ
Modelからvalidateを収集するようにしてビジネスロジックを集約してもいいけど
今更そこまで設計変えるのは愚策か
>>500
これじゃ何やってるかお客様がわからないだろ
素直にエクセルにしろって お客様がソース読むのかよ w
条件をお客様が決めるならExcelでもらって>>500のentryを生成するツールを作ればいいだけ 結局コード生成するんじゃないかwww
なら最初からコード生成する前提で余計な手書きコードは書かない方がいい
プログラミングの基本すらわかってないのかよ
>>502
> 条件をお客様が決めるならExcelでもらって>>500のentryを生成するツールを作ればいいだけ
発想が逆。YAML形式などで条件を書いて
必要ならばExcelに変換する。
Excelなんてサイズが無駄に多すぎて差分の比較もできないから
バージョン管理は事実上無理だろ YAML形式の何が良いかというとシンプルで見やすいから
お客様が直接読み書きできるってことだな
下手なCSVファイルよりもメンテナンス性が良い
まあそのデータなら差分出したきゃ
CSVで出して比較できそうだけどな
Excelでも管理できてるなら別にいいと思うぞ
客や開発メンバーのリテラシーレベルに合ってるなら
無理に違うフォーマットを強要する必要はない
openxmlとか使えば差分比較だけならできる
むしろルールと処理を密結合させても平気な神経のほうが理解できない
そのうえプロを自称してドヤるww
>>509
客にExcelを "ルール通りに" 使わせるという
リテラシーレベルをもとめるな
勝手にフォーマットを変える、勝手にセルを結合する。
どこからかコピペした結果おかしくなって直さない
追加分とかいって差分を送りました。そっちで結合してください
とか、毎回人手で対応しなきゃならない作業が発生するぞ。
こっちで決めた使い方のルールを守ってくれやしない > openxmlとか使えば差分比較だけならできる
むり、見た目同じように見えても、
レイアウト属性など関係ない情報の
大量の差分までできて管理できない
>>511
属性情報は無視してdiff出せるよ
色変えたとか罫線追加したとかそのレベルの差分確認したいとなると
専用ツール入れないと実用レベルでは使えない ヴァリデーションフレームワークってどれも中途半端だよな
ちょっと複雑なヴァリデーションをしようとすると適用不能になる
しょうがないからカスタムコードを書くことになるんだけどフレームワークとケンカし始めるからフレームワークは規約で禁止って流れになる
日本の厳しい要件についてこれる柔軟性の高いフレームワークは無いものか
>>510
その辺は上の自称プロさんならVBA使ってルール守らせるExcel作るだろ
俺は別にExcel推奨したいわけじゃないぞ >>506
意味わからん
YAMLで書ける客がどれだけいるんだよ w
そもそも客がYAMLで書けるならExcelに変換なんて要らん、そのままソースに変換するなりすればいい
要件によっては実行時にそのまま読み込んでもいいかも知れんし
まあ>>500程度ならcsvとかで充分だと思うが >>510
> とか、毎回人手で対応しなきゃならない作業が発生するぞ。
どんだけ低レベルの客と付き合ってるんだよ w >>512
例えばこの例だと行を一行追加して、A2にあったWorldが
A3に変わった時の差分はこんなふうに表示される
http://blog.modd.com/entry/2016/01/26/125206
diff -u a.txt b.txt
--- a.txt 2017-10-14 14:16:59.481494825 +0900
+++ b.txt 2017-10-14 14:17:20.601528128 +0900
@@ -5,6 +5,12 @@
</row>
<row r="2">
<c r="A2" t="str">
+ <v>OOXML</v>
+ </c>
+</row>
+<row r="3">
+ <c r="A3" t="str">
<v>World</v>
</c>
</row>
Worldがもともとrow r="2"、c r="A3" だったわけだが、たった一行挿入することで、
2行目以下の、"全ての行データに対して" このようにrowとcが変化するわけだよ。
それで差分を管理できるわけ無いだろ。 >>515
> YAMLで書ける客がどれだけいるんだよ w
こっちでこんな感じで書いてくださいっていうだけ。
それはExcelと同じ。
違うのは、Excelでは条件を指定した所で
見えない情報（フォーマット情報など）が
大量に埋め込まれるということ。
そしてその見えない情報を正しく修正するのが大変だということ >>516
> どんだけ低レベルの客と付き合ってるんだよ w
逆。客のレベルがExcelを無駄に使えるから
セルの結合とか色を変えたりしてくる。
Excelはできることが多すぎるんだよ。
余計なことをなんでもできてしまう。 >>513
> ちょっと複雑なヴァリデーションをしようとすると適用不能になる
普通はちょっと複雑なバリデーションを書くための方法がフレームワークに用意されてる。
それに、ちょっと複雑なところだけ別にやればいいだけ。
100個のうち1個のマイナーケースに対応できないから、
100個すべてめんどくさい方法で作りましたとかアホでしか無い。 >>520
日本の業務アプリを甘く見過ぎだろ
カスタムコード書きまくらないと対応できねえよ
アホみたいにシンプルなUIしか書かなくてもいいWeb屋はスキル要らないし気楽でいいよな >>521
じゃあバリデーションのすべてがカスタムコードである例を教えてください 例えば郵便番号のバリデーションが
カスタムコードとか言いそうで笑えるｗ
そして郵便番号を使うたびに
同じバリデーションをコピペしてるんだろうな。
普通は関数にしてフレームワークに登録すれば終わり
あとは同じバリデーションを使いまわしできる。
あぁ、当たり前だけど範囲チェックや型チェックや正規表現チェックとか
単純なものだけではなく、カスタムバリデーションや条件付きバリデーションなんかも
フレームワークの基本機能の１つだと先に言っておこう
>>518-519
> こっちでこんな感じで書いてくださいっていうだけ。
えっ？
YAMLの書き方から教えるのかよ...
Excelでフォーマット守れって言うこともできない客にYAML書けるとか無職の妄想乙 w 日本の業務アプリを作っているところがアホなのは、
バリデーションが正しく機能しているかは
アプリを実行して画面からぽちぽち実際と同じ使い方をして
検証していることなんだよな。同じ内容のバリデーションであっても
項目ごとに検証する。それがテスト時間を無意味に増やしてしまっている。
本来はバリデーションのテストは種類ごとに１つ（すごく当たり前だがｗ）
そして、画面の項目ごとに、想定しているバリデーション名が
設定されているかを設定ファイルを見て確認するだけ。
実際に動かしてテストはしない。
>>517
試したけど俺の環境では↓こうなるよ
diffだけなら十分実用レベル
$git diff
diff --git a/book.xlsx b/book.xlsx
index c75fc9a..6215aa2 100644
--- a/book.xlsx
+++ b/book.xlsx
@@ -1,5 +1,6 @@
Sheet1
Hello
+ OOXML
World >>525
> YAMLの書き方から教えるのかよ...
YAMLの書き方はExcelよりも簡単だよ。
Excelは知らない人が使いこなすためには
数週間とか数カ月かかるが、
YAMLだとフォーマット用意して、
これと同じように書いてくださいで説明終わり。
Excelでフォーマットを守れないのは、
これと同じように書いてくださいと言っても、使い方が難しいから。
俺の母親は、文字の自動補間機能のせいで「1」と入力しようと
しても「10」と補完されてしまって困っていたな。 >>527
じゃあ今度はある程度データを入れて、同じ内容のセルを結合する前後で
ためしてみそれがどう見えるかを確認したら絶望することになるから ちなみに補足しておくと、>>529はxlsxを直接比較しているのではなく
xlsxをテキストに変換してから比較している。
その時にフォーマット情報などいろいろ抜け落ちる。
だから「取り消し線のところは無視してください。」なんてのはわからない。
このようにExcelはなんでもできてしまうから、
重要な情報が抜け落ちる所に書かれてあった時に比較できない。 >>528
Excelの使い方が難しい？
YAMLがきちんと書けてExcel使えない奴なんて見たことないけどな
お前のおかんはYAML書けるのか？ w >>526
俺はやるべきだと思うなぁ
だって外人のアプリってそのせいなのかどうなのか知らんけど
よく動いてないじゃんｗ xmlはプログラマしか編集できない上に
ファイルがでかくなると読み込み速度ヤバイので駄目だよ
俺が昨日書いた検証処理の一部
実際にはこれの数十倍の検証ルールがあると考えてほしい
フレームワークで簡単にできるなら教えてほしいおねがいします
webアプリ
テーブルをバリデーションする
列は4つでそれぞれinputを持ってる
typeは順に「checkbox, text, text, text」
検索でバックエンドから取ってきたデータがこのテーブルに表示される
これを手入力で編集してバックエンドに保存する
再検索できるが検索時にはバリデーションしなくてよい
保存するときはバリデーションを実行する
メッセージはローカライズすること
すべてのテキストリソースはバックエンドで管理されている
1列目のcheckboxがOFFの行はバリデーションしなくていい
2〜4列目のtextがすべて未入力の行はバリデーションしなくていい
2, 3列目が空白の場合エラー
2, 3列目が整数でない場合エラー
2, 3列目の合計値が1000を超えたらエラー
1列目のcheckboxがONの行の2, 3列目の合計値が10000を超えたらエラー
4列目はオプション
10文字以上の場合エラー
入力された文字列がバックエンドに登録されていない場合エラー
エラーメッセージは重複を排除して昇順に並び替えて所定の ul の子要素として追加する
エラーがあった入力項目は背景色を赤くする
同じ行で1つでもエラーがあった行は罫線を赤くする
>>533
> だって外人のアプリってそのせいなのかどうなのか知らんけど
> よく動いてないじゃんｗ
外人のアプリって何？Windows？Linux？MacOS？ >>537
どうでもいいけど、列目～とか言って時点で、画面と密結合してんなーとしか思えんなｗ
列があれば行もあるんだろうけど、一行単位で処理してるようだから、
一行が、一クラスの一インスタンスと考えればよいだろう
1000超えたらエラーなのか10000超えたらエラーなのか分からんが。
画面表示周りにビューの仕事でこれはバリデーションではない。
バリデーション結果オブジェクトを見てビューで表示さればいいだけ（何度も言わせないように）
長くなったのでコードは次のレスに書く class Row
include ActiveModel::Validations
def col1_condition; end
def col2_value; end
def col3_value; end
def col4_text; end
def condition;
col1_condition && col2_value.present? && col3_value.present? && col4_text.present?
end
def col2_plus_col3_number
col2_value + col3_value
end
// ↑ここまでは単なるクラス定義
//↓ここ以下がバリデーション
validates :col2_value numericality: true, presence: true, if condition
validates :col3_value numericality: true, presence: true, if condition
validates :col2_plus_col3_number less_than_or_equal_to: 1000, if condition
validates :col2_plus_col3_number less_than_or_equal_to: 10000, if condition
validates :col4_text; maximun: 10, if condition
validate :col4_registered
def col4_registered
// 入力された文字列がバックエンドに登録されていない場合エラー
end
end
× validate :col4_registered
○ validate :col4_registered, if: condition
っていうか全部 if の後の: 付け忘れてたｗ
>>531
だからそれは意図して属性情報は差分比較しないようにしてるからじゃん。。
なんなんその言いがかり
セルの結合もデータ的に何を意味してるのかVBA使うやつなら当然知ってるし
データとして使うExcelシートなら書式設定は変更されないようにロックするだろ
その辺のリテラシがないならExcel使うってのは選択肢にはならないわな >>543
すべての属性情報が無視していいとは限らないからね。
属性情報として重要な事が書かれているかもしれない。
そういう無視して良いのがないかわからないのがExcelの欠点の１つ
Excelになれている人ほど、余計な工夫をしてくる。 >>541
これはなんの言語ですか?
JavaScriptだとどうなるのでしょうか?
10000を超えないのは複数の行について合計した時の話です
メッセージやCSSの処理はどうすればいいでしょうか？ >>545
Ruby & Rails
JavaScriptはしらん。けど大差ないものは作れるだろ
文法上の制約があるとしてんもこんなふうになる程度
validates("col2_value", {numericality: true, presence: true, if: "condition"})
> 10000を超えないのは複数の行について合計した時の話です
一行ごとに保存できるのであれば、保存する時に
この一行を保存するときに10000を超えるかどうかを調べればいい
一行ごとに保存できない、つまりまとめて保存するならば、
一行に相当するオブジェクトに含まれる配列として
テーブル全体を持っておき、そのテーブルの数値の合計を調べれば良い。
> メッセージやCSSの処理はどうすればいいでしょうか？
んなもん、バリデーション結果を返して、そこに含まれるerrorsを
画面に表示すればいいだけ。ローカライゼーションは別の話。 >>546
なるほど
なんとなくわかりかけてきました
肝心のエラー情報はどうやって、どのような形式で取得しますか？
検索や保存など処理によって検証内容が異なる場合は似たようなクラスを２つ用意するのでしょうか？ > 肝心のエラー情報はどうやって、どのような形式で取得しますか？
フレームワーク次第なんだんだからそのやり方に従えばいい
> 検索や保存など処理によって検証内容が異なる場合は似たようなクラスを２つ用意するのでしょうか？
似たようなもの＝同じではない＝違うもの
違うなら別々に用意しなければいけないし、
100%まったく同じならば、使い回せばいい。
一部が全く同じならば、同じ部分だけつかいまわせるように切り出せばいい
絶対にやってはいけないのは、違うところがあるのに
似ているからという理由だけで違うものを使いまわすこと
そんなことをするとある修正が全く無関係な所に影響を及ぼしてしまう。
異なるなら別のものを作るのは当たり前の話だ。
>>544
> すべての属性情報が無視していいとは限らないからね。
限るだろ ⇒ >>500 のデータなんだから w あとなぁ、コピペはいけないってことの意味を勘違いしてるやつが多いんだよな。
単語、文字列をコピペしたらいけない。ファイルをコピペしたら
いけないって勘違いしてる。
コピペしたらいけないのは処理だってーの。
処理はテストするものが定義はテストする意味はない。
定義でするべきなのはテストではなくて確認
確認は目視でもOKなんだよ。
バリデーションなんてほぼ定義にできてしまうのだから
テストする項目にはならない。確認する項目。
だからYAMLに分離して、技術者じゃなくても確認できるようにしておけば良いんだ。
>>548
ちなみにrubyだとバリデーション結果はどうなってるんですか？ >>549
問題はExcelには>>500のデータ以外の情報も自由に入れられてしまうところなんだよ。
そしてそれがわかりづらい。 >>551
RubyじゃなくてRailsな。バリデーションはRailsというフレームワークの一機能
バリデーション結果のオブジェクトの中に
errosってのがあってそこに項目ごとにエラーメッセージが入ってる。
またバリデーション結果のオブジェクトにはvalid?、invalid?メソッドがあって
全体がバリデーションでOKだったかどうかもわかる。 >>553
どの項目でエラーが出たかはわかりませんか？
背景色を変えるには入力項目のidとrubyオブジェクトのプロパティとのひも付けが必要だと思いますが
ここも粗結合にしたまま対応できるんでしょうか？ >>541
この場合のcheckboxは更新対象を示すフラグっぽいから
2~4列目のモデルの要素とは別にしたほうがいいんじゃないかな
ONになってる行のコレクション対してバリデーションすればいいので
if conditionは全部消せる >>554
だからerrorsオブジェクトの中に項目ごとにエラーが入ってるって言ったろ
> 背景色を変えるには入力項目のidとrubyオブジェクトのプロパティとのひも付けが必要だと思いますが
いらねーよ。
どうせエラー画面がでたら、エラーが出たその項目の値を表示するだろ？
その項目のすぐ下にでもエラー情報だせばいいだろ。
あ？id？ エラー情報の表示にidなんていらねーからな。
まさかと思うが、CSSに全項目書いてたりしないよな。
それならclass使え。アホらしいから >>555
そこらへんはどうでもいいやｗ
重要なのはこの程度でカスタムコード書きまくらないと対応できないとか
思っていたことがはっきりしたってだけ
で、俺の意見はここからさらに先で、Railsのバリデーションコード
あの程度の情報量であれば、YAMLに簡単に外だしできるので、
外出して、客にもレビュー可能にして、価値の低いテストを減らしたい。
YAMLにすればフロントエンド側（JavaScript）でも再利用できるだろうし。
なんでもかんでもクラスに定義するのが良いとは思わないな。 その先はないので程々にした方がいい
設定ファイルでバリデーションするアイデアはJavaとか他の言語が大昔にとっくに通過していて
世界中でこれは使い物にならんと判定されたものだよ
バリデーションすなわち入力検証をプレゼンテーションから切り離して考えるのもバカバカしい
入力検証はViewあるいはViewModelに属する処理だからプレゼンテーションに入るのが正解
ドメインモデルに入力検証をやらせるのは愚かとしか言いようがない
> 設定ファイルでバリデーションするアイデアはJavaとか他の言語が大昔にとっくに通過していて
それはXMLが失敗の原因だった。
XMLにはタグや属性という技術者しか知らないものが
あるからだめだったんだよ。
>>559
> 入力検証はViewあるいはViewModelに属する処理だからプレゼンテーションに入るのが正解
YAMLにすることでそれも実現できる
バリデーションは、プレゼンテーションだけのものではない
プレゼンテーションでもドメインモデルでも使われるものだ 更に言うならば、バリデーションはフレームワークではなく
言語仕様に組み込むべきものだよ。
本質的にはD言語の契約プログラミングと同じものなんだから
>>560
違う
モデル定義とバリデーション定義が離れすぎていること
コンパイルできないから開発環境の恩恵をうまく得られないこと
バリデーションを書くのは開発者であるが開発者に馴染みのある言語はXMLやYAMLではなくJavaやC#であること
これらが問題点 >>563
> バリデーションを書くのは開発者であるが開発者に馴染みのある言語はXMLやYAMLではなくJavaやC#であること
あんたはバリデーション処理とバリデーション定義をごっちゃにしてる。
バリデーション処理は動くコードで書くが、
バリデーション定義は動くコードではない。
JavaのXMLなんかも動くコードではないから
これは定義であり、定義の内容をJavaやC#で書く意味はない。
だってただのデータだぞ？ハッシュで持たせればいい程度の情報。 >>559
俺もその意見に賛成かなぁ
画面が変わったら変わった画面用のチェックが必要になってる気がするわ >>561
違う
プレゼンテーションレイヤではオブジェクトが不正な状態を受け入れることが前提
不正な状態を検知する処理がバリデーション
ドメインレイヤではオブジェクトは不正な状態は受け入れない
プロパティの不正な値をセットしようとした瞬間に例外
メソッドに不正な引数を与えた瞬間に例外
これはバリデーションではない
ドメインレイヤでは契約を使う >>541の例で言えば
validates :col2_value numericality: true, presence: true, if condition
validates :col3_value numericality: true, presence: true, if condition
validates :col2_plus_col3_number less_than_or_equal_to: 1000, if condition
validates :col2_plus_col3_number less_than_or_equal_to: 10000, if condition
validates :col4_text; maximun: 10, if condition
validate :col4_registered
この部分がバリデーション定義。
簡単にYAMLにできるし、客が検証したい部分でも有る。
numericalityの内容とかconditionの内容がバリデーション処理（の一部） >>566
> ドメインレイヤではオブジェクトは不正な状態は受け入れない
> プロパティの不正な値をセットしようとした瞬間に例外
> メソッドに不正な引数を与えた瞬間に例外
> これはバリデーションではない
バリデーションに引っかかった結果をどう表示するか？が
プレゼンテーションでやるべきこと。
バリデーションそのものは使いまわすことができる。 >>566
ctrl+vで貼った1GBテキストとかメモリに保持すんの？ >>564
それはあなただけが感じる特殊な感覚だよ
世界中のプログラマは設定ファイルを捨て去り属性やアノテーションを使うようになった
XMLよりYAMLの方が多少マシという点は認めるが上記の手法に比べればどんぐりのせくらべといったところだ >>570
> 世界中のプログラマは設定ファイルを捨て去り属性やアノテーションを使うようになった
設定ファイルを捨ててYAMLにしたの間違いだろｗ 設定をYAMLではなくソースコードに埋め込むのを見てみたいもんだがｗ
お前ら、喧嘩するな
どこに持とうがチェック項目は増えても減ってもいないんだぜ
だったら一番やりやすい画面かな
>>573
いや増えてる。画面でやると画面ごとにバリデーション処理が増えてしまう。
だから数を減らすにはより中心であるモデルで行う必要がある。 ファイルに外だししたからチェックしなくていいですなんて
んなわけねぇだろ
今時エロ本の竿役だってそんなこと言わねぇよ
>>572
JavaのBean ValidationやC#のDataAnnotationsを調べてみればいい
モデルとバリデーション設定を分離して管理する意味がないとわかるはずだ >>552
低能相手ならそうかもな
御愁傷様としか言えないけど w >>575
> ファイルに外だししたからチェックしなくていいですなんて
> んなわけねぇだろ
そんなこと言ってないよｗ
バリデーションという単純な部分を
外だしすると誰でもチェックできるようになるよ。
そもそもExcelでやっていたことだからね。
Excelという使いづらい形式がYAMLに変わっただけ
誰でもチェックできるってことの意味がわかったかな？
あ、YAMLに変わってプログラムからそれを
そのまま使うってところも違うか。 YAMLが誰でも読み書きできると主張しているのはプログラマだけという事実について考える必要があるようだ
エクセルは誰でも読み書きできる
これはプログラマ以外のステークホルダーも同意している
xmlはパンピーには無理
スコープなんて意識できるわけねーし
っていうか俺でも辛い
xmlを編集できるツールがそもそもねーじゃん
責任持ってお前作って配れよ
結局のところフレームワーク無しだとif文書きまくるのが最強ということですか？
いわゆるKISSに原則ってやつですね
データからソースコード吐き出すツールでも作ったらどうか？
データはRDBMSでもテキストでもなんでもいいだろ
DAOで抽象化しとけば後から変えられる
メンテできるものにしろ
>>584
それやるとメンテが大変になるから辞めたほうが良いよ。
変換などせずそのまま使う方がいい なんか盛り上がってるようだがとりあえず
>>533
に賛成票。
設定が正しいか目視で済ませずテストすべき。
目視チェックで済ませたところが往々にしてトラブルの元。 > 設定が正しいか目視で済ませずテストすべき。
そのテストって実行結果を目視で調べるんだろ？
それか、テストのテストのテストのテストを書くわけないだろうから、
テスト書いて目視でそのテストが正しいか調べるんだろ？
どうせ最後は目視するしかないんだよ。
コードレビューとも言うね。
そんなのをやるぐらいなら
「十分な目ん玉があれば、全てのバグは洗い出される」方式を
利用した方がいいよ。
オープンソースでない場合、コードだと「十分な目ん玉」は集められない。
だから技術者ではない人でも検証可能な形にして「十分な目ん玉」を集めたほうが良い
これはコストのかけ方の問題だよ。重要かつ難しい所には技術者を割り当て
バリデーションとかいう単純な所は、誰でもできるようにして十分な数の目ん玉で対応する
バグってるかどうかはリリースすればわかる
瑕疵期間でも人件費はタダじゃねえからな
別にテストで全部見つける必要はない
瑕疵期間なしって契約ならテストで全部チェックするけどね
>>588
コードレビューとテストは目的も確認の手段も違うじゃん
正しいメールアドレスの形式かどうかをチェックする場合とかを考えたら分かるだろ
それに仕様に間違いがないかどうかを誰もが確認できるようにすることと
コードがその仕様通りに動いているかどうかを確認することは
確認する対象が全く違う
自己正当化の論理に聞こえる >>590
> 正しいメールアドレスの形式かどうかをチェックする場合とかを考えたら分かるだろ
その場合だと「ある文字列が正しいメールアドレスの形式か？」という
ロジックは技術者が入念にチェックすべき重要なロジック。
そしてこれはisMailAddressみたいな名前の関数となる。
そしてユーザーが入力したある項目のバリデーションが
isMailAddressになっているか？は目視で確認すれば良い
これは技術者でなくてもできる。
何でもかんでもコストがかかる技術者を使うなっていうのはこういう話だよ。
バカは項目が存在する数だけ、漢字が使えないこと、@の前は.になってないこと
.を連続して２つ以上使わないこと、みたいなチェックをするからな。
メールアドレスのバリデーションが正しく動いているならば、
そのバリデーションを使う場所がいくつあろうが、
そのバリデーションが使われていることだけを確かめれば良いんだよ。 「社員に対して給料を振り込む」という文章を
「ooをxxする」という1文にしたいときって、
「社員」と「給料」の2つの目的語があるからどうすればいいの?
>>591
>>メールアドレスのバリデーションが正しく動いているならば、
>>そのバリデーションを使う場所がいくつあろうが、
>>そのバリデーションが使われていることだけを確かめれば良いんだよ。
確める内容はそれでOK
でも確める方法が設定ファイルの目視チェックでは不十分。
設定ファイルの各項目が実際の動作に反映されてるか動かしてみないと。
まあシステム間結合テストとか言われるようなテストフェーズでやる場合、実装担当はあまり関係ないことかもしれないが。
誰かがそのテストをする必要はある。 設定ファイルに書いてあればOK
笑えないけど笑っちまった
設定ファイルの記述ミスは存在しない前提かよ
>>593
> 設定ファイルの各項目が実際の動作に反映されてるか動かしてみないと。
それは画面やAPIごとに、ここではこの項目が使われていますって
画面に表示するだけでOK。それを目視で確認すれば良い。
>>594
> 設定ファイルの記述ミスは存在しない前提かよ
記述ミスは目視で調べろって話だろｗ
何を聞いてるんだか というかさ、目視を軽視してないか？
動作確認を過大評価してないか？
動作確認っていうのは確かに動作させたものに関しは
その通り動くだろうけど、動作させてない所はわからないんだぞ。
偶数かどうかチェックする関数、2と4と6でテストしてOKだからといって
8がOKになるとは限らない。コードのロジックを "目視" して
問題ないことを確認しているはずなんだが？
永遠の時間があれば全て動作確認すればいいだろうけど
実際にはそんな時間はない。だから動作させずに目視で確認できるように
そういう仕組を作っていくことが重要なんだよ。
時間をかけて努力をすることは偉くもなんともない。
なるべく時間をかけずに成果を上げるようにしないと
生産性は上がらないぞ
>>596
それは見ただけでわかるような仕組みを作ってないから。
ゲームでよくあるデバッグモードみたいなものを
本気で実装した方がいいよ。
通常のプレイで見えないパラメータを、デバッグする人も見えないまま
デバッグするのは、時間を無駄に消費するだけ
デバッグモードを有効にしたら、見えないパラメータ
例えばこの項目のバリデーションは○○です～みたいなものを
表示するようにすれば、見ただけでわかるようになる。 テストも目視も要らないよ
とりあえずリリースしちゃいなよ
問題があればそれではっきりするだろ
説得するより怒られる方が楽って昔の偉いプログラマも言ってたぞ
>>599
ベータ版リリースとか有るからね。
でも、それはちゃんと発生した問題を自動で
検出して通知する仕組みが必要だよ。
それがないと問題があっても教えてくれないし、
発生した問題の詳細もわからない。
言うほど簡単じゃない。 >>597
なんかお前もうヤケクソじゃね？ｗ
お前の主張は誰が見てもありえねーからｗ >>601
反論は、文句じゃなくて、理屈で返してください >>602
だってそんなん
社会で通用しねーのわかってるし
相手にしてお前の馬鹿が伝染ったら嫌だし >>602
でかいソフトを書いたことないだろうな...
コードは正しくても実行するとうまく動かないとか経験したことないだろ >>605
その質問に、
ある と答えた場合
ない と答えた場合
それぞれあなたはなんて返してくるんですか？
いや、どうせどちらで答えても、的はずれな
文句言って終わるんだろうなと思いましてねｗ >>606
いや、もうただの屁理屈じゃんお前の
設定ファイルの読み込み処理がバグってるかもしんねーじゃん
最終的な動作の確認は絶対必要じゃん
お客からしたら設定値なんて
ファイルに出そうがソースに埋め込もうが知ったこっちゃないじゃん
ただ、お約束した機能が動いているかどうかはお客さんとの約束でしょ？
その確認をしないでどーすん？ > 設定ファイルの読み込み処理がバグってるかもしんねーじゃん
ならそこだけをテストすりゃいーだろ。
仕事は減らす方向に向かって頑張れよ。
人海戦術で時間をかけたらからって
偉くもなんともないんだぞ
> ただ、お約束した機能が動いているかどうかはお客さんとの約束でしょ？
> その確認をしないでどーすん？
その確認をどーするって、お前は客にテストやりましたって
エクセルシートでも送りつけて、それが本当かもわからないのに
これ見て納得してくださいってやってるんだろ？何一つ証拠がねーよ。
それともテスト作業してる動画を何時間も見せてこれが証拠ですとでもやるつもりか？
コード見せたって客はその内容わからないかもしれないし、
テストコード見せたって、それがソースコードの形じゃやっぱりわからない。
エクセルファイル見せたって、それを本当にやったかどうかもわからない。
間違って記入しているかもしれない。何にもあてにならないよね。
俺が言ってるのは、客にも簡単にわかるような形でデータを作り
そのデータをそのままプログラムで使えって言ってるの。
客がそれみて納得すりゃそれでOKだし、そのファイルを
直接使うからもちろんその通りに動く。
客の検収作業が、そのまま目視による確認になってるんだが。
>>591
メールアドレスじゃなく郵便番号くらいを例にしたほうがよかったかね
どういうメールアドレスを正しい形式とするかは要件によって変わってくるんだよ
RFCがあるからといって技術者が勝手に決められるものじゃないから
簡単な郵便番号の入力チェックでも
何をOKとして何をNGとするかは要件次第
その「目視の確認」で一体何が担保できるんだろうね？
1500001
150-0001
１５０－０００１
150 (旧３桁)
150-01 (旧５桁)
150-9999 (存在しない)
あらゆるケースをすべてテストできるわけでもないしするべきでもないが
仕様通りに動くと自信を持てるレベルのテストはすべき >>608
はぁ？馬鹿？
設定ファイルが間違ってる可能性は？
読み込みはうまく行っても
値が反映されてない可能性は？
それが設定ファイルのある特定の設定値だけバグる可能性は？
まあ、普通に仕様通りに動くこと確認した方が早いよね？ > メールアドレスじゃなく郵便番号くらいを例にしたほうがよかったかね
> どういうメールアドレスを正しい形式とするかは要件によって変わってくるんだよ
> RFCがあるからといって技術者が勝手に決められるものじゃないから
>
> 簡単な郵便番号の入力チェックでも
> 何をOKとして何をNGとするかは要件次第
> その「目視の確認」で一体何が担保できるんだろうね？
メールアドレスや郵便番号でもなんでもいいが、
ある項目が「メールアドレス」や「郵便番号」であることが担保できる。
これにより仮にバグがあったとしても、一箇所を修正するだけで
すべてが修正されることが担保できる。
動かして確認する方法だと、ある箇所のバグが修正されたからといって
別の場所も同じように修正されるとは限らない。
目視の確認ができるようにしておくことで、工数が大幅に削減できた。
>>612
ならばそこだけテストすればいいだろって
さっきも言った。
目視の確認ではない。テストだ。 想像力が足りないから不具合が無いように見えるんだろうね
想像力足りなくてもこういうの経験ないのかな？
経験不足もあるのかな？
考えが幼いよ
>>614
じゃあ、普通に全部テストするってレスしてるよね？ｗ >>616
お前関数って知らないのか？
共通化の基本テクニックだぞ？
全てのメールアドレスや郵便番号の項目で
同じ関数を使うんだよ。
テストをするのはその関数のみ。
バリデーションとしてその関数を使っているかどうかを
設定ファイルに書く。
何度も同じ話をさせるな >>617
かんけーねーんだよ
何度も言うけどファイルに出したのはテメーの勝手なんだよ
動くかどうかを証明しろって言ってるの
何が必要でしょうか？ >>618
見えない情報がある時点で、動かした所で
どんな場合でも動くとは証明できないってのは理解できてる？
ソースコードを読めば動かさなくてもわかる問題でも
ソースコードを隠した状態だと動かした結果だけでは証明できなくなる。 >>619
俺の質問に答える気はあるのかな？
もちろん答えは千差万別だが
お前のソフトが動くことの証明をして欲しいんだよ
一度でもソフトを納品したことがあるならわかるよね？
上司におんぶで抱っこでそんなこと気にしたことなかった？ >>628
> お前のソフトが動くことの証明をして欲しいんだよ
なんでお前もできてないことを俺がやらんといけないの？
って言ってるんだが。
動くことの証明はソースコードを見せる以外に不可能なんだよ。 ソフトウェアの納品は、動くことの証明じゃない。
これだけやりました。やったという証拠です。信じてください。
バグはないと思います（実際には有るだろ？）
という意味でしかない。
気にしたことなかった？
いや、ソフトウェア納品でバグが１つもないと
証明するものを出したというのであれば、
それを言ってくれて良いんだが？
バグが有ることは証明できるが
バグがない（正しく動く）ことは証明できない
常識なんだがねぇ。
>>622
おお、よくわかってんじゃん
じゃあ、それをお前はどうやってやるの？ >>624
え？ 信用してくださいドキュメントの話なんかしてないじゃんｗ
今まで通りのやり方で適当にでっち上げれば？
俺は少ない手間で必要十分なテストをするだけの話 >>625
いいや
ソフトウェアって上から下まで
さっきお前が言ったとおり
確実なものなんか何一つないよ
お前の十分だってお前の中の十分だろ？
俺等とは違うの
その差分を俺らとは違うお前は自分で埋めなければならない
そこに理屈はない
それが説得ってもんじゃん
人を見るのが嫌ならこの業界は向いてないね 結局屁理屈でごまかしたかｗ
無能なお前らと違うと言っても
だから何としか言えんわｗ
>>627
結局、テスト仕様書もテスト結果も
全ては説得なんだよ
理論に飛躍があり過ぎる
ウォーターフォールのV字開発で
設定ファイルに外だししたから
テスト項目減りますなんざ
あり得ない理論なんだよ
まあ、当然説得なんで可愛い女の子が交渉してくれば通る可能性も無きにしもあらずではあるけどね >>595
>>593
>>>> 設定ファイルの各項目が実際の動作に反映されてるか動かしてみないと。
>>それは画面やAPIごとに、ここではこの項目が使われていますって
>>画面に表示するだけでOK。それを目視で確認すれば良い。
なるほど。
各項目のUIを一通り動作させて、
>>598 で書いてくれたようなデバッグモード的表示やデバッグログで、動いたバリデータの書類を出力するってことならよさそうだ。
それなら設定ファイルの内容および設定ファイルの配置の正当性が確認できる。 2008年くらいに.net FWの地雷踏みまくった事を鑑みると、
テスト仕様は要件定義から作成すべきだし、その実施も単体、結合レベルは機械的に掛けてもいいけど、総合は手でやるべきだろうなぁ。
「テスト対象はまともに動いていない」という仮説を、ケース毎に一つずつ潰していって、残るのが「正常に動いてる」って結果なのが試験で
「正常に動いてる」が先に立って「なぜならこう書いたから、こう動くはずで、現にそう動いてる」ってのは試験じゃなくて単なる確認では？
正直、単体テストでもテスト対象を作った言語を使わないでテストして欲しいところ。
結局ID:/8UsyUgnは>>609にレスできずに逃げたのかよ w ＞コードは正しくても実行するとうまく動かないとか経験したこと俺はマニュアルどおりやったからこのコードは動かないけど正しいんだ！
「Object Oriented」は「オブジェクト指向」と訳されていますが、実はこれが大変な誤訳で、正しくは「目的志向」です。
つまり、何らかの目的があって、それを目指す（「指向」は向いているだけ）というわけです。
目的はObjective
Objectは単純に『物』の意味だよ。
>>641
Jittaさんが言ってることの方がガセネタですね
じゃあそれを根拠にわんくまに怒鳴り込もうと思います
ありがとうございます まあ英語でObject orientedだと、大体は対象志向みたいな意味合いだけどな。
Objectって単語は、モノと言うよりも「認識できる何か」「動作や感情の対象」を指す。
動詞になると顕著で、「俺はこれに文句があるんだが」ぐらいキツい意味。
「I object to waiting」みたいな。
Ob + ject 。前に向かって投げたやつ。客観的に見ることができる物、が語源。
逆に、中に投げ入れるモノがinject。下に投げたものがsubject(自我、主観)。
>>636
単なる「モノ」はだいたいbody、matter、substance。
physical bodyとか使う。
天体の「体」もbody。heavenly-body。 >>644
素晴らしい「モノ」
優れている「モノ」
高品質な「モノ」
高機能な「モノ」
のモノはどれになるの？ >>643
つまりJittaさんが大正解ってこと？ 目的を指向するってメチャクチャ当たり前だなw 殊更言葉にするのが恥ずかしいくらい
役割って感じ？
objectではないけどしっくり来る
Functional ProgrammingのFunctionにだって責務あるし
POAのProcessやDOAのDataにだって責務は有る
他と違って「オブジェクト」という抽象概念を中心に物事を考えるからオブジェクト指向という名前
んでオブジェクトってのは↓
a data structure that can contain functions as well as data, variables, and other data structures
https://www.merriam-webster.com/dictionary/object Object oriented languageは
・カプセル化、継承、多態性をサポートするもの
・JavaやC++、Rubyなど
Object based languageは
・継承・多態性をサポートしないもの
・VBなど
orientedはbasedと似たような意味で、basedよりも多くの条件を規定する。
Object based languageを「オブジェクトを基本にした言語」と解釈するならば
Object oriented languageは「オブジェクトを本位にした言語」と解釈するのが妥当な気がする。
「本位」は中心にして基本にするという意味なので「基本」を強めてる感じ。
>>656
やっぱそうだよね、オブジェクトを中心にするっていうのがオブジェクト指向だよね >>657
オブジェクトじゃわからない
Objectはなんて訳すのが適切なのか ピッタリの訳語がないから
新しく作るか (例 経済)
既存の言葉に新しい意味を持たせるか (例 自由)
ちなみに中国語訳では「対象」らしい
>>645
good one,
better one,
high-quality one,
とかでは？モノと言うよりは、何か指しとるでしょ、その言い回しで言うときには、モノは。
>>647
事象、作品、道具、衣服などなど、それだけでは存在に意味が存在しない類のやつ。転じて、流行りとか、大事な事を指したりする。 orientedも指向より主導の方がいいと何かの本で書いてたな
主体とか本位とかでもいいかもね
役割主体、役割本位
>>659
「モノ」「箱」「塊」とかなんでもいいような気がしてきた
どうせ実際に使う時は「社員」とか「敵機」とかになるんだし 人間の方の理解のために「”もの“になにかやらせる」
「”もの“を複製して別な”もの“のパーツとして使う」
これわかりやすいっしょ？
どんどん再利用パーツ増えて複雑になってったらこうじゃないとキツイっしょ。
で提唱されたってのに、すぐにベテランプログラマーさんは
「この名前さあ、タイプすんのめんどくさいから「あ」「い」「う」でよくね？」と他人にわからない暗号にしたがったり
「オブジェクト指向ってさぁ、オブジェクト単位に分けるんっしょ？この再利用しない中身もさぁ
ぜんぶ用途別に名前つけてパーツに分類整理しなきゃ！」とかやりなさる…
そうなると、クラスって何だ、インスタンスって何だ、コピーなら、コピー元も何かの役割を果たしてたんだろ？みたいな明後日の事言われるからな。
プレスの金型と、それで作り出した製品くらいの言い方の方が伝わる。
たまに金型に便利な治具ついてることもあるし、付けることもできて、それはプレスせずに金型から直接使えますが、
その治具にメモとかつけると皆から見えたり、誰かに剥がされたりするので、必要がなければ製品に付けたほうがいいですよ、
何回プレスしたかのカウンタとかは治具につけたら良いですね。みたいに説明した事ある。
スーパークラスとかサブクラスも、同じように、互換品の金型と互換品とかそういう説明できるから、物理な型で説明すると割とわかってくれる。
プロトタイプベースな言語だと、コピーのメタファの方が的確になったり、まぁ難しいわ、もう自分が知ってる物を、1から人に教える順番を考えるのは。
自分がちゃんと理解してないものは人に説明できないって言うしね
>>671
わかるわ。耳が痛い。教育することになって逆に知る事も多かったしな。
若手の新アイディアは、素直に教えてもらってる。
たまに俺が相槌しか話してないうちに「出直します」って言うから、どうやらテディベアとしても活用されてる模様。 自分の行動を素直にと修飾するところが完全に淫乱テディベア
オブジェクト指向を理解させたければ
まずはオブジェクトを理解させることからはじめないと
クラスやプロトタイプは二の次でいいし
責務や役割は別レイヤーの話
>>677
IT後進国の日本ではまだほとんど導入されてないね
非正規化DB 、非レイヤー化、貧血ドメイン、トランザクションスクリプトが主流 >>677
結構やってるでしょ
エヴァンス本から何年経ったやら… >>679
>>682
完全に対立してるな。
個人的には比較的昔からある企業は前者で、若くて成功してる部類の企業は後者かな？と思うけど。
実際DDDやってるぜー、て現場はどういう特性なんだろ。 要件定義や設計時にDDDの考え方を(一部)導入してるのと
実装含めて厳格にDDD導入してるのとで違うよね
前者は多いけど後者は少ない
>>679は実装者の視点
>>682は要件定義・設計者の視点
おそらく たとえば>>26をDDDでやるとどんな感じになるの？
DCIでやったときとの違いも知りたい >>687
業務アプリを受託で開発するのが主戦場
iOSと同時開発必須
自分で直接販売するのはバクチだね
アプリ数多いといってもニッチはまだまだ足りてない >>592
別に複数あっていいと思うが
社員給与を振り込む
給与の分類か属性かで >>592
給与は社員に与えられるものだから
「社員に対して」は要らなくね？ 役員やパート・アルバイト等、社員以外のケースがあるんじゃね？
>>592
目的語でひとくくりにするとわかりにくいけど
日本語では名詞が述語をどう修飾するかは格で区別されるから
格を考えればよいかと
1.「振り込む」が述語ならば振込先は口座なので「社員の口座に」としたほうが良いかと
振り込む(社員の口座に:与格, 給料を:対格)
2.「社員に」を使うなら述語は「支払う」かな
支払う(社員に:与格, 給料を:対格)
3. 対格しか使いたくないんですということならば「社員の」という属格で対格を修飾するしかないんじゃないかな
振り込む(社員の給料を:対格) すっごい不評な法令検索つくって賞もらっている大学教授
法令データベース「e-Gov法令検索」リニューアルにあたり、同法情報研究センターの協力教員である名古屋大学情報基盤センター（センター長：森健策）の外山勝彦（とやまかつひこ）
DDDと言えば20項目の責務単位でドメインクラス作ったら一つのグラフ作るのに20個のクラスがデータベースに問い合わせちゃってパフォーマンスやばい
有識者のみなさんはどうやってるの?
DDDならドメイン層とインフラ層のレイヤーは分けろ
つまりドメインのクラスが個々に
直接SQL文でDB叩いたりしない
>>698
例えばドメインクラス「作業時間」にhogeプロジェクトの作業時間を問い合わせた時、作業時間クラスがDBクラス使って作業時間を教えてくれるんじゃないの?
この辺解らないとパフォーマンスの問題でアクティブレコードに走っちゃいそうです >>699
たとえばソシャゲみたいなWebアプリをイメージしてみよう
一個アイテムを見るたびにDBアクセスしてたら重いから
画面を遷移するときにまとめてローディングするよな？
だからそういう風にインフラ層で
ある程度まとめてデータ取ってきて
ドメイン層の内部ではDBに直接触らないようにする >>700
それはレイヤ分けるメリットでなくて
レイヤ分けるデメリットをカバーする方法じゃないの >>700
あらかじめオブジェクトにぶち込むのかな
油断するとメモリ食いそう >>703
昔は画面単位にデータ取ってたけどトランザクションスクリプトアンチパターンになるから作業時間とか予算とかドメインでクラス分けたんだ
それぞれのクラスがデータベースに問い合わせるからウッホという状態に >>697
基本は集約一つにリポジトリ一つ
レポーティング用途の場合はドメインモデルやリポジトリを経由せずに
DBレイヤーに直接問い合わせるのも有り
ドメインモデルを経由しなければ
ドメインロジックが分散する可能性があるのでトレードオフを判断したり
それを避ける工夫が必要だったりする
Patterns, Principles, and Practices of Domain-Driven Designって本で
一つの章使ってレポーティングの実装パターンを紹介してるので読むといいと思う ドメイン駆動とORMって相性悪くない？
class Foo : ValueObject<Foo> { ～ }
class Bar : ValueObject<Bar> { ～ }
class Baz : ValueObject<Baz> { ～ }
class Hoge : Entity<Hoge> {
private final Foo _foo;
private final Bar _bar;
public Hoge(Foo foo, Bar bar) {
Assert.notNull(foo);
Assert.notNull(bar);
_foo = foo;
_bar = bar;
}
public Baz queryBaz() {
// なんか計算する
return new Baz(...);
}
public Hoge doSomething() {
// なんか計算する
return new Hoge(..., _bar); // なんか計算した結果fooが変化する。_barはそのまま
}
}
ORMってこういうガチンコDDD的なオブジェクトってうまくマッピングしてくれないじゃん？
だからORM使おうとするとpublicプロパティに汚染されてゲロ吐きそうになる
かといってORMはDTOまでに留めてDTOとドメインオブジェクトのマッピングを手書きするってのはそれはそれでめんどくさい
>>707
AutoMapperってやつそんな賢いの? 逆にDDDこそORMだろ
集約をそのまま永続化したいんだから
>>709
どうかな
さっきも書いたようにDDDに忠実にドメインモデルを構築するとpublicプロパティが無くなって完全コンストラクタでインスタンスを構築しなければならない
DTOのようにフラットな構造にならない点でもORMで扱いにくい そもそもDBが単にオブジェクトの置き場所になるってのも疑問だよ
RDBは個々のオブジェクトではなく集合としてのビジネスルールを表現するのに適している
単なるデータストアではない
1ヶ月の間に正当な休暇を間に挟まず3営業日連続で欠勤した従業員にはペナルティを与えるといった業務ルールがあったらSQLで解決するほうがスマート
どのORM使ってるの？
いまどきORMのために可視性を変えたりしないでしょ
>>712
> そもそもDBが単にオブジェクトの置き場所になるってのも疑問だよ
DDDだろうとトランザクションスクリプトだろうとDBの役割は変わらないよ
ドメインモデルから見てあたかも単なるオブジェクトの置き場であるかのように振る舞うっていうのは、
そう振る舞うように作ってるからそうなるのであって、DBから見たら、アプリがDDDで作られてるかどうかなんてわからない >>712
じつはそういう考え方もアリだと思う
SQLやPrologでビジネスルール書くのもアリ
でも現実的にはDDDの
インフラ層にDBを隔離するやり方が無難だと思う
SQLでビジネスロジックを表現すると
シンプルな例だと分かりやすく感じても
実務レベルの複雑なルールでは非常に難解になる
OOでチマチマ差分を書いていく方が分かりやすい
これはなんでOOが主流なのかの理由でもあると思う >>712
ひっかけっぽい例だな
SQLかじったレベルじゃそれは書けない
普通にアプリでやったほうが柔軟性高そうだ >>712
RDBMS主体でやるプロジェクトもあるだろ
ただ古臭くて不便なことが多いからか
アプリケーション側でやるのがほとんど
技術者の数も違うからかな 期待のデータベーススペシャリスト持ちが開発してくれたプログラム
1クラス1メソッドにSQLをぎっちり書いていてくれた
流石データベーススペシャリストだと思った
そんなんアーキテクチャ検討時に認識合わせしとけよ
単なる指示ミス
>>719
チームリーダーは電気寄りのC使い
JAVAの実装にはノータッチ データベーススペシャリストがSQLしか知らんのは仕方ない
ソフ開持ってなきゃね
オブジェクト指向のスペシャリストとは言ってないからな
メンバー集める時はくだらん資格のことより影響を受けた本とか聞いた方がいい
オブジェクトにメソッドでリクエスト飛ばすと答が返ってくるならそれはそれでいいような…
DBスキルつけても負の遺産と有害な社内規約のせいで役に立たないことが多いね
データアクセス層でオブジェクトにマップしたらもう二度と中は見たくない
>>720
javaはともかくJAVAって書かれると
あっ・・・（察し）ってなるから気をつけて スクリプトの方はjava表記多いけど
Javaの方は書籍とかもJAVA表記多いよねぇ
ネット校正員多いけど
そんな表記は本質に全然関係ない
JAVAが得意とかJAVASCRIPT経験5年とか書いてるの見て
まともなコード書けるやつだと思えるの？
そんなことで何か判断してる気になってるオマ、恥ずかしいぜｗ
java - コマンド。
Java - 言語。
JAVA - 茶。
>>723
VBの絵本でプログラムを覚えました
非常に解りやすく良書だと思います
御社のお役に立ちたいです 憂鬱なCプログラマのためのオブジェクト指向入門かなー
読みにくくなるとかでクラス禁止になった
で、大卒正社員PMがクラス作った俺を高卒非正規はスキルが無いと滅茶苦茶言ってる
帳票の抽象クラスとそれを継承した3帳票のクラス作っただけなのに
つかボタンイベントで作られるメソッド以外禁止にする勢い
前任者がボタンイベントのメソッドに処理をつらつら書いて完成させた成功体験が悪かったみたい
全部のメソッドに同じ処理をコピペしてるから修正の影響範囲がわけわからん
>>740
カスなチームでまともな自分アピールならマ板でやれよ >>740-741
そうは言っても仕事で
オブジェクト指向のメリットって
説明できんやろ？
やれるもんならやってみいや 結局、ここで人を馬鹿にしてる奴等もいざ自分が説明する立場になったら
何もできんということは覚えておいたらええよ
>>744
同じコードをどこにコピペしたかわからんなるぐらいなら
クラスで一括にしたいなぁ >>747
俺じゃなくて大卒正社員PM様に説明して差し上げろ >>741
そいつここに呼んでこい
精神崩壊するまで論破して追い込んでやるよ 作っておしまいなソフトは多いし
規模が大きくないか、仕様が変わらないようなところなのかもしれないし
個別に修正するときはコピペした方が影響の範囲は小さくなるし
一か所見れば処理がわかるってんならコードの見通しもいいし
ソースコード見ない段階であれこれ言うのはちょっとちょっとちょっと
>>751
作ってお終いなら俺は文句言わないよ
改造とバグ修正を投げられたから困ってるんだ
関心が分散しまくってる
高卒非正規の脳じゃオーバーロードだ 無職じゃないって
つかクラス化した場合の有効性をコストで可視化しろって
もうバグ満載でリリースしてデスマーチコースだ
IT業界らしくなってきた
>>754
ごめんけど、ここはオブジェクト指向を諦めた人のスレじゃないから
コピペだらけのトランザクションスクリプトが至高だと悟ったなら、それでやっていけばいいじゃん
わざわざ啓蒙しに来なくていいよ >>755
横からだがそれはコピペコードを勧めてるおじさんたちに言うべきだろ >>752
共通のメソッド作ればいんじゃない？
クラスが駄目なら オブジェクト指向がダメって人は
言語何使ってるんだ?
オブジェクト指向言語のAPI使ってないってこと?
オブジェクト指向ダメおじさんが棲んでいるのはC++
よくわかんだね
throw new AppException("ERR12345");
throw new AppException(ErrorCode.ERR12345);
throw new AppException(ErrorCode.BlogPostNotFound);
throw new BlogPostNotFoundException();
AppExceptions.ThrowBlogPostNotFound();
IAppException appExceptions = GetService<IAppExceptions>();
appExceptions.ThrowBlogPostNotFound();
どれがいい？
長すぎるのはだめ、変換がかかって脳の短期メモリを大量消費させるのもダメ
diとiocの組み合わせの意義を教えてください
シングルトンをどこが持ってるかが重要なんですか？
VBには継承がないから！
みたいなことを言って恥をかくと良いよ
オブジェクト指向の言語を使っても
オブジェクト指向でプログラムを作ることにはならんでしょうに
staticメソッドを中心にプログラム組むことだってできるし
それなりの規模がないとオブジェクト指向は効果を発揮しないのじゃないかな
そいえば旧VBは型の継承はサポートしてるんだよね
昨今は実装の継承はあまりやらない方がいんじゃないかって言われてるし
旧VBはオブジェクト指向言語と言っていいと思う
旧VB+ラムダ式の言語があれば最強な気がする
>>765
IoCは概念
DIはデザインパターン
シングルトンはゴミ >>773
あれあれ？ポリシーがないってだけ？
そのポリシーとやらは
オブジェクト指向にどう関係してくるんですか？ VBが糞と言うよりVB使いにくそしかいないと言うことでしょ
言語に善悪はない
VBはラムダのFunction省略できないとめんどくさくてやだ
「ナンバーズ-天才数学者の事件簿-」でFBIの技術官が犯人のwifi逆探知するのに
「ええ、ビジュアルベーシックで絞り込めば…」って言ってたし(ガクブル
vb.netになって出来ることはC#と同じになったのになんか書き方がいちいち冗長
やはり話にならないらしい
VBに毒されたものの末路だな
>>779
そりゃBASIC構文だからな
BASIC構文でラムダ式とか記述に無理がある VBってまだサポートされてんだっけ
Coreになってからさっぱり話題にならなくなったけど
JavaScript併用しなければならないWeb開発だと文法違い過ぎるから敬遠されるだろうね
VBは言語の問題でなく使う奴が糞
8割がスマートUIを書きモダンな設計を読みにくいと一蹴する
4重ループにカウンタ現役
VBAはオブジェクト指向が出来るように近代化して欲しいと思ったけどVBAごときでオブジェクト指向導入する規模とかヤバそうだから現状維持と緩やかな死が良いね
ER図とクラス図が似てくるのは危険な匂いしてますか?
正規化した物理設計レベルじゃ違うけど外仕レベルじゃ同等になっちゃう
>>787
RDBMSの最適化進めてくと違ってこないか
後からクラスだけ変えるのもあるし >>788
内部設計になってDBの正規化始めると確かに違います
ただ外部設計ではほぼ同じになるのでER図とクラス図に差が無いんです
ER図要るのかこれってなるので世間様はどう折り合い付けてるのか気になりまして データベースは実装の奥底にあるものなので設計では何も決めない
データベースなしの状態で動くところまで実装してようやく、そろそろ永続化の実装考えようかって話が始まる
>>789
そのDB使う他のアプリケーションには必要だろう 異なるアプリでデータベースを共有するの迷惑
APIを用意してくれ
マイクロサービスか
やりたいけど構築するのが面倒だ
誰か代わりに作ってくれ
クラス依存症は、だいたいのところファンクションという概念すら理解できていないのが9割
クラスに格納されたデータという名詞的実体に安堵しているだけで
プログラムを書く才能も、システム設計する能力もないやつが
好き勝手にクラス図をかいて、ぼくのさいっきょなクラスチームを作るだけなんだよなあ
だから僕の考えたクラス構成という話題は出ても
そのクラスがどのように通信するかっていう話をオブジェクト指向信者は語らないの
なぜならばそのメッセージングを実装できないから
そのすばらしいクラスが単なるデータの塊でしかないことを
自分で書いた壮大な物語でカプセル化し、他人から見えなくしたいから
カプセル化って偉大だよなあ？
電卓やじゃんけんすら実装できないひ弱な自分を壮大なクラス図を書けばごまかせると錯覚できちゃうんだから
VB.Netはもう20年ほど前に完全に移行しているんだけどなぁ
VB馬鹿にするやつがどれだけオブジェクト指向理解してんのか疑問だな
>>792
それならオブジェクトをシリアライズして保存した方が楽かな
キーは要るけど オブジェクトでプールして必要に応じて永続化してくれるようなサービスでもういいな
>>794
さすがに時代錯誤な感じ
今どきのメジャーな言語は
ほとんどクラス持ってるぞ
Java、C#、C++、Python、Ruby、PHP…… 間違ってないんだから問題ないだろ。
あとついでに無名クラスを持っている言語
PHP、・・・
クロージャーを持ってる言語
PHP、・・・
トレイトを持ってる言語
PHP、・・・
ジェネレータを持っている言語
PHP、・・・
PHPは最先端の言語だからな。だからこそ、バカには使いこなせない。
のに、バカがこぞって使うからクソ言語扱いされている。
10年経ったことにも気づかない引きこもりがいる板だからな
10年前に見かけた与太を今日話すことに違和感をおぼえる知能もない
プログラミングできるわけじゃないから、技術的な話にも初心者の質問にも応えられない
「ただ」「昔見かけたもの」を「書く」だけ
>>795
VB6のコードをそのままVB.NETに移植する仕事を何度したことか C系やる奴はPHPやJAVAもやってるけどVB使いはVBしかできないケースが多い
>>795
> VB.Netはもう20年ほど前に完全に移行しているんだけどなぁ
VB.netのリリースは2001年（16年前）なんだが...
> VB馬鹿にするやつがどれだけオブジェクト指向理解してんのか疑問だな
人の心配する前に自分の認知症の心配した方がいいぞ w 20年ほど前じゃない16年前だ <- これアスペすぎるだろ
>>810
20と16の区別もつかなくなってるのか w 8進数の20は10進数の16
すなわち、20=16、とな
VBとCOBOLはいまさら覚えたくねえなぁ
C系と記述が違うのに先進性は無いとか鬱になる
分かりにくい解説だな
マルチポストする前に文章を見直せ
>>823
ペチパーやドザーみたいな愛称だろアスペか >>825
文脈的に、アスペルガー症候群じゃなくてアスペルガー症候群患者な どうやったらこんなつまんないレスを返せるんだよ...
重症やな w
どうやったらこんなつまんないレスを返せるんだよ...
重症やな w
ひょっとしてガチが若いとか思ってるんじゃないよな w
若いと思ってるっつーか実際若いしな
ガチとか使う奴=低脳、バカっぽいって発想がオッサンぽい
>>838
ごめん、どうみてもお前の方がおっさんだよ ww アスペクト指向プログラミングってのは具体的にどんなのかよく分からんわ
興味ないから
おっさんは知識と経験と優しさでできています
残りの9割は脂肪です
おっさんは別に嫌いじゃないけど>>838みたく勘違いしてる奴はキモい やっぱり青木 淳いいな
若い時に心酔して、経験積むうちに忘れていたが
ようやく言わんとすることが分かつて来た
![オブジェクト指向システムの設計 174 [無断転載禁止]©2ch.net ->画像>10枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/uatG5Vj.png)
![オブジェクト指向システムの設計 174 [無断転載禁止]©2ch.net ->画像>10枚](https://rz.anime-tube.win/pic.php?http://i.imgur.com/sWco4kY.jpg)
