オブジェクト指向システムの設計 172
ttp://mevius.2ch.net/test/read.cgi/tech/1467992113
オブジェクト指向システムの設計 173
ttp://mevius.2ch.net/test/read.cgi/tech/1502182334/
類似スレ
手続き型システムの設計 1
ttp://mevius.2ch.net/test/read.cgi/tech/1500282714
デザパタ厨： 煽ることしか出来ない無能
次の患者、どうぞ
お前は何て病気?
デザパタなんてイラネな俺がいくら無能でも、
デザパタを勉強する価値がある事にはならんだろ。
肝心のデザパタ厨が無能なんだから。
お前ら当たり前の論理も組み立てられないのな。
結局はデザパタ厨もやりすぎて手段が目的になってる。
上級者の実装パターンを学び、実装時にそれを生かすのが目的なのに、
デザパタの暗記が目的になり、undoすら実装出来ないのでは意味無いだろ。
しかも自分がその程度だと気付けてないのも救えない。
全スレは訂正しておく
・933の実力>>>デザパタ厨＝自分がundoの実装すらマトモに出来ない事に気づけない
布教したいのなら、お前らがやるべき事は、
実装方式を悩んでいる初心者に対し、「そこは○○パターンで(ｷﾘｯ」と丁寧に教えることであって、
いくら俺を叩いても意味無いだろ。
まあお前らにはこれをやる実力すらないわけだが。
で、なんでデザパタイラネなんだっけ？
> デザパタの暗記が目的になり、undoすら実装出来ないのでは意味無い
とか言ってる人がいたから、デザパタ厨とアンチデザパタ厨で実装対決してたのかと思ったら、誰もなにも実装してなかった
なるほど、undoすら実装できない人同士で設計論を争ってるのか
デザパタとundoの関係も理解してない人が
デザパタイラネと言ってたのが前スレ
こいつundoさえわからないのか
いつもの「自動車は馬なし馬車だから」さんが居たのは憶えてる。
「振る舞い」と「操作」って何が違うんかな。
主体が違うし、それがOOPの基礎でもある。
詳しくは優秀なつもりのデザパタ厨が説明してくれるのを待て。
cancel(order) -> 注文に対する操作
ただしメソッドのことを操作と呼ぶ場合もあるから文脈による
注文のように振る舞うオブジェクトを他のオブジェクトが操作するんだよ
デザインパターンすら打つのが面倒くせえ奴はプログラミングなんかやめちまえ
例として商品は10種類まで、今はつり銭の概念が入ってくるとややこしくて考えられないので投入金額 = 価格のみ購入可能というすごいシンプルな飲料自動販売機を想定しています
フローとしては購入する()内で飲料型の商品変数のメンバ価格と投入金額を比較し、イコールだった場合在庫数を減らす()を呼ぶというふうに考えているのですがどうなのでしょうか？
また自販機がわかりづらい場合、他の例を出して頂ければそちらで設計しますのでお願いします
クラス図を貼っておきます
ttps://i.imgur.com/0Sthq5O.png 複雑そうなところはクラスの数を増やす、そうでないなら無理にクラス化しない
そういうことでどこまで作るかにもよるし
ユースケース図でも書け
お前が何がわからないのかわからない
デザパタ デザパタ デザパタ デザパタ デザパタ デザハタ デザパタ デザパタ
デザパタ デザパタ デザパタ デザパタデザパタ デザパタ デザパタ デザパタ
そもそもデザパタ厨ですら全く使わない（＝見かけない）から最初の質問、
「本当に使われているのか？」が発生するのであって。
デザパタは使おうとすると
適応根拠が説明しきれない
それだとデザパタは使い物にならない＝ゴミ、ってことになるだろ。
てか君はどっち派よ？
まずはデザパタ厨に説明する機会を与え、様子見すべきだろ。
rgy
どっちとかじゃない
デザパタはどのくらいクソって議論しか取り合わない
なら敢えて聞こう、どの位クソなのかと
熱盛
外国人にはデザインパターンじゃないと
通じなかったよ
オブジェクト指向かどうかに関係ないが
内部構造を考える前にシステム境界の内側と外側のインタラクションをまず考えること
システム境界の内側と外側のインタラクションを定義するためには
各インタラクションを自然言語で明確に記述することからはじまる
それができれば一番外側のクラスのインターフェースを考える（慣れるまで内部状態は一緒に考えない）
次に一番外側のクラスのインターフェースをサポートするために必要な状態やクラスを考える
で新しく必要だと考えたクラスのインターフェースを考える
これを繰り返す
- 「お金の投入」と「商品の購入」を別インタラクション？ お金はどうやって投入するの？
- 「購入する()」は何も渡さず何も返さない？
↑こういう点が必要なインタラクションを把握できてないと感じるところ
外人なんてDPって書く奴ざらにいるぞ
出庫(商品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)
押されたボタンに紐付く商品を取り出し口に落とす()
}
}
グローバル例外ハンドラ {
未処理例外イベント(例外) {
エラーログを出力する(例外)
}
}
- 無限に入庫できるの？
- ボタン押せばお金入れて無くても商品出してくれるの？
- 在庫数取得中にラスト1個の出庫が発生すると商品出てこないね
早まった詳細化はよくあるデスマーチパターン
手続き型との違いが分からない
要件に無いので無限に入庫できる
金銭の問題は質問者が別途考えることであり現在のコンテキストにはそぐわない
自販機において商品購入の並列処理は考慮しなくてよい
あまりにも馬鹿馬鹿しい指摘は今後スルーします
ならばデザパタは存在価値が無く、デザパタ厨はゴミだって事になるが。
俺の見立てでは、デザパタはセンスがない奴の勉強してますアピール時のアリバイ程度にしかならない。
肝心の構造実装を説明する時にも他の用語の方が適切だって時点でゴミ確定。
使い物にならないから誰も使わず、「本当に使われてるんですか？」という質問が発生する。
デザパタ厨は老害だよ。
デザパタが有用だと主張するなら、デザパタ用語でより分かりやすい説明を提供できないといけない。
そもそも俺はデザパタ厨は実装能力が全くなく、非デザパタ用語での説明すら出来ないと見ているが。
ついでに言うとsmalltalk信者もこういう時こそメッセージング指向(ｷﾘｯで
素晴らしい実装を披露するべきであるんだがな。
ところでそれは何言語で何指向なんだ？
(なお俺もは揚げ足取りで、現段階で必要な議論ではないと思う)
自販機クラスの構成の説明に使えないものはゴミなら、プログラミングの世界ってゴミばかりだねw
そもそもお前らデザパタ厨は「『何に役立つから』デザパタを学ぶべきだ」という主張なんだ？
当然だが俺は、何にも役に立たないからゴミだ、という主張だ。
実際ここで使わないで、いつ使うんだ？という状況だろ。
> プログラミングの世界ってゴミばかりだねw
他に何がゴミだと思っている？
え、じゃを書いた意味というか目的はなんなの？
だろうな
マシならいいという風潮
> そもそもお前らデザパタ厨は「『何に役立つから』デザパタを学ぶべきだ」という主張なんだ？
デザパタ本を最初に読んだ時、
俺がそれまで悩んでいたり自分で考えた設計が
紹介されていたから、やっぱりちゃんとした
本で勉強したほうが時間の節約になると
実感したから学ぶべきだって主張
あんたの世界が狭いんだろ？
フレームワークを使って、その中身だけを書いてる人は使わないだろうさ
自分の作ったアプリにプラグインの仕組みを取り入れようとしたり
テキストエディタなんかを作ろうと考えたら、必ずと行っていいほど使うよ。
そりゃへの回答だろ。
つか、俺は君のよりもの方が直接的で分かりやすいと思うが。
全部実装する必要もないし。
俺は48で何指向かと聞いたがこれは間違いだった。
これはOOPだね。見落とした。すまん。
> 自分の作ったアプリにプラグインの仕組みを取り入れようとしたり
> テキストエディタなんかを作ろうと考えたら、必ずと行っていいほど使うよ。
ほう。何パターンを使うんだ？
前者は「DLL」、後者は前回も言ったがundoなら｢逆方向履歴｣等で、デザパタ用語は不要だろ。
これ以上に明快な説明をデザパタ用語でやってみろよ。
自動販売機をモデル化する場合に核になるのはステートマシン
それを理解せず設計したりコードを書いたりすれば
で指摘したような問題が後から後から出てくる
設計時もコーディング時も
事前/事後/不変条件を常に意識することが大事
「デザパタ」が必要ないんじゃなくて
「デザパタ用語」が必要ないって
お前書いてるよね？ｗ
デザインパターンが使われている
それは当たり前。
デザパタは登場時の時点で「既に頻出」な物に名前を付けただけ。
何も新しい物はない。普通にコード書けば使っている。
だから俺は「デザパタを別に勉強する意味はない」という立場。
> 逆方向履歴という機能を実装するのに
何パターン？
これにはパターンは無いはずだが。
（ただし俺は全て押さえているわけではないが）
馬鹿なの死ぬの？
> 自動販売機をモデル化する場合に核になるのはステートマシン
これは多分違うぞ。
どのレベルからステートマシンと称するかにもよるが。
たしかに世界にとっては頻出だろう？
だが勉強中の人にとっては知らない知識だ
だからその人が世界に追いつくために
勉強しなければいけないってことだ
なぜ頻出なものを自分で考え出さないといけないのか
それこそ時間の無駄だ
そこはステマシじゃねぇのかよ
中途半端な野郎だな
自分で考えだしたものが
実は教科書に乗っているようなものと
認めたくないんだろうな。
> なぜ頻出なものを自分で考え出さないといけないのか
> それこそ時間の無駄だ
使える物は全て言語機能に採り入れられてるから、言語を学べば「使い方」は理解出来る。
そしてせっかく覚えた「デザパタ用語」は使い道がない。
中途半端に抽象化した結果、「ストラテジーバターン」＝動的に対象関数を切り替える
とした場合、実装は「継承/委譲/関数ポインタ」等になり、実装時にはこれらの区別も重要な為、
「継承/委譲/関数ポインタ」が使われ、「ストラテジーバターン」が使われることはない。
だったら最初から言語機能をきっちり押さえた方がいい、というのが俺の立場。
(ただしJavaみたいな制限がきつい言語だと、言語だけ学んでも駄目だが)
ストパタじゃねぇのかよ
馬鹿なの？
言語を学ぶの中にデザパタを学ぶが含まれているんだが？
なにを言ってるのだろうこいつは
作り出すパターン
単体の道具（継承/委譲/関数ポインタ）を
複数組み合わせて構造を作るのがパターン
やっぱりデザパタ分かってないんだなｗ
ストバタにしろやカス
> 言語を学ぶの中にデザパタを学ぶが含まれているんだが？
これは初耳だが、どの言語のことだ？
どの言語でも
継承ってなんですか？
→ 親クラスの機能をサブクラスが受け継ぐことです
継承を使うと何ができるんですか？
→ 応用例はいくつもあります。例えば〜のような使い方が出来ます。
このような使い方を○○パターンといいます。
っていうように道具を使った応用例として
デザパタがでてくるだろ
お前は継承という道具を勉強するだけで
その継承のいろんな応用例まで勉強中のやつが思いつくと思ってんのか？
> 単体の道具（継承/委譲/関数ポインタ）を
> 複数組み合わせて構造を作るのがパターン
これは俺は無駄なバリエーションで名前の数を増やしているだけという立場。
お前らはテンプレートメソッド＝継承という立場だったはずだが、
その場合、テンプレートメソッド、ストラテジー、コンポジットを別々にする意味はあるのか？
そして、この程度の差異で無駄に名前を増産する意味があるのか？
何の為にストラテジーパターンを抽象化したんだ？
> → 応用例はいくつもあります。例えば〜のような使い方が出来ます。
> このような使い方を○○パターンといいます。
ねーよアホ。
デザパタが書かれる前から継承はあったし、使われてる。
継承は継承としか書いてない。
お前はデザパタ洗脳用の教科書を掴まされたんじゃないのか？
使い方が違うからな。
第一な、無駄なリエーションで名前を増やしているというのなら、
言語なんて実は
・順次実行
・メモリ（I/O)読み書き機能
・演算機能
・（条件付き）ジャンプ機能
これだけの用語で十分。関数とか例外とかそんなものすらいない。
実際機械語はこのぐらいしか機能がない。
それ以外の機能は、これらの基本的な機能の応用例でしか無い。
だが、それだけじゃあまりにも基本的な機能すぎて
他の人と知識を共有できないから名前を増やすことで
短い単語で言いたいことを表現してるんだろうが
テンメソだろ
なめてんのかてめぇ
> デザパタが書かれる前から継承はあったし、使われてる。
だからなんだ。
使われてるその応用例をカタログ化したのが
デザインパターンなんだろ
プロが長年かけて最適なパターンを教科書に乗せて
初学者がすぐに追いつけるようにしたんだよ。
当たり前過ぎ・・・
基本と応用の違いも理解できんのか。
初学者に継承を教えるだけで、
すぐに応用例が思いつくわけ無いだろ
基本（継承）を教えてから、基本機能を組み合わせて
応用（パターン）を学ぶんだよ。
継承とパターンが違うんだから、
継承のストラテジーパターンって書くわけ無いだろｗ
継承＝ストラテジーパターンではない。
色んなパターンの中で継承が使われてる
ストラテジーパターン以外でも継承が使われている。
この２つの単語は同一ではない
> 短い単語で言いたいことを表現してるんだろうが
おう、だからやってみろとで俺は言ったはずだが、
お前も不都合なことは見えなくなる病気なんだな。
デザパタ用語は抽象度が中途半端すぎて、何にも使えない、というのが俺の立場。
まあ、の回答を待つ。
> 単体の道具（継承/委譲/関数ポインタ）を
> 複数組み合わせて構造を作るのがパタ
これは俺は無駄なバリで名前の数を増やしているだけという立場。
お前らはテンメソ＝継承という立場だったはずだが、
その場合、テンメソ、スト、コンポジを別々にする意味はあるのか？
そして、この程度の差異で無駄に名前を増産する意味があるのか？
何の為にストパタを抽象化したんだ？
俺はの
> どの言語でも （中略）
> っていうように道具を使った応用例として
> デザパタがでてくるだろ
についてダウト！と言ってるんだよ。
理由は「継承」は「デザパタ」よりも古いから。
これに対する回答は？
> おう、だからやってみろとで俺は言ったはずだが、
そこがお前ずれてるんだよ。
デザパタは「やること」ではない
（誰かが）やったことの知識だ
すでに「やってる」ことに過ぎない
何をやれと言ってるのかさっぱりわからない。
> 理由は「継承」は「デザパタ」よりも古いから。
古いから何なんだよ・・・
最初に継承が生まれ、それを使って
いろんなパターンが生み出された。
継承はパタ−ンよりも古くて当然だよ。
で「継承」は「デザパタ」よりも古いからなに？
> 初学者に継承を教えるだけで、
> すぐに応用例が思いつくわけ無いだろ
いやストラテジーパターンは応用例ですらない。使用例だ。
誰でも思いつくというか、この使い方をする為に設計された言語機能が継承だ。
そして使い方なら言語の説明で一通り為されて居るものだ。
> 継承＝ストラテジーパターンではない。
(意見としては)違うね。
継承を使った場合、ストラテジーパターンに該当しない物を作れない。
抽象度が異なる為、これらは確かに単語としては同じではないが、しかし、
「ストラテジーパターン」という単語を使って説明する適切な場合がない。
要らない単語をいたずらに増やしただけだ。
> その場合、テンメソ、スト、コンポジを別々にする意味はあるのか？
応用例の説明見れば分かる通り
使い方が違うんだから意味あるだろうな。
シチューとカレーなんてどちらもほとんど同じ材料が使われてるが
別々の料理になってるだろ。
お前が言ってるのはそういうこと
いろんなパターンで継承が使われてるが、その継承の
使い方の違いでパターンの違いになるんだよ。
どっちも同じ材料が入ってるから、
「にんじん＋たまねぎ＋じゃがいも料理」だ！
じゃないの
> 何をやれと言ってるのかさっぱりわからない。
お前は本当に馬鹿なのか？
日本語が通じないようならこの辺で打ちきりにするが。
俺は、
> 他の人と知識を共有できないから名前を増やすことで
> 短い単語で言いたいことを表現してるんだろうが ()
について、で求めた、
> 前者は「DLL」、後者は前回も言ったがundoなら｢逆方向履歴｣等
よりも簡単な説明をデザパタ用語でやれ、と言ってるんだが。
> 誰でも思いつくというか、この使い方をする為に設計された言語機能が継承だ。
最初にストラテジーパターンというパターンがあって
継承が生まれただと？
ハハハ
逆
なぜなら
> 理由は「継承」は「デザパタ」よりも古いから。
なるほどお前は池沼なんだな。
> で「継承」は「デザパタ」よりも古いからなに？
デザパタ(1995)以前の「継承」を実装していた言語の仕様書、
例えば「プログラミング言語C++」(1983)において、
> どの言語でも （中略）
> っていうように道具を使った応用例として
> デザパタがでてくるだろ ()
があり得ない、と言ってるんだが。
> 前者は「DLL」、後者は前回も言ったがundoなら｢逆方向履歴｣等
DLLはダイナミックリンクライブラリ
動的にリンクするライブラリと言うだけで、
それだけではどんなものかがわからない。
> undoなら｢逆方向履歴｣
逆方向履歴という機能を実現するにはいろんなやり方がある。
それだけではどんな設計を使うのかが決まっていない
その設計にどんなパターンを使うのが良いのか？
そこでデザインパターンの中から適切なものを探そう
あ、お前今が2017年だってわかってなのか？ｗ
そりゃデザインパターンとしてカタログ化されてない
昔(1995)以前では、言語の勉強の中で
デザパタが登場するわけ無いだろｗｗｗ
昔（お前の時代）にはデザパタ出てこないの当たり前だよーーーーｗ
今は言語の勉強の中で基本の応用として
デザパタを学習するんだよ。
俺の子供の時代にはそんなこと習わなかった
が根拠になっていたとはなｗｗｗ
草ｗｗｗ
> 最初にストラテジーパターンというパターンがあって
> 継承が生まれただと？
お前は本当に馬鹿だな。
継承の典型的な使用例に「ストラテジーパターン」という名前を付けただけだ。
だけど実際は「継承」で全く問題なくて、しかも無駄に抽象化したから使いどころもなくなった。
というかどうやらデザパタ厨はマジで馬鹿で議論が出来ないのは分かった。
他の言葉が通じる連中が出て来たら再開する。
> 最初にストラテジーパターンというパターンがあって
> 継承が生まれただと？
お前は本当に馬鹿だな。
継承の典型的な使用例に「ストパタ」という名前を付けただけだ。
だけど実際は「継承」で全く問題なくて、しかも無駄に抽象化したから使いどころもなくなった。
というかどうやらデザパタ厨はマジで馬鹿で議論が出来ないのは分かった。
他の言葉が通じる連中が出て来たら再開する。
継承の応用例の一つとして「ストラテジーパターン」がある
応用例の一つであるということからもわかるように
継承を使った応用例はいくつも有るから
継承と言っただけで「ストラテジーパターン」を意味することにはならない。
だから「使い方」を言いたいときには「ストラテジーパターン」という必要がある。
継承はベースとなる機能
その継承の使い方がパターンなのである
> その設計にどんなパターンを使うのが良いのか？
> そこでデザインパターンの中から適切なものを探そう
それも俺は要求済みだ。早く答えろ。
> > 逆方向履歴という機能を実装するのに
> 何パターン？ ()
お前は典型的な「都合が悪い物は見えない病気」だな。
まあこの議論を見れば、デザパタ厨がどれだけゴミか分かるだろうから、お前らの布教も捗るだろうよ。
継承の典型的な使用例と何度も言っていることからわかるように
ストラテジーパターンは継承の使用例の一つでしか無い
だから継承といっても使用例が定まるわけではない。
何度も言うぞ
継承の「典型的な使用例」がストラテジーパターンである
だから
・継承を使っているがストラテジーパターンには非該当
の例を出せるか？多分無理なんだよ。だから、
> だから「使い方」を言いたいときには「ストラテジーパターン」という必要がある。
この分離は必要ないんだよ。
この言い方では通じないとは思うが。
継承の「典型的な使用例」がストラテジーパターンである
継承の使用例の一つがストラテジーパターンであるが
継承の利用例は他にも有る。
では聞こう
継承とは何パターンか？
答えるわけがない。
継承の使用例の一つがストラテジーパターンであるが
継承の他の利用例は別のパターン名がついているからである。
継承は道具。使用例がパターン。
使用例であるパターン名を言わないと、
どんな使用例かは答えられない
何度も言うぞ
継承の「典型的な使用例」がストラテジーパターンである 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f)
という言葉の意味が理解できたことだろうか？
そう使用例がパターンなのである
だから
・継承を使っているがストパタには非該当
の例を出せるか？多分無理なんだよ。だから、
> だから「使い方」を言いたいときには「ストラテジーパターン」という必要がある。
この分離は必要ないんだよ。
この言い方では通じないとは思うが。
読め、そして以下の例よろしく
・継承を使っているがストラテジーパターンには非該当
読め、そして以下の例よろしく
・継承を使っているがストパタには非該当
> ・継承を使っているがストパタには非該当
> の例を出せるか？
だせるが？
継承を使っている他のパターンはいくつも有るだろ？
だが、そのほかのパターンまで必要ない
継承の「使用例」がストラテジーパターンだ。
有るパターンが有るパターンを内包しているってのはない。
継承を使ってる他のパターンがストラテジーパターンを内包していること無い。
なぜそんな愚かな勘違いをするのか？
それはストラテジーパターンという使用例を
基本機能である継承と同一視しているからだ。
継承を使っているパターンはあるが
それはストラテジーパターンとして使っているわけではない。
継承とストラテジーパターンを同一視しているから、
そんな馬鹿な結論に至る。
これこそが、継承（基本機能）と応用（使用例）を
別々にしておくべきだという回答の一つでも有る
と説明してあるように
アルゴリズムを実行時に選択しないのであれば
それはストラテジーパターンではない
継承を使っているからと言って実行時に選択するとは限らないからな
アルゴリズムを実行時に選択したい（使用例）ときに使うのが
ストラテジーパターンである
だから、継承を使っていて、
> アルゴリズムを実行時に選択しない
例を挙げてみろ、と言ってるんだよ。
実行時にアルゴリズムを変えたりはしない
ではそれは何の為に継承しているんだ？
機能を利用するために決まってるだろｗ
蛇足だが
ActiveRecordクラスを使わないモデルもあって
その場合は例えばActiveModelを使う。
だが面白いことに、ActiveRecordクラスは継承するが
ActiveModelは継承ではなくinclude（MixIn）する
実際の所コードを再利用することが目的なので
継承以外にもやり方はあるということだ。
そう考えるとActiveRecordも継承するのは必須ではないということになるな。
まあ蛇足だがｗ
> そう考えるとActiveRecordも継承するのは必須ではないということになるな。
当たり前だ。
virtualに対して全くoverrideしないのなら継承の意味はない。
それはある意味、典型的な間違った使い方だ。
そしてお前はそれも分からない馬鹿だということ。
ようやくこのバカも理解出来あってことか。
デザインパターンは使用例（応用例）であって
そこで継承を使っているからって
継承が使用例（応用例）になるわけじゃない
ストラテジーパターンはアルゴリズムを実行時に
選択することができるようにするためのデザインパターン
そこで継承が使われていることは重要ではない。
継承を使うパターンは他にも有る。
使用例（応用例）が論点なのであって、何を使っているかは
デザインパターンとして考えるときには重要な事ではない。
> virtualに対して全くoverrideしないのなら継承の意味はない。
（そこからかーｗ）
は？下がってないぞ。
俺はデザパタ＝ゴミ、デザパタ厨＝ゴミ、で変わりない。
ただしお前が馬鹿すぎて議論は無理だからフェードアウト気味なだけ。
でも、継承の「典型的な使用例」がストラテジーパターンである
という言葉に反論できてないじゃないですかーｗ
所詮、継承は使用例の一つなんですよ。
ストラテジーパターンを継承と言ってしまうと
他の継承を使っているパターンは、すべてストラテジーパターン
アルゴリズムを実行時に選択することができることが重要
だってことになるじゃないですかーｗ
意味不明ですよね
これはデザパタがゴミなんじゃなくて、
すべてはあんたのストラテジーパターンを継承と呼ぶから
こういう意味不明な結論にいなるわけですよ。
そうならないように、基本機能（継承）とその応用例（パターン）
きっちり分けて考えましょうって話なるわけ
何度も言いますよ？
継承の「典型的な使用例」がストラテジーパターンである
「典型的な使用例」です。
間違った使い方はいくらでも出来るんだよ。言い換えれば、
・継承の正しい使用例は常にストラテジーパターンになる
でいいか？
overrideしないで継承するってのは典型的な「便利関数置き場」であって、
駄目だろこれは。
というか、これがありならパターンにあるべきだが、無いだろさすがに。
間違った使い方はいくらでも出来るんだよ。言い換えれば、
・継承の正しい使用例は常にストパタになる
でいいか？
overrideしないで継承するってのは典型的な「便利関数置き場」であって、
駄目だろこれは。
というか、これがありならパタにあるべきだが、無いだろさすがに。
> でいいか？
継承の正しい使用例は常に「アルゴリズムを実行時に選択することができる」
ためのも。
うん。明らかに間違いだなｗ
実行時に選択できる必要ないし
> overrideしないで継承するってのは典型的な「便利関数置き場」であって、
> 駄目だろこれは。
だめでもなんでもない。
有るクラスが、有るクラスを踏まえているならば
（is-a関係）それを表現するために継承を使うべき
継承っていうのは「便利関数置き場」じゃないのよ？
それらの関数を使わなかったとしても
継承関係にあれば継承を使うんだよ。
その他の実行時エラークラスはRuntimeErrorを継承して作る。
そうすることで、全ての実行時エラークラスをRuntimeErrorとして
みなすことができるし、一部のクラスだけは例外的に
その他の情報をエラークラスに格納することができる。
それはまた違う話だ。
1本道で複数継承している場合は、将来的に分岐したり交換される可能性等を踏まえているだけ。
絶対に分岐しないと分かり切っている場合に継承する意味はないだろ。
例えば、メソッド一つ一つ全部バラして継承させて、メソッド20個で継承20階層も出来るが、無駄だろ。
将来的にも絶対にoverrideされないのなら最初から継承構造なんて必要ないんだよ。
ベタにクラス作って終わりだ。
それはoverrideと同じ、というか、メソッドではなくメンバのoverrideになる。
ttp://blog.toshimaru.net/ruby-standard-error/ # `Exception`ではなく
class MyError1 < Exception; end
# `StandardError`.
class MyError2 < StandardError; end
お前さ、基本
1. 自分が○○にたいして馬鹿なことを言う
2. 自分が言った馬鹿なことの対して馬鹿だと自分でツッコむ
3. そのツッコミを根拠に、○○はダメだという
というやり方やってるよね？
○○がだめなんじゃなくて
お前がダメなんだよｗ
・メソッドの継承の正しい使用例は常にストラテジーパターンになる
・メソッド/フィールド等全てについて（将来的にも)全くoverrideしない場合は継承する意味がない
これでいいか？
ならないって何度も言ってるんだがｗ
> ・メソッド/フィールド等全てについて（将来的にも)全くoverrideしない場合は継承する意味がない
意味はある。その例も出した。
結局さぁ、お前、実装のことしか考えられてないんだよ。
設計能力が圧倒的に不足している。
どんな設計を見た所で、その実装が継承使っていれば、
これは継承と呼ぶべきだーって叫ぶつもりだろ？
目的が有る。それがデザパタの使用例や応用例なんだよ。
継承は「何のために」ではなく実現技術
だから継承といっただけでは何をしたいのか全くわからない。
だからデザインパターンで定義されている名前が必要
・メソの継承の正しい使用例は常にストパタになる
・メソ/フィー等全てについて（将来的にも)全くoverrideしない場合は継承する意味がない
これでいいか？
ならないって何度も言ってるんだがｗ
> ・メソッド/フィールド等全てについて（将来的にも)全くoverrideしない場合は継承する意味がない
意味はある。その例も出した。
おれはRuby使いではないからチラ見ではよく分からんが、
見る限りrescueの仕様によるものであって、
Exceptionは派生しまくってるし、特に変だとも思わないが。
メソッド/フィールド等全てについて（将来的にも)全くoverrideしない
継承の正しい使い方だって言ってる
とりあえずID見る癖付けろ。
俺のレスは粘着により複製されてるから。
> どんな設計を見た所で、その実装が継承使っていれば、
> これは継承と呼ぶべきだーって叫ぶつもりだろ？
そりゃそうだろ。
お前は継承使ってても「これは継承ではない！」というのか？
いや派生しまくってんだから、既にoverrideされまくっているはずだが。
> お前は継承使ってても「これは継承ではない！」というのか？
いや？ 継承使っていてもストラテジーバターンでなければ
ストラテジーパターンではないと言うつもりだよ？
お前はストラテジーバターン＝継承と呼ぶべきだって言ってるんだから、
お前はストラテジーパターンでないパターンを見ても、
ストラテジーバターン（＝継承）だって言うんでしょ？
っていう話をしてるんだが？
あんたが表現のロジックを統一しないから代弁してやってんだよ
え？ なに？
世界中の何処かで誰かがオーバーライドしていれば
それは継承使っていいって言ってるわけ？
その理屈だと継承が適切じゃないものなんてないだろうな。
世界中の何処かで誰かはオーバーライドしてるだろうさ
たとえそれが便利関数であったとしても
> お前はストラテジーバターン＝継承と呼ぶべきだって言ってるんだから、
そうとは言ってない。俺は、
・（正しい用法で）メソッドを継承した場合、ストラテジーパターンは自動的に適用されるから、
わざわざ「ストラテジーパターン(ｷﾘｯﾂ」なんて言う機会も意味もない
という立場だ。
抽象度は違うが、分離不可能だし、分離する意味もないから通常は「継承」という言葉が使われる、ということ。
> お前はストラテジーバターン＝継承と呼ぶべきだって言ってるんだから、
そうとは言ってない。俺は、
・（正しい用法で）メソを継承した場合、ストパタは自動的に適用されるから、
わざわざ「ストパタ(ｷﾘｯﾂ」なんて言う機会も意味もない
という立場だ。
抽象度は違うが、分離不可能だし、分離する意味もないから通常は「継承」という言葉が使われる、ということ。
意味不明。
RubyのExceptionは派生しまくっている＝メソッド/フィールド等が既に追加/上書きされているはずであり、
これは正しい継承の使い方である、ということ。
> ・（正しい用法で）メソッドを継承した場合、ストラテジーパターンは自動的に適用されるから、
されない。
されると思っているのはお前がストラテジーバターン（設計用語）を
勝手に継承（実装用語）と読んでいるから、
何度も言うが設計は使用例（応用例）、つまり目的が有る
「アルゴリズムを実行時に選択することができる」
という目的があってこそストラテジーバターンと呼ぶことができるのであって
この目的がなければ、継承を使っていたからと言ってストラテジーバターンにはならない
設計用語を使わないからお前は「継承を使っているものはすべて継承だー！」という
意味不明なことをいうつもりだろって言ってんの。
設計用語を使っていれば「継承を使っているものはすべてストラテジーバターンだー！」
という事になって言葉的には意味不明なことにはならない。
もちろんこれが間違っているのは先に言ったとおり。
設計能力が足りないよ？
> RubyのExceptionは派生しまくっている＝メソッド/フィールド等が既に追加/上書きされているはずであり、
いや上書きされてない。
上書きする必要ようもないしな。
メンバは追加されてるだろ。（多分）
全く同じで階層だけ与えてエントリポイントをずらしているのか？
走だとしたらかなり奇妙な使い方だとは思うが。
メンバは追加されてるだろ。（多分）
全く同じで階層だけ与えてエンポイをずらしているのか？
走だとしたらかなり奇妙な使い方だとは思うが。
> メンバは追加されてるだろ。（多分）
オーバーライドの話だっただろ。アホめｗ
例外クラスは、クラスの階層構造を表現するのに
継承が適切だから継承を使ってる。
すべてのErrorはExceptioであり、実行時に発生するのは
StandardErrorであり、ファイルIOに関するエラーはIOErrorである
という風にだ。
これは設計として正しい。
オーバーライドするかどうかは些細な問題にすぎない。
重要なのは各クラスにどういう関係があって（これが設計）
それをどう言語で表現するか（これが実装）だ
お前がずっとやってるのは、実装だけしか見てないってことだよ。
言いたいことは分かるが、平行線だな。
お前は言いたいことがわかる（俺が言ってることを理解した）
俺はお前が言いたいことがわからない
平行線ではない
それも既に書いたけどね。
読め。
とはいえ平行線ならそれでいい。
すべてはお前が
ストラテジーバターンは継承を使ってるから
設計用語ではなく実装用語の継承と呼びましょう
そうするとストラテジーバターンなんて用語はいらないですよね？
ってことはデザパタ用語は全ていらないんじゃないですか？
使う目的なんか気にせず、実装に継承を使っていれば
全部継承と呼びましょうよ
だからデザパタは意味がない。ゴミ
というばーかな。理屈を言い出したのが悪い。
> 俺はお前が言いたいことがわからない
じゃあ全部読み直せ。
それで分からないのなら、俺かお前の日本語が駄目駄目なだけであり、
どちらにしてもこれ以上は無理だ。
それも既に書いたけどね。
読め。
とはいえ平行線ならそれでいい。
お前の日本語がダメダメだってことだろｗ
お前はコンテキストを理解してない。
設計の話をしている時に実装の話をすんな
全部継承と呼ぶな。それは実装用語だ
ストラテジーバターンの目的として使ってない時に
ストラテジーバターンは継承♪
継承を使っていればストラテジーバターン♪
だから全部ストラテジーバターン♪
とか言い出すなボケ
ストラテジーとは別のバターンとして使っているときは
実装に継承が含まれていようが別のパターンだ
,79,84読め
現実的に使えないから使われてないのだと思うぞ。
これも平行線ならそれでいいが。
そんなことは言ってないんだが、そう読めたのならそれでいい。
現実的に使われてるから、使われてるとしか言いようがない
ストラテジーパターンって何？
ストパタのこと？
もともとPoEAAのActiveRecordパターンという
パターンを実装したものだ
あまりにもRailsが有名になりすぎてRailsのものだと
勘違いしている人がいるぐらいにな。
これだけでも有名で大規模な利用例と言えよう
> 現実的に使われてるから、使われてるとしか言いようがない
これって前から聞いてるけど、お前のリアルなの？
あぁ、レスが遅かったな。
すでにデザインパターンが使われてる例を一つ出したところだ
デザインパターンが使われていない証拠を出せ
デザインパターンが使われている証拠を出せ
これは
幽霊がいないという証拠を出せ
幽霊がいるという証拠を出せ
という話と似ている。幽霊がいないことを証明するのは難しいが
幽霊がいるという証明をするのは簡単
一匹でも幽霊を見つけてくればいい。
だから俺はデザインパターンが使われてる例を一つ出した。
お前は難しい方から攻めてくれ。デザインパターンが使われていないという証明をしろ。
そうだとしてさ、その場合、
「AcriveRecordオブジェクトを継承しといてね」とは言うけど、
「AcriveRecordパターン使ってね」とは言わないだろ、普通。
#define デザインパターン デザパタ
#define ストラテジーパターン ストパタ
#define メソッド メソ
#define フィールド フィー
これでだいぶコード量が小さくできる
他に入れとくべきものある？
だからお前は実装のことしか見れてないっていってんだよｗｗ
視野が狭すぎ
「AcriveRecordオブジェクトを継承しといてね」は実装の話だ
「AcriveRecordパターン使ってね」は設計の話だ。
（実際には誰かに頼まれて使ったのではなくRailsの生みの親のDHHが
考慮した結果AcriveRecordパターンを使っわけだが）
お前は設計がすんだあとの立場からしか見えてないんだよ。
お前の書き込み自体が「○○しといてね」と指示を出される側から見てるのがその証拠
お前は誰かがやった設計の通りに、実装することしかしたことがないんだろ？
それだけのことだよね
いや、指示を出す立場でも同じ言葉だと思うが。
よく知らないが、
> ActiveRecordのようなO/Rマッパーを使うと、
> オブジェクト指向プログラミングができるのはもちろん、
> モデル層の永続化のコードを基本的にライブラリ任せにできるので、
> SQLを記述する煩わしさを避けることができます。
>
ttp://www.atmarkit.co.jp/ait/articles/1104/12/news135.html つまり俺なら普通に「O/Rマッパー」って言うぞ。
それを厨二に「ActiveRecord(ｷﾘｯ」と名付けるのは勝手だが、
何故俺がいちいち名前を覚えないといけないのだ？
ソフトウェア設計者ならパターンくらい覚えるものだろう
仕様書を元に実装するコーダーなら別だが
むしろ覚えるべきは「O/Rマッパー」（一般用語）であって、
「ActiveRecord」（Rails方言）ではないだろ。
言うとしたら「○○パターンを使いましょう」だ
なにもない所から使うパターンを考えることが設計作業なんだから。
設計者が実装者に指示を出すとしたら
「○○パターンを使いますから、必要なクラスを実装してください」か
もしくは「○○パターンを使います。そのために必要なクラスの一部を作りましたから、
あなたは○○オブジェクトを継承しといてね」になるだろう。
そう実装の話。実装の立場からしか物事を見れてないから
設計をすることの意味すらもわからず
設計に実装と同じような指示が存在すると墓穴をほってしまう。
O/RマッパーとActiveRecordは同じ意味ではない。
まずそこから勉強することが大事だよな？
Active Recordというワードで鬼の首取るしかなくなってるように見える
議論の本質はそこではないともうひと方は言っていることがはたから見てても汲み取れる
O/Rマッパーは設計を意味する用語ではない
なにかのオブジェクトとデータベースをマッピングする
という目的のためにライブラリ・フレムワークの種類のことだ。
O/Rマッパーと言ってもそこにどんな設計が使われているかはわからない。
ActiveRecordパターンを使ってるかもしれないし
Table Data Gatewayパターンを使ってるかもしれないし
Row Data Gatewayパターンを使ってるかもしれないし
Data Mapperパターンを使ってるかもしれない
その名前の通りPoEAAのActiveRecordパターンを
実装したO/Rマッパーである
別にO/Rマッパー全てがActiveRecordパターンというわけではない
はいはい、「O/Rマッパー」と「ActiveRecord『パターン』」な。
つかこの辺は普通に脳内補完しろよマジで。
それ前から疑問で何度も聞いているのだが、お前のリアルでは
> 「○○パターンを使いましょう」
と言っているのか？
これも何度も言っているが、ストラテジーパターンに該当するとして、
その際、継承/委譲/関数ポインタのどれにするかで大違いなので、
現実的に「ストラテジーパターンで行きましょう」なんて議論は無理で、
「ここは委譲にしとく？」みたいなことにならないか？
ってことでFA？
Data Mapperパターンを使っている
ttp://d.hatena.ne.jp/naoya/20051024/1130146687 > テーブルの構造とクラスの設計に乖離がある場合、
> その乖離を埋めるためのマッピングを用意してやる必要がある、
> これが Data Mapper パターン。Java の Hibernate とかが
> Data Mapper による O/R マッピング実装。
O/Rマッパーの実装として
ActiveRecordパターンを使ったRailsのActiveRecordと
DataMapperパターンを使ったJavaのHibernateを紹介した
ここからもO/Rマッパーという用語では
設計がわからんという話に納得できただろ？ｗ
それくらいは分かるが、と言うより、
・O/Rマッパー＝OとRをマッピングするもの
であって、それ以上でも以下でもないんだよ。
ただし、中身の実装を知らなくていいというのがOOPであって、それで終わり。
ア、ハイ、実装者側の立場からしか見えてないんですよね？ｗ
中身の設計ぐらい知らなきゃｗ
終わった話を蒸し返す論法も使ってるぞｗ
そのURL読んだけど、それって多分単純にその実装をそう呼んだだけであって、
いわゆるデザパタ(GoF)とはだいぶ主旨が異なるぞ。
まあそれを有り難がるのも自由だが。
めちゃくちゃになるからな。
例えば昔、トランザクションスクリプトパターンと
単なるSQLライブラリばかり使ってきた人が
別プロジェクトでPythonのDjango（これもActiveRecordパターン）を
使ったんだが散々な結果だったよ。
フレームワークとしてActiveRecordパターンを要求されるが
そこにActiveRecordパターンではやらないようなコード
（SQLを実行するだけのようなメソッド）をクラスに生やしたりして。
Djangoフレームワークの実装の中身は見なくてもいいけど
そこで使われている設計はちゃんと理解していなければダメだ。
そこはちゃんと分離して話をしないとダメだと思うの
お前（今までの流れから明らかに力不足）の
感想なんていらんがなｗ
・デザパタはゴミ
・デザパタ厨もゴミ
・デザパタ用語は使い道がないからゴミ
そうだろうね
そしてそれはソフトウェア設計者としては二流以下だというのがこれまでの話の流れだと思うの
もう一つ。
・俺は無能なバカ
これも加えとけｗ
今までの流れで明らかになったしな
それはある。
しかしそれは「フレームワークの中身を知っておけ」であって、「デザパタを知っておけ」ではない。
というより
・俺はデザインパターンとかめんどくさいから勉強したくないの
だと思う
一応それは世間的には区別されているらしいぞ。(wikiだと思ったが、今探したがない)
・自分が思うように使うのがライブラリ
・フレームワークの場合は、自分が合わせる
> しかしそれは「フレームワークの中身を知っておけ」であって、「デザパタを知っておけ」ではない。
「フレームワークで使われてるデザパタを知っておけ」だ
俺はDjangoは当時知らなかったがActiveRecordパターンを知っていたから
使い方が間違っていることにすぐに気づいたぞ
特定のフレームワークに縛られない知識が重要という話だ。
あくまで実装者として立場からしか見れないお前は
今使ってるフレームワークの使い方で精一杯なんだろうけどな。
そしてフレームワークから呼び出されるコードしか書かないから
お前の世界にはデザパタがでてこないわけだよ。
全て理屈が通ったなｗ
だからそれは「フレームワークがActiveRecord前提で組まれている」からであり、
それを「ActiveRecordパターン」と呼ぶのは自由だが、GoFの言う「デザパタ」とは違うって。
まあ平行線ならそれでいいが。
そりゃそうだ。ActiveRecordパターンは
エンタープライズアプリケーションアーキテクチャパターン
ttps://www.amazon.co.jp/dp/B01B5MX2O2/ にのってるマーチン・ファウラーのデザインパターンなんだから
そうだな
デザインパターンをデザパタと呼称する奴はゴミな場合が多い
読め
ActiveRecordパターンとともに紹介されている
Data Mapperパターンを使っているが
Hibernate はフレームワークではない。ライブラリである。
それ前から疑問で何度も聞いているのだが、お前のリアルでは
> 「○○パターンを使いましょう」
と言っているのか？
これも何度も言っているが、ストラテジーパターンに該当するとして、
その際、継承/委譲/関数ポインタのどれにするかで大違いなので、
現実的に「ストラテジーパターンで行きましょう」なんて議論は無理で、
「ここは委譲にしとく？」みたいなことにならないか？
デザパタ厨の皆様、これに答えてくれよ。
何かしらのソフトウェアをゼロから作り上げるにあたっては必ず何かしらの大枠となる基本設計思想や基本構造を構想して行われる
それがGoFのデザインパターンに一致するかもしれないし、新しい独自のデザインパターンかもしれない
デザインパターンという言葉は両者含めての言葉である
つまり、デザインパターンを持たないソフトウェアなど本来は存在しない
お前がなんでそんなことに必死になってるのか？
みんなそう思ってるよｗ
ストラテジーバターンでしか
お前はデザインパターンを否定できないってね。
> これも何度も言っているが、ストラテジーパターンに該当するとして、
> その際、継承/委譲/関数ポインタのどれにするかで大違いなので、
> 現実的に「ストラテジーパターンで行きましょう」なんて議論は無理で、
ここはいろんなアルゴリズムを実行時に切り替えられるようにしよう
であればストラテジーバターンで行きましょう。という議論になる。
アルゴリズムを実行時に切り替えられるようにしようという設計の話で
委譲にしておく？なんて実装の話は出てこない。
それ前から疑問で何度も聞いているのだが、お前のリアルでは
> 「○○パターンを使いましょう」
と言っているのか？
これも何度も言っているが、ストパタに該当するとして、
その際、継承/委譲/関数ポインタのどれにするかで大違いなので、
現実的に「ストパタで行きましょう」なんて議論は無理で、
「ここは委譲にしとく？」みたいなことにならないか？
デザパタ厨の皆様、これに答えてくれよ。
答えたのに無視するもんなー
こういうやつです
デザインパターンとは設計の大枠となる構造や指針であって、それを決めてからより具体的な実装を検討していくってだけなんだが…
だからID見ろよマジで
とはいえ君がならそれでいい。
他の奴も出来ればに回答よろしく。
俺はもう寝るが。
回答しといたぞ
お前もどういう神経なのか分からんが、議論したいのなら普通に入ってこい。
邪魔したいのもお前の自由だが、だったらさらっと入ってくるな。
普通に迷惑行為をしてるんだぞお前は。
デザパタっていうなら省略ポリシーをちゃんと守って書きなって言ってるだけ
デザパタと言ったかと思えばストラテジーパターンと言ってみたり、中途半端なんだよ
そういうやつが書くコードは、ところどころポリシーが違ったりしてるいい加減なコードを書きそうだ
そんな調子だからデザインパターンも軽視するのだろう
ストパンと略すべきだろうな
いやそれはおかしいだろｗ
ストラテジーパターン以外についても前スレでさんざん
○○＝△△パターン、って書いたろ。
まあいいが。
undoすらまともに実装出来ないデザパタ厨が、
何をどう勘違いしたら設計出来るつもりになれるのか不思議だったが、
だいぶ喋ってくれたので何となく分かったような気がする。
まあ後日読み返してみることにするよ。これについてはありがとう。
まあ今日はもうやり合う気はないんだが、多分お前らは設計を根本的に勘違いしている。
例えば、内URLで言うなら、
> Table Data Gateway は J2EE の DAO に代表されるパターンで、
> ひとつのインスタンスがテーブルの全部のレコードを扱うというもの。
> SQL を一箇所に集めることで保守性を上げましょうね、というもの。
普通の人の設計＝後半部分を考えること
お前らの言う設計＝この全文を覚えること
になってる。
ただしこれがお前らみたいに考える能力がない連中にとって現実解になり得るのかもしれん。
これは前にも言ったが。
> 自分がやったことあるところは自信あるもんな
これがお前らの世界観を端的に示している。
経験済みならパターンとして暗記しているから出来るが、やったこと無いと何も出来ない。
最初の卵は絶対に産めないわけだ。
実はお前らがundoをさも難しいと思っていること自体がかなり滑稽なんだがな。
とはいえ新しい意味での「コピペプログラマ」が跋扈する時代でもあるから、
お前らのやり方でもある程度通用するのは事実なのだろう。
デザパタ厨＝コピペプログラマのようだし。
「動的に対象関数を切り替える」と言えば済むだけのところで
「ストラテジーパターン」と言い換えるのは、厨二以外の意味はないと思うけどな。
そして「AcriveRecordパターン」なんて言っちゃうのは厨二過ぎて付いていけない。
「Rails標準O/Rマッパーの実装方式」と言えば誰にでも通じるのに。
とはいえこういう状況も割とよくあるのも事実だが。
デザインパターンもそれと同じだよ
この考え方を理解できない人ってめちゃくちゃ長い関数を書きそうだよね
仕事では絶対に付き合いたくないタイプ
とくに名前ついてないと思うけど
頭の悪い子が無自覚に食い下がるときって、いつもこうなってると思う
だから、いつもの展開だなって思うだけ
おまえら、バターン君これ以上いじっても何の利も無いぞ
もうそっとしておいてやれ
それは君らが枝葉に対してしか反論しないからなんだがな。
とはいえこの意味も分からないのだと思うが。
君らのやり方については名前が付いていたはず。
ID:H5Asg8Dcは頭が悪くて、多分短期記憶領域が非常に狭い。
だから論理的に筋立てるのではなく、言葉尻を掴んで反論してくる。
というかそれしか出来ない。
だがまあ、それでも話す気はあるみたいだから相手してみた、というところ。
最初からちゃんと議論してくれればこの展開にはなってない。
とはいえ、今のID:H5Asg8Dcにこれを求めるのは無理だ。
ただ、こういう、お前らに問題があるのに相手のせいにするというのはゆとりに多いし、
ゆとりは本当に馬鹿だから他のゆとりもそう思ってしまってみんなで同調する事も多い。
今まさにそうだが。
で、そういうのにも上の世代はブチ切れているから、そこら辺は自覚した方がいい。
メメントとあともうひとつぐらい
よくわからんけど、なんでそんなに否定したがるかわからん
これが記憶能力が少なくて名前を覚えられなくて
2分ヒープ木を用いて並び替えする方式でも
隣り合う要素の大小を比較しながら整列する並び替え方式でも
あらかじめ順番通りに並んだバケツを並び替えを行う要素分用意して順番に格納された要素をバケツから取り出し並び替えする方式でも
10進数の0以上の整数値の場合、0?10のバケツを用意しソートを行う要素の下1桁目に対応するバケツに格納する方式でも
バラバラになっている配列データを再帰的に最小限まで分解を行い分解し終わった後、結合を行う並び替える方式でも
動的に対象関数を切り替えるようなやり方をしよう
っていうやつなんやでｗ
デザインパターンな
リアルで恥ずかしい思いしないように今のうちから直しといた方がいいよ
まともな奴だと逆に珍しい
もともとプログラム好きなオタクはもれなくキチガイだし
他の就職先なくてプログラマになったやつも内定取れないだけあって人間性のおかしなキチガイばかり
だからデザパタは使えないってことにしたいんだ
身の程知らず、も初学者にありがちなパターンだよなｗ
コンパイラがバグってるだの
言語がゴミだのOSがカスだの
俺だけが正しくて世界の全員が間違ってるだの
なにか、自分が無敵に思えるタイミングが、学習の初期の初期に存在するんだろうな
前スレ読め
基本的に君は相手が何を言ったのか全く覚えてない。
だから話がループする。
それは君の問題だが、君の場合はそれが常である為に、その異常性に気付けない。
それはマジでヤバいぞ。リアルだったらブチ切れられて終わりのはず。
俺は、デザパタは役に立たない、デザパタ厨は全員undoすら実装できないのが証拠、という意見で、
それでも君が勉強するのは君の自由。
ただここら辺も前スレ818で言ったし、話は完全にループしてる。
結局俺は前スレ812の意見からほぼ修正されてない。
デザパタ厨はデザパタを暗記することが目的になっている。
GoFのはデザパタ厨が主張するように「設計用語」としては多少は意味があるが、（ただし使いどころがないからゴミ）
ActiveRecordとかのただの「実装の一例」を抽象化無しで「パターン」として取り扱うからおかしな事になる。
ただし、デザパタ厨＝コピペプログラマにとってはこれが彼等なりの現実解なのだと思う。
これも前スレ927で言ったとおり。
>デザパタ厨
ってなんすか？
根拠が無いな。
世界中を調べてみたのか？
まさかこのスレだけで判断してないよな？
>デザパタ厨＝コピペプログラマ
これもよくわからんな
デザインパターンを把握してないプログラマほどありもののコピペのつなぎ合わせでしのぎそうだが
明らかだろう。
正解。
アルゴリズムはコピペできるが
デザイン（設計）はコピペできない。
なぜならコピペ元（デザパタのサンプル）は
名前もサンプルだからそのまま使えることはない
え？
実例はいくつも出してるよ。
ごめん
現場で一度も見たことない
派遣で結構たくさん大手まわったけど
マジで１回も見たことないよ
参照
あほ
フレームワーク作ってるなら
コマンド、テンプレートメソッド、ストラテジー、アブストラクトファクトリー
は鉄板でしょ
掻い摘んで言うと
消滅したんだよねｗ
それでいいじゃん
何にこだわってるの？
うん
全部知らない
・デザパタ用語を敢えて使う状況がないから自然消滅した
という気がしている。
だから何度もデザパタ厨に「お前らのリアルで使ってるのか？」と聞いている。
数学なんて役に立たねーってわめいてるバカ学生みたい
使ってるし使われてる。
お前はフレームワークを使うことしかやってないんだろ？
実装の立場でしか見れてない、
お前の仕事は設計が終わった後で設計にたずさわっていない。
そりゃ知らんはずだわｗ
あんたつくづくお人好しだなｗ
数学なんて社会に出ても役に立たない！
って主張はたまに聞くが
その反論は意外と耳に届いてこない
なぜなら、反論しうる層の人々は
そこまでヒマでもないし、お人好しでもない
真顔のままで見下ろしてる
消滅？
なぜそういうことに思考が繋がるのかわかんないっすね
まあundoすら実装出来ない馬鹿がフレームワークの設計とか、あり得ないけどな
なぁ
見たことないよな
msも使ってないし
デザパタサポートしてるフレームワークとかも聞かないし
言ってることがおかしい。
デザインパターンは設計なのだから
「サポートしている」という言い方はしない
よくある設計をサポートしているフレームワークと言い換えれば
おかしいのがわかるだろう？
その時点で間違っているというのがわかる。
設計は使うものなので、デザインパターンの設計が
使われているフレームワークはいくつもある
GUIライブラリはデザインパターンをよく使う場所だし
プラグイン的な仕組みにも使われてる
矛盾する二種類の批判が有る。
一つは
・誰でも普通に使ってるものにわざわざ名前をつけるな
もう一つは
・誰もそんなものを使っていない
おもしろいやろ？
デザインパターンを批判している人同士で
対立してるんやでｗ
え？ボタン押してパターン選択したら必要なクラスが勝手にできるんでもいいんじゃないの？
でも誰も使ってないからそういうのできないんだよ
矛盾してないじゃんｗ
両方成り立つ
大事なのはデザパタのパターンでのやり取りを誰もしてないってこと
明らかに矛盾してるよ
・誰でも普通に使ってるもの
・誰もそんなものを使っていない
> え？ボタン押してパターン選択したら必要なクラスが勝手にできるんでもいいんじゃないの？
あははｗ
それは「デザインパターンを使って設計したもの」
つまり「設計が終わった段階」から
コーディングの仕事をお前にさせる時に
クラスの枠組みを自動生成しているだけだ。
UMLツールがそういったことをやってくれる
お前は設計が終わった後の
実装を振られているだけなんだよ
お前は設計をしたことがない
話の内容を理解しないで言葉だけ捕まえてるじゃん
使ってるって言ってる人はデザパタの構造だけの話でしょ？
使ってないって言ってる人はデザパタのパターンでのやり取りの話じゃん
結局、下の状態でなければデザパタの主旨から外れてるんだから
デザパタは使われてないんだよｗ
意味不明なことを言ってるやつがいたが
デザインパターンはコピペしても意味がない。
なぜなら設計（＝構造）だからだ
自動生成したとしてもファイルや
クラスのインターフェースぐらいしか作成できない
アルゴリズムなどコピペするような処理は含まれていない
あくまで構造だけなんだからコピペしようがない
> 使ってるって言ってる人はデザパタの構造だけの話でしょ？
そもそもデザパタは構造のパターンですが？
> 使ってないって言ってる人はデザパタのパターンでのやり取りの話じゃん
「デザインパターンのパターンでのやり取り」ってなんですか？
パターン♪パターン♪
雛形作ってくれてもいいだろ
デザパタを使ってるなら楽だと思うぜ
シングルトンって押したら勝手にやってくれてもいいしね
だからパターン名で設計のコミュニケーションを取ってないって言ってるの
UMLツールで雛形は自動生成されてますね？
お前が実装担当だからだろ？ｗ
え？
デザパタが指定できるの？
見たことないよ
そらデザパタ勉強してないひとらにあわせてるんでね？
一番レベル低いところに合わせるって日本的じゃない
だから使ってないってｗ
だからデザパタが指定できるっていうのが意味不明
何を指定するんだ？
デザインパターンにはクラス名もメソッド名も
決められていない。（説明用サンプルは実際に使う名前じゃない）
クラス名もメソッド名も決まってないのだからコピペしようがないのがわかるだろ？
UMLツールなどで、デザインパターンを使って
設計者が設計していくんだよ。つまり
デザインパターンを表現するのに必要な
クラスとメソッドを書いていく。（クラス図）
そこから自動生成する。
デザインパターンを使うっていうのは、
コードの再利用じゃねんだよ。
設計レベルの話なんだから
いい加減、実装の世界からしか見れないのは卒業した方がいいよ
本当に技術力不足だから
知っとくと便利ってだけで
だからボタン一発で作ってくれればいいじゃん
visualstudioみたいに
馬鹿だなお前ｗ
まあ、この世に無いものの話だから理解できなきゃいいけどｗ
誰も使ってないから
だから何を作るんだよ？
ファイルならファイル作成ボタンから作ればいいだろ
ttps://www.infoq.com/jp/articles/Design-Pattern-Automation お前が思っているよりも遥かに
高次元レベルでデザインパターンは言語・ライブラリ・フレームワークと
融合していることがからわかるぞ。
この上なにを自動生成したいのか？
>
略
>
> これで、デザインパターンの既製の実装を使って、チームはAOPを学習せずに、AOPの恩恵に浴することができる。
まさにこの現象だろうな。
実装担当者は、すでにフレームワークなどの含まれてるデザインパターンを使うだけだから
デザインパターンを学習せずに、知らずに利用している。
そういうやつら（デザパターンの恩恵を受けてるやつ）が
デザインパターンは（実装者よりも前の設計者が担当が使うものだから）
使わないというのだろう。
視野の狭い事だ。視野っていうか、所詮コーダーって言えば良いのか
> デザインパターンの自動化の使用は、一般的に政治的に敏感な問題である 。
> なぜならそれは、チーム内で関心の分離を対処するからである。
> 典型的には、上級開発者は、デザインパターンを選択し、アスペクトを実装する。
> そしてジュニア開発者は、それらを使用する。上級開発者が検証ルールを記述し、
> 手書きのコードがアーキテクチャを尊重することを確実にする。
> ジュニアの開発者が全体のコードベースを理解する必要はないという事実は、実際には意図された効果である。
>
> この議論は、シニアマネージャーの視点を取り、ジュニアの開発者のプライドを
> 傷つける可能性があるので、一般的に取り組むにはデリケートものである。
ジュニアにはデザパタは不要だよｗｗｗ
ぶっちゃけ、三○もN○Tもニ○ンもコニカミ○ルタもpana○onicもス○エニもシ○ープもN○Cも沖○気もク○タも富○通も
富士○機も東京○力も関西○力もS○NYも
使ってないから
誰も信用しないように
デザインパターンを活用し、最適なIT基盤を提案
ttp://www.nttdata.com/jp/ja/insights/trend_keyword/2013011701.html 見たことねーｗ
連徹過ぎて記憶が飛んだ覚えしかねーわｗ
俺が関わったとこはまともな資料なんて無かったな
俺が実践で使えると思ったのは
N○Cだけだけどね
ここは１回行ってみる機会があれば
いい勉強になると思うな
ttps://www.fujitsu.com/jp/Images/ejb-0312-mda.pdf ttp://www.nagisa.or.jp/training/2017/18j.pdf > 富士通九州システムズ（FJQS）講師：井上 龍也
> ・GoFのデザインパターンを使用したコード記述量削減法
> ぶっちゃけ、三○もN○Tもニ○ンもコニカミ○ルタもpana○onicもス○エニもシ○ープもN○Cも沖○気もク○タも富○通も
> 富士○機も東京○力も関西○力もS○NYも
> 使ってないから
> ここは１回行ってみる機会があれば
> いい勉強になると思うな
派遣の仕事って楽しい？
おさっしｗ
> N○Cだけだけどね
> ここは１回行ってみる機会があれば
> いい勉強になると思うな
NECのこれを受講すればいいのかな？
ttps://www.neclearning.jp/courseoutline/courseId/JV104/ システム開発における詳細設計の位置付け、作業内容、
JavaEEアーキテクチャの特徴を学びます。また
、JavaEEを使用したWebアプリケーション開発に用いる主要な
デザインパターンとその適用方法を設計演習を通して修得します。
そんなんじゃねーよ
ちゃんと要件定義書から設計、実装までルーチンワークで作れるマニュアルがあるんだよ
見てねー奴も多いんだけど
作った奴天才だと思ったわ
考える必要がある設計は不要だよ
お前は何も考えなくていい
ルーチン化できると言う割に自動化はしないあたり本当はルーチン化できてないんだろうなぁ
考えないとわからないところなんて俺らの仕事の範囲ではないのかもな
> 考えないとわからないところなんて俺らの仕事の範囲ではないのかもな
だから設計は、俺ら＝お前の会社の同僚 の
仕事の範囲でないんだろ？
使わないから必要ないと思ってる時点でおさとが知れるというだけなのでは
デザパタが使われていないことを証明できる
デザパタは
俺は使わない
↓
それは使わない
↓
どれも使わない
↓
だれも使わない
↓
使わない
↓
故にデザパタだ誰も使っていない
これなんかObjective-C固有のプログラムガイドかと思ったら
アップルのシステムやアプリじゃ実際にこんなパターンを使ってるよ参考にしてね！
だったっけなぁ…
Objective-C プログラミングの概念
ttps://developer.apple.com/jp/documentation/CocoaEncyclopedia.pdf 現行でこういうのを使いまくった上でiPhoneやiPadが町中で日々動いてるわけで
デザインパターンは無いんだ！デザパタ厨が！とか言われても
おじいちゃん、そろそろ引退したら？としか…
マジ書いてあんなｗ
多くの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：モデルオブジェクトは、自分自身と直接的な関わり合いがあるオブジェクト（一般にビューオブジェクト）の
状態が変化すると、その通知を受け取ります。
Appleはああ見えてソフトの会社だから
そういうとこはしっかりしてる
客の御用聞き会社とは違うやつ）は軒並みデザインパターンが
当然のものとして語られてる気がするね。
関数型のデザイン・パターン、第 1 回
ttps://www.ibm.com/developerworks/jp/java/library/j-ft10/index.html 若気の至りってやつさ
素直な心を取り戻せることを祈ってる
これしか見たことねーけど
使われてるんだな
凝った設計にもできるけど（たとえばDDDのドメインサービスとかさらに突っ込んだDCIのコンテキストベースで）
このくらいの要件なら自販機オブジェクトだけ定義して
在庫管理と商品種別はRDBで管理し、金銭投入→購入のタイミングで
SQLを発行して該当する飲料を商品種別テーブルからピックアップし、その後
在庫管理テーブルで在庫減らしのSQL発行で十分なのでは？
O/Rマッパーの使い方を学びたいならクラス図のようにオブジェクト化するのも手だけれども
得るもんがあったのかどうか
各自寝る前に自問自答してほしい
実装側の視点でしか考えることができないってのがわかった。
これが得たものかな
「結局キャットドアに戻ってきたな」とかだせえリセット図るの。
けっこうおっさん…つうより“じいさん”って歳で構造体から脳が進化してないから
オブジェクト指向側からのアプローチが歳で理解できない可哀想な初老
何の自演だよ？
どのレスと同じやつだと勘違いしたのか教えてくれ
プログラムってどう組んでも動くしね
正解なんてないんじゃないかなぁ？
って思うようになった
仮にあったとしてもそれをどうやって証明するのか？
非常に虚しい気がしてきた
デザパタ、オブジェクト指向使うだの使わないだの
どっちが正解もクソも組んで金もらえたらそれでしめーな話をグダグダうるせーよな給料安いくせに
今、組めている人間を否定することはできない
また、否定する必要もない
俺等が話してることは麻雀のどの牌を捨てたらいいか？みてーな話でどうでもいいんだよきっと
初っ端字牌がないから国士無双は狙っては駄目ですよ
って言ったところで実際に狙って来ちまったらそれを誰が否定できようか？
そんなくだらない内容なんだよ
動くだけじゃダメでしょｗ
最低限じゃん。
動くだけの汚いコードたくさん見たこと有るよ。
でも客からしたらどうでもいいよね
プログラムを組み上げるものとして見てるってことだよね
保守に工数かかるじゃん
無駄じゃん
次の開発が無かったら保守にかけたお金は無駄だよね？
この辺は君等はトレードオフの問題を勝手にプラスサムの問題だと履き違えている
ぶっちゃけ馬鹿にしか見えないのであまりおおっぴらに言わない方がよい
なぜ君等はつければつけるほどお得みたいなアホな考えもってるんだ？
保守なんかねーよ（あるかどうかわからないじゃん）
でもこういう俺の確率が高い方もしくは損害が少ない方に倒す的考えも
所詮は麻雀の捨て牌議論と何も変わらないんだろうな
って話だな
やっぱ意味ねぇよな設計に拘るのはやめたほうがいいな
金にならねぇ
> でも客からしたらどうでもいいよね
いくらでもコストがかかってもいいなんて言う客はいないよ
> 汎用性はトレードオフのはずだ
汎用性の話はしてない
同じコードを何度も書いたり
コピペするとコストがかかるって話をしてる
そうとは限らないよね
一般論だろ
つまり字牌を切るといいよって話だよね
使えない単価安い奴に
やらせとけって話じゃないの
まあ保守は作り始めた時点から始まってるから
リリースまで行けないかもしれないがな
運ゲの麻雀で例える意味がわからない
せめてオセロとか将棋で例えろよ
オセロと将棋だと納得できるんだ？
出来るよ
どっちも定石があるじゃん
そう言うこと
まあ麻雀よりはイメージしやすいでしょ
お前がアホだからできるだけだ
デザインパターンて、将棋における定石みたいなもんじゃん
定石覚えてなくても駒動かせれば将棋はできるけどねー
できなければ定石は役立たずのゴミということ
飛車は移動して右下隅の王を金銀桂馬香車で囲う
って言ったほうがわかりやすいじゃん
そもそも定石なんて知らなくても将棋はできるし、
何十年もやっていれば定石なんて自然に思いつく
デザパタもAIにひっくり返される日も近いなｗ
MVCかMVVMかみたいな
デザインパターンは手筋に近い
何十年もやってれば自然に思いつくことを
数週間から数ヶ月程度の断然短い時間で理解できるようになることや
より高い抽象度で物事を考えられるようになることに価値がある
おじいちゃんに何言っても無駄かもしれんが
AIで新しい定石（デザパタ）ができるってことか？
それは嬉しいことだがｗ
ひっくり返ってそれが有益ならそれでいいじゃん
> 何十年もやってれば自然に思いつくことを
> 数週間から数ヶ月程度の断然短い時間で理解できるようになることや
寿司学校に3ヶ月通っただけの店がミシュランになるなんて許せん
10年間下積みをしてやっと職人になれるんや。
寿司の修行ってのはなぁ、寿司の勉強じゃなねぇだよ
オブジェクト指向設計なんてやってればそのうちできるようになるし、それが人と比べてどうなのかなんて気にする必要もない
人それぞれのオブジェクト指向でいい
カルフォルニア巻き
それをあーやこーや言い合うのが子のスレなんじゃないの
デザインパターンを学習することによる不利益を逆に教えてほしいんだが
麻雀の捨て牌議論といっしょで別に国士無双狙ってもええで
誰も困らん
こっちへどうぞ
Smalltalkとオブジェクト指向議論スレ [無断転載禁止]©2ch.net
ttp://mevius.2ch.net/test/read.cgi/tech/1505709697/
ネタじゃなく本気で寿司屋と比べてるなら
ソフトウェアの世界から早めに足洗って転職したほうがいいよ
お？理由は？説得力ある答たのむね！
せめて会話しようぜ
言葉のキャッチボールをさ
で、おまえらはひたすらごはんを詰め込む係
プロパー様がネタを乗せて最後に元請け営業様がたんぽぽ乗せる
インタフェース名はsushiと予想する
寿司メイカーはストラテジーパターン？
シャリを基底クラスに例えてネタごとにシャリクラスを継承、
軍艦巻インターフェイスの実装とか、お子様にはワサビプロパティをtrueにとか、
そんな話かと思ったら全然違った。
スシローに関して言えばワサビのプロパティは不要
ワサビの状態は複雑だから真偽で取るなんてナンセンス
例えば罰ゲームで使うような山盛りわさび寿司
外国人向けの程よくわさび増量
あと、わさび巻の場合はわさびプロパティの内容はどう持つべきか？
寿司.putワサビ(量)
じゃないの
荒れそう
寿司職人.putワサビ(寿司,量,状態)
かな
キャットドアはやめろ
オブジェクト指向云々とは別のところに問題がある
またこの手の話するならちゃんと要件定義してからやれよ
１つ賢い意見が出たな
要件定義をしないとキャットドアは作れない!
他のものもそうでないかな？
オブジェクト指向でモデリングできると思ってるやつが多々いるのはオブジェクト指向に密接に関係した問題
できないの?
寿司屋はわかりやすくね？
キャットドアやるならまずドアを作ってから継承するなりで基礎がないと
オブジェクト指向が間違っているのでは？（笑）
責務指向とか役割指向の方が適切
enum ワサビ量 {なし, ちょっぴり, 少なめ, やや少ない, 普通, やや多め, 多め, メガ盛り, ギガ盛り, テラ盛り, ペタ盛り, ワサビのみ};
あちこちから飛んでくるし
「これ誰が保守するんだ？」って気分になってる。
ちょっとした修正が今までならピンポイントでテスト合わせて30分位のところが
全体見るために3時間かかる感じ。
能力高くないと無理だと思うけど人手不足だし集められるかな？
もっと緩いオブジェクト指向でいいと思う。
こんなガチガチで上手くいったプロジェクトってあるの？
犬のしょんべんに当たっちまったな
自分以外の奴がソースコードを読めないようにする工夫だそれ
元凶がインターフェースで
継承してあるすべてのクラスのインスタンス作成箇所全部をチェックしないと処理がわからない
チンポをインスタンス化して、引き数にマンコを持つキンタマメソッドの戻り値
ザーメンを取得したいのですが、コンパイル結果がフニャチンになります。
どうしたらいいですか。
それガチガチなんじゃなくて設計や実装が下手なだけ
ほんとにガチガチならそのクラスを作ったやつの後任者〜お前の前任者までの間で間違ったクラスの使い方が広まったんだろうよ
それガチガチなんじゃない。
処理飛ばした後はそいつがよしなにやるから
細かいことは考えなくていい。
というのがオブジェクト指向の売りだから
「コイツはなにやってんだよ！」と処理追うのに混乱するようなのは
基本を履き違えてる気はする。
変なとこから流れてきた自称プログラムのプロがやりがちな
暗号みたいなクラス名とか
実行してみないとわかんねーし
それができてないなら単なる設計ミスじゃん
バカの作るインターフェースは思いつきで入れた汎用性を実現するものだからそもそも設計書に書かれない
そういうもんか
そういう用途で使うべきではないわな
手続き型みたいなのでバグ探すと、大体1ファイルの中見て
処理の流れもその中だけ追えば良くて
シンプルな流れだからチョイチョイってできるけど
完全なオブジェクト指向だと、
｢この値を設定してるのは、ここ、
…、
じゃなくて、コイツ他のとこで設定してるのか〜、
ここ？
あ、もっと上か〜｣
みたいにあちこち辿っていくから
あんまり良いことに感じないけど。
影響範囲も広いし。
考えなくていいのは、製造するときに何が何をすると
ハッキリと決められてる時で
どこにバグあるかとか見るときは
｢ここだろう｣と最初に思ったとこではなかったりしなくね？
設計が難しいなら、
バカでもできる簡単な設計で済む手続き型最強な気がする。
ガチガチのオブジェクト指向ならその値がどこで設定されたなんか関係ないよ
今受け取った値に対しての動きをするだけ
継承多くなるとっていうかある時点でクソ言語になるんだよね
＞
＞手続き型みたいなのでバグ探すと、大体1ファイルの中見て
＞処理の流れもその中だけ追えば良くて
＞シンプルな流れだからチョイチョイってできるけど
これはむしろオブジェクト指向の特徴だね
＞完全なオブジェクト指向だと、
＞｢この値を設定してるのは、ここ、
＞…、
＞じゃなくて、コイツ他のとこで設定してるのか〜、
＞ここ？
＞あ、もっと上か〜｣
これは典型的な手続き型のデバッグだよね
もしかしてスレ加速を狙ってわざと間違えてる？
それ明らかに俺から見て逆だわ
処理に対して一旦オブジェクトで纏めるオブジェクト指向がそこの辺シンプルになるわけねーだろチンカス
あ〜
うん
まあそういう人も居るよね
存在を否定はしないよ
民主主義国家の人民は自由であるべきだ
393で言いたいことはまぁわかる
けど自分が多数派であると思い込んでるのはおかしい
おまえの中の「〜べき」って論は他人に通じないので押しつけないで
いろんなコミュニティに顔だしてみなよ
リアルが無理ならネットコミュニティだけでもいい
が常識的な認識だよ
どこにそんなの書いてあるんだよ
呼び出し元や定義にジャンプする機能のないエディタ使ってると辛いとか
DIでコンフィグから実装を注入してると追うのが面倒くさいとかなら分かる
おまえの中ではそうなんだろうな
繰り返すが393で言いたいことはまぁわかる
> どこにそんなの書いてあるんだよ
いろんなコミュニティ
それは認めるべきだ
オブジェクト指向が好きなやつも手続き型が好きなやつもみんな自由と権利を持っている
でもここはオブジェクト指向のスレなので
手続き型に興味があるなら手続き型スレで議論を深めればいいんじゃないかな？
手続き型システムの設計 1 [無断転載禁止]©2ch.net･
ttp://mevius.2ch.net/test/read.cgi/tech/1500282714/
オブジェクト指向がわかりにくくて嫌いだからといってもオブジェクト指向のコミュニティを荒らしてもいい理由にはならないだろう
住み分けは大事だ
なんだそのキチガイコミュニティ
2〜3個リンク貼ってみろ
潰してくる
スタックオーバーフロー潰してくれ
どのレスだよ
あちこちに飛ぶから云々ってマジでいってんのか
飛ばなかったら全ての処理が一箇所に集まってパンクするだろw
枝から枝へモモンガのように飛ぶ処理が入っていたら地獄だ
責任が遡ったり他へ波及するのを防ぎデバッグも局所化して容易にする思想なので
どこかで一目でわかるように「この値を設定する一意の責任を持つのはおまえ」と
責任を持った誰かがいて、正しく作ってればそこから周りにゴミが飛び散るはずがないので
＞｢この値を設定してるのは、ここ、
＞…、
＞じゃなくて、コイツ他のとこで設定してるのか〜、
＞ここ？
＞あ、もっと上か〜｣
とか、それのどこがオブジェクト指向だ。と同じ感想
だからインターフェースだって
意味わからんけど
どんな使い方してんねん
実装クラスの内部的な挙動を前提にするとかね
リアルで交流しろや
なに？ お前、モモンガ先輩の事ディスってるの？
Javaのデフォルトメソッドとか
利点も何も役割分担できてないならそもそもオブジェクト指向じゃないよ
神クラス
いやだから、インターフェイスってそういうもんじゃん
このクラスはこのことを知ってるべきだ、イヤ知らないべきだ
なんて話がよくあるが
アスペの代表的な特徴として自分の視点でしか考えられない
ということかあるのでアスペにOOは無理
確かにアスペに取り扱いは難しいな
だが言うなればオブジェクト指向はアスペクラスの集合体だからアスペ視点は大切
1人1クラスずつ作るのか
他の人のクラスを利用することがないからゴッドクラスが乱立するな
最悪だ
見積もりしやすいとかいう頭が悪い理由で、画面を作業単位にして割り振るから
神画面クラスがいくつも出来上がる
挙げ句の果てにその見積もりも根拠なしの適当な数字ときたもんだ
お前がアスペだったか
説明できないと何の論拠も無く相手をアスペで片付けるんだね
あるな
メンテの費用たくさん取れるからいいんだよとか言い出す始末
勉強してるのがバカバカしくなる
せめてググってwikipediaや解説サイトぐらい見れば話が合うような言葉を選んでくれ
10人にADHDの説明させたら10通りの回答が出てくる現状では
技術的な議論に使う言葉じゃないと思うんだわ
客も見積もりに意味ないことは分かってるから上司への説明など適当にうまくやってくれる
その辺は阿吽の呼吸ですよ
自分が誰よりも上位にあることを見せかける上で便利だからねアスペ認定は
アスペがアスペを叩いていて笑う
オブジェクト指向にフックを仕込めれば十分であることがわかった
アスペクト指向は「指向」ではなく、オブジェクト指向設計に
組み込む一種のパターン
DIで若干使われてなかったっけ？
実装のまずさを誤魔化す手段という認識しかなかった
属性バリデーション
シリアライズ
apiプロキシ
…
aopは意識しないだけで結構使ってるな
void SomeAppMethod() {
// do something
view.AddMessage("MSG_0123")
// do something
}
こんな感じでリソースIDがシステム中にばら撒かれて制御不能状態になっています
メッセージリソースを管理するクラスを作って解消したいのですが良いAPIが決まりません
何が困ってるの？
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); }
}
それになんの意味があるのかさっぱりわからんな
メッセージなんてでかいプロジェクトだと500個とか行っちゃって
詳細なんかわかんなくていいんじゃないの？
もうメッセージ一覧で確認することは諦めろよ的な
そこまで構えろとはいわんけどそういう性質のものではある
ソースの該当箇所に一つ一つ置いていく手間は省略できない
メッセージリソースIDとメッセージが照合できればそれでその作業は終わりじゃねーのか？
後、何を管理してもらいたい？
ハードコードされた人間可読性ゼロの3000個のIDはそう簡単には管理しきれないと思うが
まあ君の人生だしどう時間を使おうと君の自由だね
私はしっかり管理して時間を節約するよ
する価値ないと思ってもとりあえずでいいから抽象化しておいて損はない
いやぁ、だからさ
ソースのエラー箇所に自動配置なんかできないんだからそこは300だろうが3000だろうが30000だろうが手動じゃん
IDとエラーメッセージが組にさえなってたらどういう構造にしようがやることかわんねーよ的な
ローカライズするならやっとかないと死ぬよ
un = rm.get("property.name.user-name")
msg = rm.get("validation.error.max-length", un, 10)
print msg # ユーザー名は10文字以下で入力してください
スッキリ
それじゃ可読性が低すぎるって言ってるの
暗号みたいにIDばらまかれても保守できないよ
それにのようにIDとメッセージの対応が変わることもある
手間が変わらないなら1つ抽象化層を設けてコードを保護すべき
いやぁでもこの数やる気にはなんないなぁ
体系が変わるのはまた別の話かな
もう完全に仕様変更なわけで落ち着いて対応できる
って言いたい
C#なら素直に.resx使う
少なくとも存在しないIDを使った場合に
コンパイルエラーになる仕組みを使う
種類ごとにグループ化(階層化)して管理しやすくする
メジャーなフレームワーク参照したら分かると思うがMSG_0123みたいな命名自体も悪手
もうどうしようもないのかもしれんが
もう数からいってメッセージのうちのどれ？って判別できる量で終わらんと思うし
IDの命名規則なんて些細なことよｗ
俺の経験で言うと
メッセージID, メッセージテキスト, パラメータ数
Hoge, ほげ, 0
Fuga, {0}はふがです, 1
これをエクセルで管理してメッセージ管理クラスを出力
class MessageManager {
public static string Hoge() => "ほげ";
public static string Fuga(object p0) => string.Format("{0}はふがです", p0);
}
んでデータ数が増えてきたらエクセルをやめてデータベースで管理
エクセルを使えばお客様もお喜びになられるので一石二鳥
メンテナンス性を犠牲にしても
命名負荷を下げたいという意思決定をしてるんならいいんじゃないの
神クラス・神テーブルと同じアプローチだけど
物によってはそれが適切な選択の場合もあるんだろうから
> メッセージリソース管理クラスの素晴らしい設計を教えてください
メッセージリソースなんてものを作らない。
view.AddMessage("あーがこーでどうなりました")
って日本語で書けばいい。
多言語化したいなら、gettextなどの言語やフレームワーク標準の
多言語化ライブラリを使えばいい話。
その場合は、英語でメッセージを書いて、日本語化するってことが
よく行われるが逆でもいいだろう。
責務指向良いね
ゲームはオブジェクト指向でしっくり来るかも知れんけど業務システムだとピンと来ない
相互作用の処理が多過ぎてオブジェクトに閉じない
ゲームとか一定のルールに則った動作をするだよ
メッセージ&イベントだらけになって死ぬな
ゲームは関数型が至高
カントクは一人一人対応なんかしてたら死ぬな！！www」
…いや、間違った理解をした奴はまあそういうドマヌケやらかしがちだが
普通はステージステータスに集約されて、ディレクターは
そのステータスを見て上から必要な個々に指示が送られるように作るからね…
特定のクラス同士の時だけ発生する相互作用とか
どうすれば楽にバリデーションできる？
言語はC#
テキストリソースは全てDBで管理されている
ロケールによってエラーテキストを変えなければならいとする
普通に作る以外にない
ちなみにダメって言う理由は何なの？
あとバリデーション自体と
バリデーション結果に応じたエラーテキストの選択は
分けて考えたほうがいいよ
属性やフレームワークは設定方法がよくわからないのでメンテナンスの時に困るから
ひたすら単調にif文をズラズラと書いてるんだけどシンドイ
項目数が100近いPageもあってそれぞれが何種類かのバリデーションを行うからバリデーションだけで数百行のメソッドになることもある
xmlでルール書くやつは敬遠されるのは理解できなくもないが
単純な属性ベースは分かりやすいしメンテしやすいのにね
楽しようとすれば結局自前で簡易的なフレームワーク風のものを作ることになる
あまりにも数が多いならコード生成という選択肢も
ライセンス的に問題がないものをコピーすればいい
フレームワーク書いたらだめなの？
Frameworkを使わないc#ってどんだけマゾなの？ランタイム自分で書いてんの？
そんな理由にならない理由に従おうとする方がバカ
使った場合に比べて何倍ぐらいの金額を請求する？
どんだけバリデーションばっかやってるプロダクトを想定してんだよ
客に費用の話をするとき、「通常この規模だと20人月ですが、バリデーションライブラリが使えないので+50人月かかります」とでも言うのか
なんでいきなりフレームワークじゃなくてライブラリの話になってんの？
既存のフレームワーク使わずに自作する方が工数膨らむに決まってんだろ
カプコンレベルじゃないとスキル的にも厳しい
工数の膨らみ方が半端なさ過ぎて非現実的ってのが言いたかった
バリデーションのソースってあんでしょ？
バリデーションのフレームワークなんてないでしょｗ
フレームワークの一部としてバリデーションがあるやろ
まず、のバリデーションって、一体何に対するバリデーションの話してるの？
var msgFormat = getResource("error.required");
var label = getLabel("#foo");
addMessage(msgFormat, label);
addCss("#foo", "input-error");
}
以下100項目繰り返し
これ以上簡潔で保守性の高いバリデーションが存在しない件
OOPは物事を無駄に複雑化するばかりで役に立たん
バリデーションとメッセージとUIを一緒くたにするな
どこが保守性高いんだか、見づらいだけだろ
それは普通に抽象化できるだろ
そんなん100個も繰り封ﾔしてたらサブャCボ出るわ
判定と表示は分けようって最初に教わる
俺のコードより明確で保守性の高いコードをかけるとは思えんが
素人は手書きするらしいけどね
プロはこんなめんどくさいコードは書かない
マジで！？どういう仕組み？
簡単だよ
|画面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を収集するようにしてビジネスロジックを集約してもいいけど
今更そこまで設計変えるのは愚策か
これじゃ何やってるかお客様がわからないだろ
素直にエクセルにしろって
条件をお客様が決めるならExcelでもらってのentryを生成するツールを作ればいいだけ
なら最初からコード生成する前提で余計な手書きコードは書かない方がいい
プログラミングの基本すらわかってないのかよ
ここは学生専用だったか？
> 条件をお客様が決めるならExcelでもらってのentryを生成するツールを作ればいいだけ
発想が逆。YAML形式などで条件を書いて
必要ならばExcelに変換する。
Excelなんてサイズが無駄に多すぎて差分の比較もできないから
バージョン管理は事実上無理だろ
お客様が直接読み書きできるってことだな
下手なCSVファイルよりもメンテナンス性が良い
CSVで出して比較できそうだけどな
客や開発メンバーのリテラシーレベルに合ってるなら
無理に違うフォーマットを強要する必要はない
openxmlとか使えば差分比較だけならできる
むしろルールと処理を密結合させても平気な神経のほうが理解できない
そのうえプロを自称してドヤるww
客にExcelを "ルール通りに" 使わせるという
リテラシーレベルをもとめるな
勝手にフォーマットを変える、勝手にセルを結合する。
どこからかコピペした結果おかしくなって直さない
追加分とかいって差分を送りました。そっちで結合してください
とか、毎回人手で対応しなきゃならない作業が発生するぞ。
こっちで決めた使い方のルールを守ってくれやしない
むり、見た目同じように見えても、
レイアウト属性など関係ない情報の
大量の差分までできて管理できない
属性情報は無視してdiff出せるよ
色変えたとか罫線追加したとかそのレベルの差分確認したいとなると
専用ツール入れないと実用レベルでは使えない
ちょっと複雑なヴァリデーションをしようとすると適用不能になる
しょうがないからカスタムコードを書くことになるんだけどフレームワークとケンカし始めるからフレームワークは規約で禁止って流れになる
日本の厳しい要件についてこれる柔軟性の高いフレームワークは無いものか
その辺は上の自称プロさんならVBA使ってルール守らせるExcel作るだろ
俺は別にExcel推奨したいわけじゃないぞ
意味わからん
YAMLで書ける客がどれだけいるんだよ w
そもそも客がYAMLで書けるならExcelに変換なんて要らん、そのままソースに変換するなりすればいい
要件によっては実行時にそのまま読み込んでもいいかも知れんし
まあ程度ならcsvとかで充分だと思うが
> とか、毎回人手で対応しなきゃならない作業が発生するぞ。
どんだけ低レベルの客と付き合ってるんだよ w
例えばこの例だと行を一行追加して、A2にあったWorldが
A3に変わった時の差分はこんなふうに表示される
ttp://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が変化するわけだよ。
それで差分を管理できるわけ無いだろ。
> YAMLで書ける客がどれだけいるんだよ w
こっちでこんな感じで書いてくださいっていうだけ。
それはExcelと同じ。
違うのは、Excelでは条件を指定した所で
見えない情報（フォーマット情報など）が
大量に埋め込まれるということ。
そしてその見えない情報を正しく修正するのが大変だということ
> どんだけ低レベルの客と付き合ってるんだよ w
逆。客のレベルがExcelを無駄に使えるから
セルの結合とか色を変えたりしてくる。
Excelはできることが多すぎるんだよ。
余計なことをなんでもできてしまう。
> ちょっと複雑なヴァリデーションをしようとすると適用不能になる
普通はちょっと複雑なバリデーションを書くための方法がフレームワークに用意されてる。
それに、ちょっと複雑なところだけ別にやればいいだけ。
100個のうち1個のマイナーケースに対応できないから、
100個すべてめんどくさい方法で作りましたとかアホでしか無い。
日本の業務アプリを甘く見過ぎだろ
カスタムコード書きまくらないと対応できねえよ
アホみたいにシンプルなUIしか書かなくてもいいWeb屋はスキル要らないし気楽でいいよな
じゃあバリデーションのすべてがカスタムコードである例を教えてください
カスタムコードとか言いそうで笑えるｗ
そして郵便番号を使うたびに
同じバリデーションをコピペしてるんだろうな。
普通は関数にしてフレームワークに登録すれば終わり
あとは同じバリデーションを使いまわしできる。
単純なものだけではなく、カスタムバリデーションや条件付きバリデーションなんかも
フレームワークの基本機能の１つだと先に言っておこう
> こっちでこんな感じで書いてくださいっていうだけ。
えっ？
YAMLの書き方から教えるのかよ...
Excelでフォーマット守れって言うこともできない客にYAML書けるとか無職の妄想乙 w
バリデーションが正しく機能しているかは
アプリを実行して画面からぽちぽち実際と同じ使い方をして
検証していることなんだよな。同じ内容のバリデーションであっても
項目ごとに検証する。それがテスト時間を無意味に増やしてしまっている。
本来はバリデーションのテストは種類ごとに１つ（すごく当たり前だがｗ）
そして、画面の項目ごとに、想定しているバリデーション名が
設定されているかを設定ファイルを見て確認するだけ。
実際に動かしてテストはしない。
試したけど俺の環境では↓こうなるよ
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
> YAMLの書き方から教えるのかよ...
YAMLの書き方はExcelよりも簡単だよ。
Excelは知らない人が使いこなすためには
数週間とか数カ月かかるが、
YAMLだとフォーマット用意して、
これと同じように書いてくださいで説明終わり。
Excelでフォーマットを守れないのは、
これと同じように書いてくださいと言っても、使い方が難しいから。
俺の母親は、文字の自動補間機能のせいで「1」と入力しようと
しても「10」と補完されてしまって困っていたな。
実際のイメージ
ttps://i.imgur.com/uatG5Vj.png じゃあ今度はある程度データを入れて、同じ内容のセルを結合する前後で
ためしてみそれがどう見えるかを確認したら絶望することになるから
xlsxをテキストに変換してから比較している。
その時にフォーマット情報などいろいろ抜け落ちる。
だから「取り消し線のところは無視してください。」なんてのはわからない。
このようにExcelはなんでもできてしまうから、
重要な情報が抜け落ちる所に書かれてあった時に比較できない。
Excelの使い方が難しい？
YAMLがきちんと書けてExcel使えない奴なんて見たことないけどな
お前のおかんはYAML書けるのか？ w
俺はやるべきだと思うなぁ
だって外人のアプリってそのせいなのかどうなのか知らんけど
よく動いてないじゃんｗ
にはフォーマット情報なんて要らんだろ
どんどん深みにはまってるぞ w
ファイルがでかくなると読み込み速度ヤバイので駄目だよ
実際にはこれの数十倍の検証ルールがあると考えてほしい
フレームワークで簡単にできるなら教えてほしいおねがいします
webアプリ
テーブルをバリデーションする
列は4つでそれぞれinputを持ってる
typeは順に「checkbox, text, text, text」
検索でバックエンドから取ってきたデータがこのテーブルに表示される
これを手入力で編集してバックエンドに保存する
再検索できるが検索時にはバリデーションしなくてよい
保存するときはバリデーションを実行する
メッセージはローカライズすること
すべてのテキストリソースはバックエンドで管理されている
2〜4列目のtextがすべて未入力の行はバリデーションしなくていい
2, 3列目が空白の場合エラー
2, 3列目が整数でない場合エラー
2, 3列目の合計値が1000を超えたらエラー
1列目のcheckboxがONの行の2, 3列目の合計値が10000を超えたらエラー
4列目はオプション
10文字以上の場合エラー
入力された文字列がバックエンドに登録されていない場合エラー
エラーメッセージは重複を排除して昇順に並び替えて所定の ul の子要素として追加する
エラーがあった入力項目は背景色を赤くする
同じ行で1つでもエラーがあった行は罫線を赤くする
> だって外人のアプリってそのせいなのかどうなのか知らんけど
> よく動いてないじゃんｗ
外人のアプリって何？Windows？Linux？MacOS？
どうでもいいけど、列目〜とか言って時点で、画面と密結合してんなーとしか思えんなｗ
列があれば行もあるんだろうけど、一行単位で処理してるようだから、
一行が、一クラスの一インスタンスと考えればよいだろう
1000超えたらエラーなのか10000超えたらエラーなのか分からんが。
画面表示周りにビューの仕事でこれはバリデーションではない。
バリデーション結果オブジェクトを見てビューで表示さればいいだけ（何度も言わせないように）
長くなったのでコードは次のレスに書く
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, if: condition
っていうか全部 if の後の: 付け忘れてたｗ
だからそれは意図して属性情報は差分比較しないようにしてるからじゃん。。
なんなんその言いがかり
セルの結合もデータ的に何を意味してるのかVBA使うやつなら当然知ってるし
データとして使うExcelシートなら書式設定は変更されないようにロックするだろ
その辺のリテラシがないならExcel使うってのは選択肢にはならないわな
すべての属性情報が無視していいとは限らないからね。
属性情報として重要な事が書かれているかもしれない。
そういう無視して良いのがないかわからないのがExcelの欠点の１つ
Excelになれている人ほど、余計な工夫をしてくる。
これはなんの言語ですか?
JavaScriptだとどうなるのでしょうか?
10000を超えないのは複数の行について合計した時の話です
メッセージやCSSの処理はどうすればいいでしょうか？
Ruby & Rails
JavaScriptはしらん。けど大差ないものは作れるだろ
文法上の制約があるとしてんもこんなふうになる程度
validates("col2_value", {numericality: true, presence: true, if: "condition"})
> 10000を超えないのは複数の行について合計した時の話です
一行ごとに保存できるのであれば、保存する時に
この一行を保存するときに10000を超えるかどうかを調べればいい
一行ごとに保存できない、つまりまとめて保存するならば、
一行に相当するオブジェクトに含まれる配列として
テーブル全体を持っておき、そのテーブルの数値の合計を調べれば良い。
> メッセージやCSSの処理はどうすればいいでしょうか？
んなもん、バリデーション結果を返して、そこに含まれるerrorsを
画面に表示すればいいだけ。ローカライゼーションは別の話。
なるほど
なんとなくわかりかけてきました
肝心のエラー情報はどうやって、どのような形式で取得しますか？
検索や保存など処理によって検証内容が異なる場合は似たようなクラスを２つ用意するのでしょうか？
フレームワーク次第なんだんだからそのやり方に従えばいい
> 検索や保存など処理によって検証内容が異なる場合は似たようなクラスを２つ用意するのでしょうか？
似たようなもの＝同じではない＝違うもの
違うなら別々に用意しなければいけないし、
100%まったく同じならば、使い回せばいい。
一部が全く同じならば、同じ部分だけつかいまわせるように切り出せばいい
絶対にやってはいけないのは、違うところがあるのに
似ているからという理由だけで違うものを使いまわすこと
そんなことをするとある修正が全く無関係な所に影響を及ぼしてしまう。
異なるなら別のものを作るのは当たり前の話だ。
> すべての属性情報が無視していいとは限らないからね。
限るだろ ⇒ のデータなんだから w
単語、文字列をコピペしたらいけない。ファイルをコピペしたら
いけないって勘違いしてる。
コピペしたらいけないのは処理だってーの。
処理はテストするものが定義はテストする意味はない。
定義でするべきなのはテストではなくて確認
確認は目視でもOKなんだよ。
バリデーションなんてほぼ定義にできてしまうのだから
テストする項目にはならない。確認する項目。
だからYAMLに分離して、技術者じゃなくても確認できるようにしておけば良いんだ。
ちなみにrubyだとバリデーション結果はどうなってるんですか？
問題はExcelにはのデータ以外の情報も自由に入れられてしまうところなんだよ。
そしてそれがわかりづらい。
RubyじゃなくてRailsな。バリデーションはRailsというフレームワークの一機能
バリデーション結果のオブジェクトの中に
errosってのがあってそこに項目ごとにエラーメッセージが入ってる。
またバリデーション結果のオブジェクトにはvalid?、invalid?メソッドがあって
全体がバリデーションでOKだったかどうかもわかる。
どの項目でエラーが出たかはわかりませんか？
背景色を変えるには入力項目のidとrubyオブジェクトのプロパティとのひも付けが必要だと思いますが
ここも粗結合にしたまま対応できるんでしょうか？
この場合のcheckboxは更新対象を示すフラグっぽいから
2~4列目のモデルの要素とは別にしたほうがいいんじゃないかな
ONになってる行のコレクション対してバリデーションすればいいので
if conditionは全部消せる
だからerrorsオブジェクトの中に項目ごとにエラーが入ってるって言ったろ
> 背景色を変えるには入力項目のidとrubyオブジェクトのプロパティとのひも付けが必要だと思いますが
いらねーよ。
どうせエラー画面がでたら、エラーが出たその項目の値を表示するだろ？
その項目のすぐ下にでもエラー情報だせばいいだろ。
あ？id？ エラー情報の表示にidなんていらねーからな。
まさかと思うが、CSSに全項目書いてたりしないよな。
それならclass使え。アホらしいから
そこらへんはどうでもいいやｗ
重要なのはこの程度でカスタムコード書きまくらないと対応できないとか
思っていたことがはっきりしたってだけ
で、俺の意見はここからさらに先で、Railsのバリデーションコード
あの程度の情報量であれば、YAMLに簡単に外だしできるので、
外出して、客にもレビュー可能にして、価値の低いテストを減らしたい。
YAMLにすればフロントエンド側（JavaScript）でも再利用できるだろうし。
なんでもかんでもクラスに定義するのが良いとは思わないな。
設定ファイルでバリデーションするアイデアはJavaとか他の言語が大昔にとっくに通過していて
世界中でこれは使い物にならんと判定されたものだよ
入力検証はViewあるいはViewModelに属する処理だからプレゼンテーションに入るのが正解
ドメインモデルに入力検証をやらせるのは愚かとしか言いようがない
それはXMLが失敗の原因だった。
XMLにはタグや属性という技術者しか知らないものが
あるからだめだったんだよ。
> 入力検証はViewあるいはViewModelに属する処理だからプレゼンテーションに入るのが正解
YAMLにすることでそれも実現できる
バリデーションは、プレゼンテーションだけのものではない
プレゼンテーションでもドメインモデルでも使われるものだ
言語仕様に組み込むべきものだよ。
本質的にはD言語の契約プログラミングと同じものなんだから
違う
モデル定義とバリデーション定義が離れすぎていること
コンパイルできないから開発環境の恩恵をうまく得られないこと
バリデーションを書くのは開発者であるが開発者に馴染みのある言語はXMLやYAMLではなくJavaやC#であること
これらが問題点
> バリデーションを書くのは開発者であるが開発者に馴染みのある言語はXMLやYAMLではなくJavaやC#であること
あんたはバリデーション処理とバリデーション定義をごっちゃにしてる。
バリデーション処理は動くコードで書くが、
バリデーション定義は動くコードではない。
JavaのXMLなんかも動くコードではないから
これは定義であり、定義の内容をJavaやC#で書く意味はない。
だってただのデータだぞ？ハッシュで持たせればいい程度の情報。
俺もその意見に賛成かなぁ
画面が変わったら変わった画面用のチェックが必要になってる気がするわ
違う
プレゼンテーションレイヤではオブジェクトが不正な状態を受け入れることが前提
不正な状態を検知する処理がバリデーション
ドメインレイヤではオブジェクトは不正な状態は受け入れない
プロパティの不正な値をセットしようとした瞬間に例外
メソッドに不正な引数を与えた瞬間に例外
これはバリデーションではない
ドメインレイヤでは契約を使う
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の内容がバリデーション処理（の一部）
> ドメインレイヤではオブジェクトは不正な状態は受け入れない
> プロパティの不正な値をセットしようとした瞬間に例外
> メソッドに不正な引数を与えた瞬間に例外
> これはバリデーションではない
バリデーションに引っかかった結果をどう表示するか？が
プレゼンテーションでやるべきこと。
バリデーションそのものは使いまわすことができる。
ctrl+vで貼った1GBテキストとかメモリに保持すんの？
それはあなただけが感じる特殊な感覚だよ
世界中のプログラマは設定ファイルを捨て去り属性やアノテーションを使うようになった
XMLよりYAMLの方が多少マシという点は認めるが上記の手法に比べればどんぐりのせくらべといったところだ
> 世界中のプログラマは設定ファイルを捨て去り属性やアノテーションを使うようになった
設定ファイルを捨ててYAMLにしたの間違いだろｗ
どこに持とうがチェック項目は増えても減ってもいないんだぜ
だったら一番やりやすい画面かな
いや増えてる。画面でやると画面ごとにバリデーション処理が増えてしまう。
だから数を減らすにはより中心であるモデルで行う必要がある。
んなわけねぇだろ
今時エロ本の竿役だってそんなこと言わねぇよ
チェックはしなきゃ駄目だよ
JavaのBean ValidationやC#のDataAnnotationsを調べてみればいい
モデルとバリデーション設定を分離して管理する意味がないとわかるはずだ
低能相手ならそうかもな
御愁傷様としか言えないけど w
> ファイルに外だししたからチェックしなくていいですなんて
> んなわけねぇだろ
そんなこと言ってないよｗ
バリデーションという単純な部分を
外だしすると誰でもチェックできるようになるよ。
そもそもExcelでやっていたことだからね。
Excelという使いづらい形式がYAMLに変わっただけ
誰でもチェックできるってことの意味がわかったかな？
あ、YAMLに変わってプログラムからそれを
そのまま使うってところも違うか。
エクセルは誰でも読み書きできる
これはプログラマ以外のステークホルダーも同意している
スコープなんて意識できるわけねーし
っていうか俺でも辛い
xmlを編集できるツールがそもそもねーじゃん
責任持ってお前作って配れよ
いわゆるKISSに原則ってやつですね
if文以外は不要
DAOで抽象化しとけば後から変えられる
メンテできるものにしろ
それやるとメンテが大変になるから辞めたほうが良いよ。
変換などせずそのまま使う方がいい
に賛成票。
設定が正しいか目視で済ませずテストすべき。
目視チェックで済ませたところが往々にしてトラブルの元。
そのテストって実行結果を目視で調べるんだろ？
それか、テストのテストのテストのテストを書くわけないだろうから、
テスト書いて目視でそのテストが正しいか調べるんだろ？
どうせ最後は目視するしかないんだよ。
コードレビューとも言うね。
そんなのをやるぐらいなら
「十分な目ん玉があれば、全てのバグは洗い出される」方式を
利用した方がいいよ。
オープンソースでない場合、コードだと「十分な目ん玉」は集められない。
だから技術者ではない人でも検証可能な形にして「十分な目ん玉」を集めたほうが良い
これはコストのかけ方の問題だよ。重要かつ難しい所には技術者を割り当て
バリデーションとかいう単純な所は、誰でもできるようにして十分な数の目ん玉で対応する
瑕疵期間でも人件費はタダじゃねえからな
別にテストで全部見つける必要はない
瑕疵期間なしって契約ならテストで全部チェックするけどね
コードレビューとテストは目的も確認の手段も違うじゃん
正しいメールアドレスの形式かどうかをチェックする場合とかを考えたら分かるだろ
それに仕様に間違いがないかどうかを誰もが確認できるようにすることと
コードがその仕様通りに動いているかどうかを確認することは
確認する対象が全く違う
自己正当化の論理に聞こえる
> 正しいメールアドレスの形式かどうかをチェックする場合とかを考えたら分かるだろ
その場合だと「ある文字列が正しいメールアドレスの形式か？」という
ロジックは技術者が入念にチェックすべき重要なロジック。
そしてこれはisMailAddressみたいな名前の関数となる。
そしてユーザーが入力したある項目のバリデーションが
isMailAddressになっているか？は目視で確認すれば良い
これは技術者でなくてもできる。
何でもかんでもコストがかかる技術者を使うなっていうのはこういう話だよ。
バカは項目が存在する数だけ、漢字が使えないこと、@の前は.になってないこと
.を連続して２つ以上使わないこと、みたいなチェックをするからな。
メールアドレスのバリデーションが正しく動いているならば、
そのバリデーションを使う場所がいくつあろうが、
そのバリデーションが使われていることだけを確かめれば良いんだよ。
「ooをxxする」という1文にしたいときって、
「社員」と「給料」の2つの目的語があるからどうすればいいの?
>>メールアドレスのバリデーションが正しく動いているならば、
>>そのバリデーションを使う場所がいくつあろうが、
>>そのバリデーションが使われていることだけを確かめれば良いんだよ。
確める内容はそれでOK
でも確める方法が設定ファイルの目視チェックでは不十分。
設定ファイルの各項目が実際の動作に反映されてるか動かしてみないと。
まあシステム間結合テストとか言われるようなテストフェーズでやる場合、実装担当はあまり関係ないことかもしれないが。
誰かがそのテストをする必要はある。
笑えないけど笑っちまった
設定ファイルの記述ミスは存在しない前提かよ
> 設定ファイルの各項目が実際の動作に反映されてるか動かしてみないと。
それは画面やAPIごとに、ここではこの項目が使われていますって
画面に表示するだけでOK。それを目視で確認すれば良い。
> 設定ファイルの記述ミスは存在しない前提かよ
記述ミスは目視で調べろって話だろｗ
何を聞いてるんだか
見ただけじゃわかんねえよw
動作確認を過大評価してないか？
動作確認っていうのは確かに動作させたものに関しは
その通り動くだろうけど、動作させてない所はわからないんだぞ。
偶数かどうかチェックする関数、2と4と6でテストしてOKだからといって
8がOKになるとは限らない。コードのロジックを "目視" して
問題ないことを確認しているはずなんだが？
永遠の時間があれば全て動作確認すればいいだろうけど
実際にはそんな時間はない。だから動作させずに目視で確認できるように
そういう仕組を作っていくことが重要なんだよ。
時間をかけて努力をすることは偉くもなんともない。
なるべく時間をかけずに成果を上げるようにしないと
生産性は上がらないぞ
それは見ただけでわかるような仕組みを作ってないから。
ゲームでよくあるデバッグモードみたいなものを
本気で実装した方がいいよ。
通常のプレイで見えないパラメータを、デバッグする人も見えないまま
デバッグするのは、時間を無駄に消費するだけ
デバッグモードを有効にしたら、見えないパラメータ
例えばこの項目のバリデーションは○○です〜みたいなものを
表示するようにすれば、見ただけでわかるようになる。
とりあえずリリースしちゃいなよ
問題があればそれではっきりするだろ
説得するより怒られる方が楽って昔の偉いプログラマも言ってたぞ
ベータ版リリースとか有るからね。
でも、それはちゃんと発生した問題を自動で
検出して通知する仕組みが必要だよ。
それがないと問題があっても教えてくれないし、
発生した問題の詳細もわからない。
言うほど簡単じゃない。
なんかお前もうヤケクソじゃね？ｗ
お前の主張は誰が見てもありえねーからｗ
反論は、文句じゃなくて、理屈で返してください
だってそんなん
社会で通用しねーのわかってるし
相手にしてお前の馬鹿が伝染ったら嫌だし
理屈で返せない理由がそれ？
でかいソフトを書いたことないだろうな...
コードは正しくても実行するとうまく動かないとか経験したことないだろ
その質問に、
ある と答えた場合
ない と答えた場合
それぞれあなたはなんて返してくるんですか？
いや、どうせどちらで答えても、的はずれな
文句言って終わるんだろうなと思いましてねｗ
いや、もうただの屁理屈じゃんお前の
設定ファイルの読み込み処理がバグってるかもしんねーじゃん
最終的な動作の確認は絶対必要じゃん
お客からしたら設定値なんて
ファイルに出そうがソースに埋め込もうが知ったこっちゃないじゃん
ただ、お約束した機能が動いているかどうかはお客さんとの約束でしょ？
その確認をしないでどーすん？
ならそこだけをテストすりゃいーだろ。
仕事は減らす方向に向かって頑張れよ。
人海戦術で時間をかけたらからって
偉くもなんともないんだぞ
まずはどっちなの？
> その確認をしないでどーすん？
その確認をどーするって、お前は客にテストやりましたって
エクセルシートでも送りつけて、それが本当かもわからないのに
これ見て納得してくださいってやってるんだろ？何一つ証拠がねーよ。
それともテスト作業してる動画を何時間も見せてこれが証拠ですとでもやるつもりか？
コード見せたって客はその内容わからないかもしれないし、
テストコード見せたって、それがソースコードの形じゃやっぱりわからない。
エクセルファイル見せたって、それを本当にやったかどうかもわからない。
間違って記入しているかもしれない。何にもあてにならないよね。
俺が言ってるのは、客にも簡単にわかるような形でデータを作り
そのデータをそのままプログラムで使えって言ってるの。
客がそれみて納得すりゃそれでOKだし、そのファイルを
直接使うからもちろんその通りに動く。
客の検収作業が、そのまま目視による確認になってるんだが。
メールアドレスじゃなく郵便番号くらいを例にしたほうがよかったかね
どういうメールアドレスを正しい形式とするかは要件によって変わってくるんだよ
RFCがあるからといって技術者が勝手に決められるものじゃないから
簡単な郵便番号の入力チェックでも
何をOKとして何をNGとするかは要件次第
その「目視の確認」で一体何が担保できるんだろうね？
1500001
150-0001
１５０−０００１
150 (旧３桁)
150-01 (旧５桁)
150-9999 (存在しない)
あらゆるケースをすべてテストできるわけでもないしするべきでもないが
仕様通りに動くと自信を持てるレベルのテストはすべき
はぁ？馬鹿？
設定ファイルが間違ってる可能性は？
読み込みはうまく行っても
値が反映されてない可能性は？
それが設定ファイルのある特定の設定値だけバグる可能性は？
まあ、普通に仕様通りに動くこと確認した方が早いよね？
> どういうメールアドレスを正しい形式とするかは要件によって変わってくるんだよ
> RFCがあるからといって技術者が勝手に決められるものじゃないから
>
> 簡単な郵便番号の入力チェックでも
> 何をOKとして何をNGとするかは要件次第
> その「目視の確認」で一体何が担保できるんだろうね？
メールアドレスや郵便番号でもなんでもいいが、
ある項目が「メールアドレス」や「郵便番号」であることが担保できる。
これにより仮にバグがあったとしても、一箇所を修正するだけで
すべてが修正されることが担保できる。
動かして確認する方法だと、ある箇所のバグが修正されたからといって
別の場所も同じように修正されるとは限らない。
目視の確認ができるようにしておくことで、工数が大幅に削減できた。
ならばそこだけテストすればいいだろって
さっきも言った。
目視の確認ではない。テストだ。
想像力足りなくてもこういうの経験ないのかな？
経験不足もあるのかな？
考えが幼いよ
じゃあ、普通に全部テストするってレスしてるよね？ｗ
お前関数って知らないのか？
共通化の基本テクニックだぞ？
全てのメールアドレスや郵便番号の項目で
同じ関数を使うんだよ。
テストをするのはその関数のみ。
バリデーションとしてその関数を使っているかどうかを
設定ファイルに書く。
何度も同じ話をさせるな
かんけーねーんだよ
何度も言うけどファイルに出したのはテメーの勝手なんだよ
動くかどうかを証明しろって言ってるの
何が必要でしょうか？
見えない情報がある時点で、動かした所で
どんな場合でも動くとは証明できないってのは理解できてる？
ソースコードを読めば動かさなくてもわかる問題でも
ソースコードを隠した状態だと動かした結果だけでは証明できなくなる。
俺の質問に答える気はあるのかな？
もちろん答えは千差万別だが
お前のソフトが動くことの証明をして欲しいんだよ
一度でもソフトを納品したことがあるならわかるよね？
上司におんぶで抱っこでそんなこと気にしたことなかった？
> お前のソフトが動くことの証明をして欲しいんだよ
なんでお前もできてないことを俺がやらんといけないの？
って言ってるんだが。
動くことの証明はソースコードを見せる以外に不可能なんだよ。
これだけやりました。やったという証拠です。信じてください。
バグはないと思います（実際には有るだろ？）
という意味でしかない。
気にしたことなかった？
証明するものを出したというのであれば、
それを言ってくれて良いんだが？
バグが有ることは証明できるが
バグがない（正しく動く）ことは証明できない
常識なんだがねぇ。
おお、よくわかってんじゃん
じゃあ、それをお前はどうやってやるの？
え？ 信用してくださいドキュメントの話なんかしてないじゃんｗ
今まで通りのやり方で適当にでっち上げれば？
俺は少ない手間で必要十分なテストをするだけの話
いいや
ソフトウェアって上から下まで
さっきお前が言ったとおり
確実なものなんか何一つないよ
お前の十分だってお前の中の十分だろ？
俺等とは違うの
その差分を俺らとは違うお前は自分で埋めなければならない
そこに理屈はない
それが説得ってもんじゃん
人を見るのが嫌ならこの業界は向いてないね
無能なお前らと違うと言っても
だから何としか言えんわｗ
結局、テスト仕様書もテスト結果も
全ては説得なんだよ
理論に飛躍があり過ぎる
ウォーターフォールのV字開発で
設定ファイルに外だししたから
テスト項目減りますなんざ
あり得ない理論なんだよ
まあ、当然説得なんで可愛い女の子が交渉してくれば通る可能性も無きにしもあらずではあるけどね
>>>> 設定ファイルの各項目が実際の動作に反映されてるか動かしてみないと。
>>それは画面やAPIごとに、ここではこの項目が使われていますって
>>画面に表示するだけでOK。それを目視で確認すれば良い。
なるほど。
各項目のUIを一通り動作させて、
で書いてくれたようなデバッグモード的表示やデバッグログで、動いたバリデータの書類を出力するってことならよさそうだ。
それなら設定ファイルの内容および設定ファイルの配置の正当性が確認できる。
テスト仕様は要件定義から作成すべきだし、その実施も単体、結合レベルは機械的に掛けてもいいけど、総合は手でやるべきだろうなぁ。
「テスト対象はまともに動いていない」という仮説を、ケース毎に一つずつ潰していって、残るのが「正常に動いてる」って結果なのが試験で
「正常に動いてる」が先に立って「なぜならこう書いたから、こう動くはずで、現にそう動いてる」ってのは試験じゃなくて単なる確認では？
正直、単体テストでもテスト対象を作った言語を使わないでテストして欲しいところ。
場合によるので「どちらも」が正解
個人の話なのに場合によるとか頭大丈夫？ w
つまり、何らかの目的があって、それを目指す（「指向」は向いているだけ）というわけです。
Objectは単純に『物』の意味だよ。
典拠をご提示いただきたい
まず自分が提示しろ
senderを自分で生成する方法
ttp://bbs.wankuma.com/index.cgi?mode=al2&namber=85371 お、おう。。それもJittaさんか…
面白い捉え方だと思うけど
Object Orientedという言葉が出てきた歴史を調べれば
「目的指向」が誤訳なのが分かるよ
ttps://en.wikipedia.org/wiki/Object-oriented_programming#History Jittaさんが言ってることの方がガセネタですね
じゃあそれを根拠にわんくまに怒鳴り込もうと思います
ありがとうございます
Objectって単語は、モノと言うよりも「認識できる何か」「動作や感情の対象」を指す。
動詞になると顕著で、「俺はこれに文句があるんだが」ぐらいキツい意味。
「I object to waiting」みたいな。
Ob + ject 。前に向かって投げたやつ。客観的に見ることができる物、が語源。
逆に、中に投げ入れるモノがinject。下に投げたものがsubject(自我、主観)。
単なる「モノ」はだいたいbody、matter、substance。
physical bodyとか使う。
天体の「体」もbody。heavenly-body。
素晴らしい「モノ」
優れている「モノ」
高品質な「モノ」
高機能な「モノ」
のモノはどれになるの？
も追加しよう
つまりJittaさんが大正解ってこと？
objectではないけどしっくり来る
いいね！
POAのProcessやDOAのDataにだって責務は有る
他と違って「オブジェクト」という抽象概念を中心に物事を考えるからオブジェクト指向という名前
んでオブジェクトってのは↓
a data structure that can contain functions as well as data, variables, and other data structures
ttps://www.merriam-webster.com/dictionary/object ・カプセル化、継承、多態性をサポートするもの
・JavaやC++、Rubyなど
Object based languageは
・継承・多態性をサポートしないもの
・VBなど
orientedはbasedと似たような意味で、basedよりも多くの条件を規定する。
Object based languageを「オブジェクトを基本にした言語」と解釈するならば
Object oriented languageは「オブジェクトを本位にした言語」と解釈するのが妥当な気がする。
「本位」は中心にして基本にするという意味なので「基本」を強めてる感じ。
やっぱそうだよね、オブジェクトを中心にするっていうのがオブジェクト指向だよね
オブジェクトじゃわからない
Objectはなんて訳すのが適切なのか
の歴史を見てほしい、翻訳してほしい、よろしくお願いします
新しく作るか (例 経済)
既存の言葉に新しい意味を持たせるか (例 自由)
ちなみに中国語訳では「対象」らしい
good one,
better one,
high-quality one,
とかでは？モノと言うよりは、何か指しとるでしょ、その言い回しで言うときには、モノは。
事象、作品、道具、衣服などなど、それだけでは存在に意味が存在しない類のやつ。転じて、流行りとか、大事な事を指したりする。
役割主体、役割本位
「モノ」「箱」「塊」とかなんでもいいような気がしてきた
どうせ実際に使う時は「社員」とか「敵機」とかになるんだし
「”もの“を複製して別な”もの“のパーツとして使う」
これわかりやすいっしょ？
どんどん再利用パーツ増えて複雑になってったらこうじゃないとキツイっしょ。
で提唱されたってのに、すぐにベテランプログラマーさんは
「この名前さあ、タイプすんのめんどくさいから「あ」「い」「う」でよくね？」と他人にわからない暗号にしたがったり
「オブジェクト指向ってさぁ、オブジェクト単位に分けるんっしょ？この再利用しない中身もさぁ
ぜんぶ用途別に名前つけてパーツに分類整理しなきゃ！」とかやりなさる…
プレスの金型と、それで作り出した製品くらいの言い方の方が伝わる。
たまに金型に便利な治具ついてることもあるし、付けることもできて、それはプレスせずに金型から直接使えますが、
その治具にメモとかつけると皆から見えたり、誰かに剥がされたりするので、必要がなければ製品に付けたほうがいいですよ、
何回プレスしたかのカウンタとかは治具につけたら良いですね。みたいに説明した事ある。
スーパークラスとかサブクラスも、同じように、互換品の金型と互換品とかそういう説明できるから、物理な型で説明すると割とわかってくれる。
わかるわ。耳が痛い。教育することになって逆に知る事も多かったしな。
若手の新アイディアは、素直に教えてもらってる。
たまに俺が相槌しか話してないうちに「出直します」って言うから、どうやらテディベアとしても活用されてる模様。
気持ち悪い
まずはオブジェクトを理解させることからはじめないと
クラスやプロトタイプは二の次でいいし
責務や役割は別レイヤーの話
IT後進国の日本ではまだほとんど導入されてないね
非正規化DB 、非レイヤー化、貧血ドメイン、トランザクションスクリプトが主流
3Dゲームはよくやる
結構やってるでしょ
エヴァンス本から何年経ったやら…
完全に対立してるな。
個人的には比較的昔からある企業は前者で、若くて成功してる部類の企業は後者かな？と思うけど。
実際DDDやってるぜー、て現場はどういう特性なんだろ。
実装含めて厳格にDDD導入してるのとで違うよね
前者は多いけど後者は少ない
は実装者の視点
は要件定義・設計者の視点
おそらく
DCIでやったときとの違いも知りたい
まず本人を召還して質問攻めにする
業務アプリを受託で開発するのが主戦場
iOSと同時開発必須
自分で直接販売するのはバクチだね
アプリ数多いといってもニッチはまだまだ足りてない
別に複数あっていいと思うが
社員給与を振り込む
給与の分類か属性かで
給与は社員に与えられるものだから
「社員に対して」は要らなくね？
お金を移動させる
目的語でひとくくりにするとわかりにくいけど
日本語では名詞が述語をどう修飾するかは格で区別されるから
格を考えればよいかと
1.「振り込む」が述語ならば振込先は口座なので「社員の口座に」としたほうが良いかと
振り込む(社員の口座に:与格, 給料を:対格)
2.「社員に」を使うなら述語は「支払う」かな
支払う(社員に:与格, 給料を:対格)
3. 対格しか使いたくないんですということならば「社員の」という属格で対格を修飾するしかないんじゃないかな
振り込む(社員の給料を:対格)
法令データベース「e-Gov法令検索」リニューアルにあたり、同法情報研究センターの協力教員である名古屋大学情報基盤センター（センター長：森健策）の外山勝彦（とやまかつひこ）
有識者のみなさんはどうやってるの?
つまりドメインのクラスが個々に
直接SQL文でDB叩いたりしない
例えばドメインクラス「作業時間」にhogeプロジェクトの作業時間を問い合わせた時、作業時間クラスがDBクラス使って作業時間を教えてくれるんじゃないの?
この辺解らないとパフォーマンスの問題でアクティブレコードに走っちゃいそうです
たとえばソシャゲみたいなWebアプリをイメージしてみよう
一個アイテムを見るたびにDBアクセスしてたら重いから
画面を遷移するときにまとめてローディングするよな？
だからそういう風にインフラ層で
ある程度まとめてデータ取ってきて
ドメイン層の内部ではDBに直接触らないようにする
それはレイヤ分けるメリットでなくて
レイヤ分けるデメリットをカバーする方法じゃないの
あらかじめオブジェクトにぶち込むのかな
油断するとメモリ食いそう
集約の単位が間違ってんじゃないの
昔は画面単位にデータ取ってたけどトランザクションスクリプトアンチパターンになるから作業時間とか予算とかドメインでクラス分けたんだ
それぞれのクラスがデータベースに問い合わせるからウッホという状態に
基本は集約一つにリポジトリ一つ
レポーティング用途の場合はドメインモデルやリポジトリを経由せずに
DBレイヤーに直接問い合わせるのも有り
ドメインモデルを経由しなければ
ドメインロジックが分散する可能性があるのでトレードオフを判断したり
それを避ける工夫が必要だったりする
Patterns, Principles, and Practices of Domain-Driven Designって本で
一つの章使ってレポーティングの実装パターンを紹介してるので読むといいと思う
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とドメインオブジェクトのマッピングを手書きするってのはそれはそれでめんどくさい
AutoMapper
AutoMapperってやつそんな賢いの?
集約をそのまま永続化したいんだから
使わないなんて考えられない
どうかな
さっきも書いたようにDDDに忠実にドメインモデルを構築するとpublicプロパティが無くなって完全コンストラクタでインスタンスを構築しなければならない
DTOのようにフラットな構造にならない点でもORMで扱いにくい
RDBは個々のオブジェクトではなく集合としてのビジネスルールを表現するのに適している
単なるデータストアではない
1ヶ月の間に正当な休暇を間に挟まず3営業日連続で欠勤した従業員にはペナルティを与えるといった業務ルールがあったらSQLで解決するほうがスマート
いまどきORMのために可視性を変えたりしないでしょ
> そもそもDBが単にオブジェクトの置き場所になるってのも疑問だよ
DDDだろうとトランザクションスクリプトだろうとDBの役割は変わらないよ
ドメインモデルから見てあたかも単なるオブジェクトの置き場であるかのように振る舞うっていうのは、
そう振る舞うように作ってるからそうなるのであって、DBから見たら、アプリがDDDで作られてるかどうかなんてわからない
じつはそういう考え方もアリだと思う
SQLやPrologでビジネスルール書くのもアリ
でも現実的にはDDDの
インフラ層にDBを隔離するやり方が無難だと思う
SQLでビジネスロジックを表現すると
シンプルな例だと分かりやすく感じても
実務レベルの複雑なルールでは非常に難解になる
OOでチマチマ差分を書いていく方が分かりやすい
これはなんでOOが主流なのかの理由でもあると思う
ひっかけっぽい例だな
SQLかじったレベルじゃそれは書けない
普通にアプリでやったほうが柔軟性高そうだ
RDBMS主体でやるプロジェクトもあるだろ
ただ古臭くて不便なことが多いからか
アプリケーション側でやるのがほとんど
技術者の数も違うからかな
1クラス1メソッドにSQLをぎっちり書いていてくれた
流石データベーススペシャリストだと思った
単なる指示ミス
チームリーダーは電気寄りのC使い
JAVAの実装にはノータッチ
ソフ開持ってなきゃね
みたいな奴が指示する立場なわけないだろw
データアクセス層でオブジェクトにマップしたらもう二度と中は見たくない
javaはともかくJAVAって書かれると
あっ・・・（察し）ってなるから気をつけて
アスペすぎるだろ
お前が気をつけろ
Javaの方は書籍とかもJAVA表記多いよねぇ
そんな表記は本質に全然関係ない
まともなコード書けるやつだと思えるの？
Java - 言語。
JAVA - 茶。
VBの絵本でプログラムを覚えました
非常に解りやすく良書だと思います
御社のお役に立ちたいです
不採用
わろちんこ
ワンピース
で、大卒正社員PMがクラス作った俺を高卒非正規はスキルが無いと滅茶苦茶言ってる
帳票の抽象クラスとそれを継承した3帳票のクラス作っただけなのに
つかボタンイベントで作られるメソッド以外禁止にする勢い
全部のメソッドに同じ処理をコピペしてるから修正の影響範囲がわけわからん
意外と侮れんぞそれ
カスなチームでまともな自分アピールならマ板でやれよ
そうは言っても仕事で
オブジェクト指向のメリットって
説明できんやろ？
やれるもんならやってみいや
何もできんということは覚えておいたらええよ
同じコードをどこにコピペしたかわからんなるぐらいなら
クラスで一括にしたいなぁ
俺じゃなくて大卒正社員PM様に説明して差し上げろ
そいつここに呼んでこい
精神崩壊するまで論破して追い込んでやるよ
黙れ無職、はい論破
規模が大きくないか、仕様が変わらないようなところなのかもしれないし
個別に修正するときはコピペした方が影響の範囲は小さくなるし
一か所見れば処理がわかるってんならコードの見通しもいいし
ソースコード見ない段階であれこれ言うのはちょっとちょっとちょっと
作ってお終いなら俺は文句言わないよ
改造とバグ修正を投げられたから困ってるんだ
関心が分散しまくってる
高卒非正規の脳じゃオーバーロードだ
そして無職か
早かったな
つかクラス化した場合の有効性をコストで可視化しろって
もうバグ満載でリリースしてデスマーチコースだ
IT業界らしくなってきた
ごめんけど、ここはオブジェクト指向を諦めた人のスレじゃないから
コピペだらけのトランザクションスクリプトが至高だと悟ったなら、それでやっていけばいいじゃん
わざわざ啓蒙しに来なくていいよ
返信先間違えてない？
横からだがそれはコピペコードを勧めてるおじさんたちに言うべきだろ
共通のメソッド作ればいんじゃない？
クラスが駄目なら
言語何使ってるんだ?
オブジェクト指向言語のAPI使ってないってこと?
よくわかんだね
throw new AppException(ErrorCode.ERR12345);
throw new AppException(ErrorCode.BlogPostNotFound);
throw new BlogPostNotFoundException();
AppExceptions.ThrowBlogPostNotFound();
IAppException appExceptions = GetService<IAppExceptions>();
appExceptions.ThrowBlogPostNotFound();
どれがいい？
シングルトンをどこが持ってるかが重要なんですか？
安定のVB
話になんないな
なぜ話にならないの？
みたいなことを言って恥をかくと良いよ
オブジェクト指向でプログラムを作ることにはならんでしょうに
staticメソッドを中心にプログラム組むことだってできるし
それなりの規模がないとオブジェクト指向は効果を発揮しないのじゃないかな
昨今は実装の継承はあまりやらない方がいんじゃないかって言われてるし
旧VBはオブジェクト指向言語と言っていいと思う
旧VB+ラムダ式の言語があれば最強な気がする
IoCは概念
DIはデザインパターン
シングルトンはゴミ
ポリシーのない言語の何を話せと
あれあれ？ポリシーがないってだけ？
そのポリシーとやらは
オブジェクト指向にどう関係してくるんですか？
言語に善悪はない
「ええ、ビジュアルベーシックで絞り込めば…」って言ってたし(ガクブル
VBに毒されたものの末路だな
そりゃBASIC構文だからな
BASIC構文でラムダ式とか記述に無理がある
Coreになってからさっぱり話題にならなくなったけど
8割がスマートUIを書きモダンな設計を読みにくいと一蹴する
4重ループにカウンタ現役
正規化した物理設計レベルじゃ違うけど外仕レベルじゃ同等になっちゃう
RDBMSの最適化進めてくと違ってこないか
後からクラスだけ変えるのもあるし
内部設計になってDBの正規化始めると確かに違います
ただ外部設計ではほぼ同じになるのでER図とクラス図に差が無いんです
ER図要るのかこれってなるので世間様はどう折り合い付けてるのか気になりまして
データベースなしの状態で動くところまで実装してようやく、そろそろ永続化の実装考えようかって話が始まる
そのDB使う他のアプリケーションには必要だろう
APIを用意してくれ
やりたいけど構築するのが面倒だ
誰か代わりに作ってくれ
クラスに格納されたデータという名詞的実体に安堵しているだけで
プログラムを書く才能も、システム設計する能力もないやつが
好き勝手にクラス図をかいて、ぼくのさいっきょなクラスチームを作るだけなんだよなあ
だから僕の考えたクラス構成という話題は出ても
そのクラスがどのように通信するかっていう話をオブジェクト指向信者は語らないの
なぜならばそのメッセージングを実装できないから
そのすばらしいクラスが単なるデータの塊でしかないことを
自分で書いた壮大な物語でカプセル化し、他人から見えなくしたいから
カプセル化って偉大だよなあ？
電卓やじゃんけんすら実装できないひ弱な自分を壮大なクラス図を書けばごまかせると錯覚できちゃうんだから
VB馬鹿にするやつがどれだけオブジェクト指向理解してんのか疑問だな
それならオブジェクトをシリアライズして保存した方が楽かな
キーは要るけど
さすがに時代錯誤な感じ
今どきのメジャーな言語は
ほとんどクラス持ってるぞ
Java、C#、C++、Python、Ruby、PHP……
PHPをそこに並べる違和感
あとついでに無名クラスを持っている言語
PHP、・・・
クロージャーを持ってる言語
PHP、・・・
トレイトを持ってる言語
PHP、・・・
ジェネレータを持っている言語
PHP、・・・
のに、バカがこぞって使うからクソ言語扱いされている。
10年前に見かけた与太を今日話すことに違和感をおぼえる知能もない
プログラミングできるわけじゃないから、技術的な話にも初心者の質問にも応えられない
「ただ」「昔見かけたもの」を「書く」だけ
VB6のコードをそのままVB.NETに移植する仕事を何度したことか
ゴミを移植してゴミを作る仕事
> VB.Netはもう20年ほど前に完全に移行しているんだけどなぁ
VB.netのリリースは2001年（16年前）なんだが...
> VB馬鹿にするやつがどれだけオブジェクト指向理解してんのか疑問だな
人の心配する前に自分の認知症の心配した方がいいぞ w
20と16の区別もつかなくなってるのか w
すなわち、20=16、とな
天才
なら020って書かなきゃね
C系と記述が違うのに先進性は無いとか鬱になる
ttps://blogs.yahoo.co.jp/kamyu_2010 にデザパタ解説を発見した。 マルチポストする前に文章を見直せ
デザパタじゃなくてデザインパターンな
ペチパーやドザーみたいな愛称だろアスペか
アスペじゃなくてアスペルガー症候群な
文脈的に、アスペルガー症候群じゃなくてアスペルガー症候群患者な
これがアスペルガー症候群患者なんだな
ガチアスペルガー症候群患者乙
重症やな w
重症やな w
ガチアスペルガー症候群患者乙
↓
オッサンか？
ガチとか使う奴=低脳、バカっぽいって発想がオッサンぽい
ごめん、どうみてもお前の方がおっさんだよ ww
ttp://i.imgur.com/sWco4kY.jpg 興味ないから
え？おまえって未成年か何か？
残りの9割は脂肪です
ホモはお帰りください
若い時に心酔して、経験積むうちに忘れていたが
ようやく言わんとすることが分かつて来た
つこてるマメがちがうよ
あるかないかだと思ってるんだけど、
DBのテーブルって継承はないわけじゃん、
継承とか知識レベル/操作レベルってDB設計的には
どう対応するの？
継承に相当するサブセット(部分集合)の表現は存在している
明らかに欠けているのはメソッド(ストアドプロシージャ)かな
データ保護に対しては各種制約を設けるしかない
それらを言語側で埋めるのがORマッピングだったりDAOパターンだったり
いやそれは分かったが実際のテーブルはどうするんだよ
親クラスと 子クラスA 子クラスBのテーブル全部別々に
作るの？
ここでいいう親子は継承の親子関係のことで
外部キーでの関連のことではないものとする。
一つのテーブルに全カラム持たせるか差分情報だけのテーブルを連結するか
指定した2点を通る線を描画するプログラムを作ろうと思っています。
・色
・線の太さ
こんなプロパティを持つクラス「DrawLine」を考えています。
さらにこのクラスを継承を用いて
・2点間のみ線を引く線分クラス
・2点を通る直線クラス
・2点のうち片方を始点に持つ半直線クラス
を派生させようかと思っています。
これとは別に描画のインターフェースを担うクラス「LineInterface」を用意しようと思っています
・線を引く
・線を消す
・2点の位置を変更を受け付ける
・色の変更を受け付ける
・線の太さの変更を受け付ける
・線分、直線、半直線の変更を受け付ける
さて、ここで疑問なのですが、インターフェースを担うクラス「LineInterface」は
内部に色や線の太さ、線分・直線・半直線の状態を記憶するbool値型のフラグ
ないしはenum型の値（線分・直線・半直線）を持つべきでしょうか？
最初はこの手のフラグには頼らない設計を心がけてみました。
色、線の太さ、線分・直線・半直線、これらの状態が変更されるたびに
クラス「DrawLine」のインスタンスを作成し直せばいいと思ったからです。
ただすぐに壁にぶち当たりまして、たとえば色を変更しようと思いクラス「DrawLine」の
インスタンスを作り直そうと思ったとき、それが線分クラスなのか半直線クラスなのか
直線クラスなのかは状態を記録しておかないと判断できないことに気付きました。
インターフェースクラスには最低限の内部状態はbool値enum値フラグとして保持しておくべきでしょうか？
その後を頑張って読んだら、言いたい事は既にに書いてあった
ttp://tokyohitori.hatenablog.com/entry/2016/10/01/102830 あのPewDiePieがついに、初心YouTuber向けに「視聴回数」「チャンネル登録者数」を増やすコツを公開！
ttp://naototube.com/2017/08/14/for-new-youtubers/ 27歳で年収8億円 女性ユーチューバー「リリー・シン」の生き方
ttps://headlines.yahoo.co.jp/article?a=20170802-00017174-forbes-bus_all 1年で何十億円も稼ぐ高収入ユーチューバー世界ランキングトップ10
ttps://gigazine.net/news/20151016-highest-paid-youtuber-2015/ おもちゃのレビューで年間12億円！ 今、話題のYouTuberは6歳の男の子
ttps://www.businessinsider.jp/post-108355 彼女はいかにして750万人のファンがいるYouTubeスターとなったのか？
ttps://www.businessinsider.jp/post-242 1億円稼ぐ9歳のYouTuberがすごすぎる……アメリカで話題のEvanTubeHD
ttps://weekly.ascii.jp/elem/000/000/305/305548/ 専業YouTuberがYouTubeでの稼ぎ方具体的に教えます。ネタ切れしない方法は〇〇するだけ。
ttps://www.youtube.com/watch?v=Co9a9fHfReo YouTubeで稼げるジャンルは〇〇動画です。YouTube講座
ttps://www.youtube.com/watch?v=_Nps8xb5czQ class abstract LineBase{
public float width{get; private set;}
public Color color{get; private set;}
public Point start{get; private set;}
public Point end{get; private set;}
// 初期値をセット
public LineBase(引数){}
public LineBase(LineBase instance){}
// 共通メソッドを実装
public void SetWidth(int width){}
public void SetColor(Color col){}
public void SetPoint(Point start, Point end){}
public void Eraser(){}
public virtual void Draw(){} // 仮想メソッド
}
class SegmentLine: LineBase{
public SegmentLine(引数): base(引数){}
public SegmentLine(LineBase instance): base(instance){}
public overrider void Draw(){} // 線分の描画処理を実装
}
class StraightLine: LineBase{
public SegmentLine(引数): base(引数){}
public SegmentLine(LineBase instance): base(instance){}
public overrider void Draw(){} // 直線の描画処理を実装
}
何のクラスかは正直どうでもいい
こんな感じで基底型のインスタンスをコンストラクタに渡してコピーしとけ
// 線分クラスを生成
LineBase segment = new SegmentLine(初期値を渡す);
// 線分のデータで直線クラスを生成
LineBase straight = new StraightLine(segment);
最初線分を描いて、途中で気が変わってやっぱり直線を描きたいな、となったときは
インスタンスsegmentを消去したのち、インスタンスstraightを選択してDraw()を実行する
という理解でよろしいでしょうか？
さらにその状態で色を変えたいときはインスタンスstraightを選んだまま色を変えるということでしょうか？
インスタンスsegmentとインスタンスstraight、いま選んでいるのはどちらか？という情報は
どこかに格納しておくべきでしょうか？
・線の引き方の違いを継承で実装する
・線のデータをフラグで持つ
特にこの二点はオブジェクト指向として筋が良くない
・線の引き方はメソッドで実装
・データはフラグじゃなくオブジェクトで渡す
こっちの方がオススメ
クラス「DrawLine」は単純なDraw()メソッドは廃止して代わりに
DrawStraightLine()…直線を描画するメソッド
DrawSegmentLine()…線分を描画するメソッド
DrawHalfLine()…半直線を描画するメソッド
を実装し、インターフェースからクラス「DrawLine」には
・2点の情報が格納された構造体
・色、線の太さの情報が格納された構造体
を渡す。
という理解でよろしいでしょうか？
ちなみにインターフェース上では線の引き方はフラグ等で格納しておいても構いませんか？
ユーザーがインターフェースに対して
SetSegmentLine()
などの命令を実行したらそれに応じてbool値に記憶させておくというのが常道でしょうか？
前半はそう。継承を使うのはダメじゃないんだけど
継承を使いこなすのは非常に難しいので
慣れるまではメソッドをたくさん生やす方が分かりやすい
後半はフラグとかいらない
そういう発想がまだないんだろうけど
デザインパターン勉強するとよく分かる
オブジェクトの生成と使用を分けて
なるべく値の設定を生成の一回だけで済ますと
フラグの不整合のバグが減ってソフトが安定する
これがオブジェクト指向を使うメリットのひとつ
特にオブジェクトが常に動き回るゲームとかじゃなくて
作図ソフトだったら基本的に一度オブジェクトを作ったら
そのまま静的な図になるから位置は不変データにして
もし位置を修正するときにはオブジェクトを再生成する
なんでそうするかっていうとフラグがバラバラ増えていくと
どこで値を変更したのか不明で後でメンテが困難になってくるから
できる限り生成時に一括で設定するようにするの
こんな感じでどうでしょうか。
インターフェースを担うクラス「LineInterface」から
実際に線を描画するクラス「DrawLine」に向けて
新たに以下のような3番目のクラス「Information」を作成し、このインスタンスを投げようかと思います。
クラス「Information」には2点の位置座標、色、線の太さ、半直線か直線か線分かの情報が格納されています。
Class Information
{
public:
double x1, y1, x2, y2;
int color;
int lineWidth;
bool leftExtendFlag, rightExtendFlag;
};
線を描画するのに必要な情報は全てこのクラスに格納・隠蔽します。
ユーザーから線に関する新たな情報を受け付けたら
ユーザーから線に関する新たな情報を受け付けたら
クラスInformationに用意した専用メソッドを通してメンバ変数にデータがセットされます。
直接メンバ変数を操作するわけではないので（bool型のフラグを直接いじることはない）
安全面でも良いかと
このインスタンスを受け取った「DrawLine」クラスはメンバ変数を直接読み込み（publicで
宣言したのでアクセス可能）、線を描画します。
書き換えはせず、新たなデータを受け取とるたびに「DrawLine」クラスのインスタンスを
新規に作成しようと思います（なのでデータはコンストラクタで受け取るのみ）。
こんな感じでオブジェクト指向になるでしょうか？
細かいこと言うと第三のクラス名はまだしも「LineInfo」とかだろうね
実用ソフトだと「Line」だけじゃなく「Box」とか「Circle」とか増えてくから
細かいとこでキリがないけど
でもそれで組んでみればいいんじゃないの
OOPの要点を一言でいうと疎結合にすることで
ゴチャゴチャするようだったらまた設計を見直していく
> 細かいとこでキリがないけど
> でもそれで組んでみればいいんじゃないの
了解しました、この方向で組んでみます
> OOPの要点を一言でいうと疎結合にすることで
> ゴチャゴチャするようだったらまた設計を見直していく
プログラムに関する本はちまたに溢れかえっているんですが
オブジェクト指向の設計に関する本ってなかなか見かけませんね
学ぶだけでなく説明する方も難しいのかもしれません＞オブジェクト指向
＞オブジェクト指向の設計に関する本
探せばいっぱいあるよ
でも本格的なのはたいてい翻訳書で
分厚くて高くて難しいから読むの大変だとは思う
そうでしたか、本屋さん行って見ます(´･ω･｀)ノ
多分そもそもオブジェクト指向を「学ぶもの」と思っている時点で間違い。
あれは悟るものだ。
おそらくOOPの練習なのだろうけど、そもそも題材も悪い。
オブジェクトの切り方は例えば .NET でも見てみればいいでしょ。
Graphicクラスに全部メソッドが付いている。
ttp://https://msdn.microsoft.com/ja-jp/library/system.drawing.graphics">ttps://msdn.microsoft.com/ja-jp/library/system.drawing.graphics(v=vs.110).aspx というか、線分と半直線と直線を別のオブジェクトにする意味が分からない。
余計使いにくくなるだけだ。何をどう抽象化(共通化)すべきなのか、全く分かってない。
ただな、OOPを「初心者」が理解するのは不可能なんだよ。
心は ： デフォルトの名無しさん [sage] 2018/04/01(日) 23:59:53.19:eiVy9NnE
了解しました
とにかく書いてみます(`･ω･´)
まあ君はやろうとしているだけかなりマシだよ。
やろうとせずに知ろうとだけする奴も多いからね。
そもそも、
・これこれこうで、後はよきにはからえ
と処理を投げられる物をオブジェクトにするべきであって、
逆に、そうでない物をオブジェクトにしても余計に話が混乱するだけ。
「隠蔽」も、初心者はとにかく「隠蔽」しようとするが、これも間違いで、
（外部から使うときに）そもそも見たくも知りたくもない物を「隠蔽」するんだよ。
といっても、やらないと分からないだろうから、まずは頑張れ。
元凶だよな
Javaも再定義してるけど
たとえば、CycはFredという名前の男が朝にひげをそるという話が理解できなかった。
Cycの推論エンジンは、この話の中に矛盾を見つけた。Cycは人間には電気の部品がないことは知っているが、
Fredが電気カミソリを持っていたので、エンティティ「Fredがひげそり中(FredWhileShaving)」
には電気の部品が含まれていると考えた。したがって、CycはFredがひげをそっている間、
Fredはそれでも人間なのかと尋ねた。
『深層学習』
著者:
Ian Goodfellow, イアングッドフェロー,
Yoshua Bengio, ヨシュアベンジオ,
Aaron Courville, アーロンカービル
きっと翻訳が悪いんだな
C++（というかその設計者）はSmalltalk（同）のメッセージングのOOPを
ユーザー定義型（＝抽象データ型）のOOPとして再定義したわけだけど
JavaはOOPの何を再定義したの？
swiftは文法モダンに！でまた“ここで処理投げてます！”が
わからないようにする悪弊組み込まれちゃったし…
(それは退歩なんだってば)
FORTANやPascalと共に滅亡して時代はC++かJAVAの二強になると
堅く信じていた当時からすれば今のObject-Cの人気ぶりには隔世の感がある
swiftの普及の早さを見ればわかるでしょ、みんな嫌々objcを使ってたって
嫌いだけど選択肢が少ないから仕方なく使っているって人も多い
だって実際に
> 嫌われる傾向が強いほかの言語には、「PHP」「Objective-C」
>「CoffeeScript」「Ruby」などが挙がっている。
ttps://builder.japan.zdnet.com/tool/35109803/ > Stack Overflowは、この嫌われている言語ランキングに
> 使用したデータを、求職情報ページの「Developer Story」ページから
> 集めた。Developer Storyは、開発者が自分の職歴や実績などを
> まとめて公開できるサービスだが、このページには使いたい言語と使いたくない言語のタグを追加できるようになっている。
>
> 嫌われる傾向が強いほかの言語には、「PHP」「Objective-C」
>「CoffeeScript」「Ruby」などが挙がっている。
>
> 一方、嫌う人が少ない言語には、「R」「Kotlin」「TypeScript」
>「Rust」「Bash」「Clojure」「Swift」「Python」「JavaScript」「Go」などが並んだ。
ttps://news.mynavi.jp/article/20170330-a133/ > fossBytesに3月28日(米国時間)に掲載された記事「Which Are The Most Loved and Most
> Hated Programming Languages｜2017」が、Stack Overflow Developer Survey 2017の
> 調査結果を引き合いに出し、開発者に愛されているプログラミング言語と嫌われている
> プログラミング言語のトップ25を伝えた。愛されているプログラミング言語1位は
> Rustで、これにSmalltalkとTypescript、Swift、Goが続いている。
>
> 嫌われているプログラミング言語トップ25は次のとおり。
> Visual Basic 6
> VBA
> CoffeeScript
> VB.NET
> Matlab
> Objective-C
> Assembly
> Perl
> Lua
> Hack
略
なんでVBとかVBAが入ってないし
そっちも Java がスルーされてるな
CoffeeScript は悪くないと思うんだけど
D とか Julia は呼ばれてないな
ttps://dotinstall.com/lessons/basic_smalltalk 日本では壊滅的に過疎ってるだけで
現役である証拠を書けばいい
手ぶらの批判は誰でもできる
事実としてPharoの処理系は更新され続けてる
よし、Dは現役だな
クラスに自分のインスタンス造る機能が入ってて
「おまえのコピーをこの名前で作れ」の方が個人的には関与する言語機能が減って好き。
> 事実としてPharoの処理系は更新され続けてる
更新されているからと言って現役ということにはならない
あたりまえのこと言わせんな
> 「おまえのコピーをこの名前で作れ」の方が個人的には関与する言語機能が減って好き。
コピーしかできないのか？
なにもないところから作ることはできないのか？
コピーを作った後に、値を変更してインスタンスを完成させるのか？
> 作った後に、値を変更してインスタンスを完成させるのか？
これってプロトタイプベースだから必要なわけではなく、クラスベースでもコンストラクタで普通にやってる作業だよね？
他の言語の場合は、更新程度なら必要条件にすらならないかもしれないけれど
Smalltalkみたいにドックフードとして食らうことが避けられず
動的かつ可塑性を最大の利点にしている言語・環境に限れば
更新（変化）し提供され続けていることは少なからぬ人に使われている証拠として十分だろうね
動的かつ可塑性を最大の利点にしている言語・環境
意味の説明もさることながら、どこの業界の用語か知りたい
ttps://tabelog.com/kanagawa/A1401/A140106/14031740/ マイクロソフトが社員に勧める“ドッグフード”栄養学
ttps://japan.cnet.com/article/20060067/ 作る人がいることの証明にはなってるが
使う人がいることの証明になってないよ
誰も使って無くても、更新し続けることはできるんだから
Rubyに限らず通常の言語の場合たとえ使う人がゼロでもリリースし続けることは理論的に可能
しかしSmalltalkの場合、Smalltalkを使わずにそれに変化を加えることはできないんだよ
それが正しいとしても
Smalltalk処理系の開発者はその処理系を使い続けている
ってことになるだけで
Smalltalk処理系の開発者以外の人がその処理系を使い続けている
かどうかは分からないよな
他の言語では 処理系開発者＝利用者 には必ずしもならないが
Smalltalkではその特殊性から 処理系開発者＝利用者 がほぼ成り立つ
したがって、Smalltalkは更新されリリースされていれば利用者は必ずいる
上にもあるがこれだけだよ君はいったい何と戦っていて何を証明したいんだ？
「利用者」の定義をしぼればいつかはSmalltalkの利用者はゼロにできるけど
それだと「俺ほどの人間のアンテナにひっかからないSmalltalkは死滅しているも同然」という情弱識者とたいしてかわらんぞ
もし本当にSmalltalkが実務等で使われているか知りたければ sorabito "smalltalk" とかでググるか
ttp://pharo.org/success/ にアクセスして事例を精査してみればいいと思うけど 実際のところSmalltalkがどうあろうが端から興味なんてないんだろ？
プロトタイプベースでもコンストラクタ定義すればいいだけだよな
ttps://pharo.org/ たぶん の ＝ の誤りの指摘だと思うんで念のためお詫びと訂正しておくと、
これは「〜ならば」の間違いなので申し訳ないけど適宜読み替えてほしい
Smalltalkであっても利用者 ＝ 処理系開発者 の関係は必ずしも成り立たない
ついSmalltalkのメッセージ式っぽく考えて交換法則を忘れてしまった^^;
まあ屁理屈をこねればSmalltalkにおける開発とはすなわち言語や環境の拡張に他ならないので
利用者はすべて処理系開発者だとも言えなくもないけどそれはさすがに言い過ぎだろうしここで主張したいことではない
海外だと事例けっこうあるんだけどね
日本だとあんまり使われてない
というのが正しいとしても、処理系開発者以外に利用者がいるとは言えない
やが言ってるのも「処理系開発者以外の利用者」についてだと思う
こだわるね^^;
では処理系開発者をその言語の利用者にカウントしてはいけない合理的な理由を述べてよ
>処理系開発者をその言語の利用者にカウントしてはいけない
誰もそんなことは言っていないわけだが
利用者が処理系の開発者だけの状況を、その言語は現役とか
その言語は普及しているとか言わないだろ
やが言ってるのもたぶんそういうこと
まず君の思う「現役」の定義を明確にしてよ
これまで誰も主張していない「普及」をいきなり持ち出してきたけど、それが答え？
もし一定のシェアをとっていない言語を「現役」と言ってはいけないって法があるなら
今のSmalltalkは誰が見ても明らかに違うだろうこれで満足？
ただシェアこそないがコミュニティはかつてないほど活発だしまして「死滅」からほど遠いのも事実
これをもって「今でも現役」と表現することも決して間違いではないと思うが違うのか？
そもそもの「現役」はを受けての「死滅」なぞしていないという意味でしかない
その文脈を読めてないが自分の考える「現役」と違うってだけの単純な話を
なにをそんなにこだわって執拗につっかかり続けるのかわからん
Smalltalkが今も「現役」を名乗ると個人的になにか不都合でもあるの？
「変態言語！変態言語！！」ってほざいてた頭ゆるいアンチApple老人が
いやあれはねとsmalltalkerが擁護するの見て
『ならsmalltalkも俺の敵だ！』ってやってるだけだからw
912>更新（変化）し提供され続けていることは少なからぬ人に使われている証拠として十分だ
とか言い出すからおかしくなる
処理系が更新されてるから少なからぬ人に使われているのは間違いない、だから現役だって主張だろ
「少なからぬ人に使われている証拠」とかいうのがあるなら最初からそれを出せばいい
処理系が更新されているからと言って現役ということにはならないのだから
なるほど「少なからぬ」を文字通り「普及」や相応のシェアを持っているという主張だと短絡して反発したわけね
これもやはり 「死滅」＝利用者ゼロあるいは数名 に対し「そんな少なくはない」という程度の意味だと思うけど
では何人くらいが使っていれば「現役」を名乗っていいわけ？とにかくそれを明確にしてよ
知らん
俺が言いたいのは
処理系が更新されているからと言って「少なからぬ人に使われている」ことにはならない
「少なからぬ人に使われている証拠」とかいうのがあるなら最初からそれを出せばいい
ってだけだし、やが言ってるのもたぶんそういうこと
改めて訊くけど処理系開発側になったらもう利用者としてカウントされなくなるのはなぜ？
利用者が処理系の気にくわない部分に手を加えてそれが採用されるパターンとかよくあると思うんだけど
それともその程度なら開発側とは考えなくても良いの？その場合の線引きは？
なぜたったこれだけのことを理解できないのだろう
>処理系が更新されているからと言って「少なからぬ人に使われている」ことにはならない
>「少なからぬ人に使われている証拠」とかいうのがあるなら最初からそれを出せばいい
（なお、言語だけじゃなくOSと比較したのはSmalltalkは環境であるってのに敬意を評して）
ttps://trends.google.co.jp/trends/explore?q=Smalltalk,Windows%2095,Windows%203.1,Pharo,D%20Language Smalltalk、もしかしたらWindows 3.1と同じくらいのユーザ数に使われてるかも知れんね。凄いね！
(相手にされない)
「ほらDVDの円盤の販売数を調べたぞ！ほっら売れてないからおまえの負け〜俺の勝ちー！」
(一同失笑)
別のSmalltalkerがそれに普通に乗っかるのもキメェ
> 改めて訊くけど処理系開発側になったらもう利用者としてカウントされなくなるのはなぜ？
「処理系開発側になったらもう利用者としてカウントされなくなる」とは言っていない
話の順番が逆で
先にお前が「処理系開発側を利用者としてカウントする」などと
おかしなことを言ったから、お前の間違い指摘しただけ
ここでお前が言ったことを改めて言い直してみようか？
「利用者数がわからないので、処理系開発者を利用者に含めていいですか？」
良いというわけがなかろう？
www
Pharo Smalltalkの利用者は数千人くらいはいる
Haskellのだいたい半分くらい
Smalltalk利用者の規模はHaskellのおおよそ半分というのは別の解析でも同じ
ttp://www.dataists.com/2010/12/ranking-the-popularity-of-programming-langauges/ Smalltalkは約20位でHaskellが約40位だけど、これはSmalltalkとHaskellの間に他の言語が20個あるという意味でしかない
そのリンクの下方にrawdataがあるけど（
ttp://www.dataists.com/wp-content/uploads/2010/12/language_ranks1.csv）、 この中で絶対値はtagcountだけで、それだとsmalltalkが189に対しHaskellが1896で10倍の差がある
比較する資格すら持たない連中がシェアなるもので一喜一憂するのは何で？
こちらもくしくもてGlasgow Haskell Compilerの36名に対しPharo Smalltalkの16名と約半分だった
ttps://github.com/ghc/ghc/pulse/monthly ttps://github.com/pharo-project/pharo/pulse/monthly ttps://github.com/dlang/dmd/pulse/monthly "sorabito smalltalk" でググったら、
ベンチャーで最初にいたエンジニアがsmalltalkerでsmalltalkを採用したとか、
そのエンジニア（元CTO）は去年12月に辞めたとか、
いまの採用ページにはsmalltalkに一言も触れてないとか、
色々あったんだろうなって想像できて面白かったわ。ありがとうw
長年議論されてきてることだけど、中には
「privateで変数やメソッドを宣言するくらいならその部分をクラスにまとめて外に追い出してしまえばいい」
「洗練されたプログラムは変数・メソッドともにpublicだけで十分」
という意見もあるんだけどこれってどう思う？
洗練されて無くてもpublicだけで十分といえるので
「洗練されたプログラムである」という判断が別に必要になる
選択肢が無くなったり少なくなったりすると利用し難くなる事も有るし
使う人のレベルや理解度もまちまちなんだから
staticだらけでやる人がいても構わないし
どちらか一方になって片方が使えなくなる方がやだな
洗練されているかどうかは悦に浸っている人が勝手に浸かっていればいいし
