-OOP限定-プログラム設計相談室
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2005/09/24(土) 16:35:590302デフォルトの名無しさん
2008/12/06(土) 06:03:41うざったいってのはよく分かる。
IService ← テンプレート・メソッド パターン
↑
AbstractLogic ← テンプレート・メソッド パターン
↑
DomainLogic
としてBaseCollectとやらはコンポジションでもっとけと。
0303デフォルトの名無しさん
2008/12/06(土) 09:36:210304デフォルトの名無しさん
2008/12/06(土) 19:23:37クライアントは、
DomainLogic dl = new DomainLogic();
dl.Run();
あれ？スーパークラス使わないの？
IService はどうした？
IService は？
カスが
0305デフォルトの名無しさん
2008/12/06(土) 19:26:080306デフォルトの名無しさん
2008/12/06(土) 19:33:020307デフォルトの名無しさん
2008/12/06(土) 19:36:490308デフォルトの名無しさん
2008/12/06(土) 19:48:280309デフォルトの名無しさん
2009/01/25(日) 05:15:15> 全部publicでいいじゃん！ってならないようにするスレです。
あーあorz
プログラミングまだまだ初心者で、C#勉強している途中だけど、
このスレ開いて、>>1を読んでしまった・・・。忘れようとしても忘れられない。
意識しないようにすると意識してします。
将来プログラマになった際、仕事中「全部publicでいいじゃん」というレスが頭に思い浮かんで、
忘れよう忘れようとしても逆に頭にこびりついて、何かとんでもないミスをして入社早々首になりそう・・・。
逆に、記憶に逆らって、全部privateにしなきゃと意識するとコーディングが全然遅々として進まなかったり。
スレ開かなきゃ良かった・・・。
0310デフォルトの名無しさん
2009/01/25(日) 06:31:570311デフォルトの名無しさん
2009/01/25(日) 13:12:030312デフォルトの名無しさん
2009/01/25(日) 13:16:53メンバ関数はpublicが基本
0313デフォルトの名無しさん
2009/01/26(月) 19:49:32そんな性格の人はこの職業向いてないよ。
このスレのおかげで早めに気づいてよかったね。
0314デフォルトの名無しさん
2009/01/26(月) 22:33:060315デフォルトの名無しさん
2009/01/27(火) 01:07:170316デフォルトの名無しさん
2009/01/27(火) 01:54:170317デフォルトの名無しさん
2009/01/27(火) 01:57:43こんなOOPで当たり前の常識をすぐ理解できない時点で向いてない
0318デフォルトの名無しさん
2009/01/27(火) 12:47:27OOPで当たり前の常識を理解できていないとな
0319デフォルトの名無しさん
2009/01/27(火) 19:08:50その時どうしてんだ？
friendにすぐにするのか。一瞬くらいは正しかったのか？って考えるだろう
0320デフォルトの名無しさん
2009/01/27(火) 23:36:38publicかprivateで十分
早くpublic(in hoge::piyo, child)とか修飾できるようにならないかなー
0321デフォルトの名無しさん
2009/01/30(金) 16:31:51クラスライブラリなら考えると思う。
実務の仕様変更で必要となったのならなにも憂慮することなく
すぐfriendにする。
最近C++やってないなあ。
Javaの同じパッケージのクラスからだけ呼べるデフォルトスコープは
わかりにくいよね。修飾子で明示的にして欲しい。
0322デフォルトの名無しさん
2009/02/27(金) 01:47:05迷うとinterface（規格）→abstract（ひな形）→具体クラスってのが多い。
0323デフォルトの名無しさん
2009/03/15(日) 01:29:180324デフォルトの名無しさん
2009/04/08(水) 03:15:330325デフォルトの名無しさん
2009/04/08(水) 08:05:11インタフェース指向設計にも載ってるやり方だけど、
結局、Java系OOPLの現状の中での最適解って感じで
果たしてそうあるべきものかと問われると
はなはだ疑問に感じる部分だよなぁ。
0326デフォルトの名無しさん
2009/05/11(月) 23:31:23今考えてるもので、なんか結局相互依存しちゃうクラス関係orz。
今考えてるのは、ネットワークプログラミングで、
コネクションを表すclass Connectionがあって、これをベースに
class ServerConnection, class ClientConnectionがある。
で、こいつらを一つにまとめておくコンテナで、
class ConnectionManager;
というものを作った。
最初に、
ConnectionManager ConnMgmt;
ServerConnection SConn( ConnMgmt );
とかやって、
//コンストラクタで自分を登録
ServerConnection::ServerConnection( ConnMgmt ){ ConnMgmt.Add( this ); }
void ServerConnection::Accept(){
//ここで、サーバーソケットに接続してきたクライアント用のインスタンスを生成
ClientConnection *CConn = new ClientConnection( Socket_.Accept() );
//で、このクライアントコネクションをコネクションマネージャに登録するのに、
ConnMgmt_.Add( CConn );
}
みたいな、ConnectionManager <-> Connectionで相互依存っぽい気がする。
何か解決方法はないっすかね？
0327デフォルトの名無しさん
2009/05/12(火) 06:19:46徹夜明けでjavaerの俺からすると
とりあえず
・ServerConnectionはそもそもConnectionなのか
・ServerConnectionの作成はServerConnectionFactoryにしたほうがよさそう
あとManagerなのになぜにMgmtなのか不思議
0328326
2009/05/12(火) 20:53:27聞きたいのはそこじゃないw
0329デフォルトの名無しさん
2009/05/13(水) 02:21:49ServerSocketとClientConnectionはManagerを知らなくていいんじゃね？
利用側のクラスをConnectionEventListenerの派生にして
ServerSocket.AddListener(this);
EventLisner#doEvent()の中でMgmt.Add(ClientConnection);
Managerはシングルトン
0330デフォルトの名無しさん
2009/05/20(水) 00:32:18表示機クラスとして抽象化するとして、表示関数のインターフェイスについて質問があります
実際に使用する表示機は
7ｾｸﾞLEDなら1行4文字
LCDならサイズによって異なりますがY行X文字
これを踏まえると
void myPrintf(int X , int Y , const char str);
という形にして1行しか表示できないユニットに関してはYを無視する形にすればいいのかなと考えます。
しかし、今後カラーLCDを使用したり反転・点滅等のエフェクトを追加しようとすると
void myPrintf(int X , int Y , const char str , int color , int effect);
と、7ｾｸﾞLEDのような単純な表示機では使わないような引数がどんどん増えていってしまいます。
しかもインターフェイスに変更を加えることになってしまうのであまり宜しくないようにも思います。
こういう場合どういう風に設計すれば良いのか、今後の変更に備えるための工夫等はどうしたらよいでしょうか？
0331デフォルトの名無しさん
2009/05/20(水) 12:16:58java:
// 表示機
// L: "1行4文字"や"Y行X文字"といった機器ごとの表示位置の表現
abstract class Display<L extends Location> {
public abstract void print(L location, char ch);
}
// 表示位置の表現(ただのmarker interface)
interface Location { }
// 7セグLED表示機
final class LED7Segment extends Display<Location7Segment> {
public void print(Location7Segment location, ch) { location.getX()とgetY()をつかってchを表示 }
}
final class Location7Segment implements Location {
public Location7Segment(int x, int y) {...}
public void getX() {...}
public void getY() {...}
}
// LCD->にたよーなもの．
Locationは"表示の形式"ということで，もし，Windowsのウィンドウに表示するような場合などはFormatみたいな形でまとめるのもいいかも
0332デフォルトの名無しさん
2009/05/20(水) 12:30:500333デフォルトの名無しさん
2009/05/20(水) 13:01:06ああ，エフェクト追加のために今後のことを考えて設計か
「エフェクト」ってのがどういう性質なのか決めないと何も始まらないので，
そっからはじめたら？
0334デフォルトの名無しさん
2009/05/20(水) 17:07:45>>331なんておそらく難しいことはしてないと思うのだが
じゃあ、テンプレートはどういうときに使えるのか、どう実装するのか？っていわれたら自分なら全力で逃げたい
0335デフォルトの名無しさん
2009/05/22(金) 11:46:25P→V+C
C→M+α
A→データ層？
と言うように見えるけどPACのCに相当する部分がMVCのMに専念出来ないような
+αの分、不必要な作業が肥大化していきそうに思えるのは気のせいだろうか？
0336デフォルトの名無しさん
2009/05/22(金) 13:18:51まさかもう俺の考え付くソフトウェア構築モデルがあるとはしたなかった
ありがとん
0337デフォルトの名無しさん
2009/05/22(金) 13:42:33よくModelとViewの関係で例えられるけど
subjectからobserverにメッセージを送るシステムの骨組みだけ提供するから
あとはそれを継承してModelとViewで好き勝手やってくれってこと？
0338デフォルトの名無しさん
2009/05/22(金) 21:03:48レベルが違う話をごっちゃにしたらダメ
0339デフォルトの名無しさん
2009/05/22(金) 21:14:27管理責任はManagerにあるんだから、
Managerにジェネレータやファクトリーの機能を持たせればOKだと思われ。
0340デフォルトの名無しさん
2009/05/23(土) 01:14:21PACなんて10年前からあんだろ
RADツールで作成するときとか既成のボタンとか流用するから
VとCは不可分じゃね？それにMVCのMは大ざっぱ過ぎね？
機能毎にグループ分けしてグループ間の行き来はレイヤーわけようぜ
って感じじゃなかったかな。
Web開発ならVとCはキレイに分けられるし、今はMVCつっても
サービス層、Dao層とかわかれてるしグループ分けならnamespace
(Javaならpackage)で行ってるし、PACがMVCの次の世代っていう
考え方は今は当てはまらないと思うよ。
0341デフォルトの名無しさん
2009/05/23(土) 02:23:25１０年前は開発なんてしてなかった
0342デフォルトの名無しさん
2009/05/24(日) 02:14:28ロジック層との融合不可能な環境がでかくなった時代背景に
注目されたモデルだからね。
Delphi位に柔軟性があるRAD環境ではそれほどレイヤ間の分離を
意識しなくてよかったのはあるやね。
UIの強化、DB項目の追加、機能追加等に備えて無意識にPAC(って言うの?)的な
分けはやっていた人達も少なくはなかったけど。
VBだと何故か殆ど全部不可分だったけどw
0343デフォルトの名無しさん
2009/05/25(月) 02:14:10VB/Delphiのフォームにポトペタのコンポーネント思考には会わなかったけど
WebではしっくりくるからWebサービスの発達と共に浸透したんだよ。
まあ確かにそれまではUIとロジック一緒にしても保守できる程度の規模の
システムでしかなかったという見方は出来るけど。
Delphiが強力ったって、Delphiから入って仕事覚えた人はあんまりVBerと
変わらないっていう印象だなあ。フォームにポトペタで設計なんか考えない感じ。
クラス派生時に可視性を下げることしかできないっていうルールが
多態性とか検討するのを阻害するしね。Delphiの場合はTAbstractButtonみたいな
ベースで考え得る機能をできるだけ網羅して、具象化するときに機能制限して使う。
コンポーネントのひな形を全部Delphi側で用意して開発者は利用するだけという考えなら
確かにクラス数が少なくていいけど、柔軟性にかけるよね。
あーなんか言葉足らずでうまく伝わらない気がするな。ちゃんと書くと長いからいいや。
0344デフォルトの名無しさん
2009/06/04(木) 22:55:00GUIのためのMVCと、WebのMVCは全然別ものだよ。
一緒なのは名前だけ。
名言集 その４
『俺、100人規模の集団サイバーテロの主犯だったこともあるんだぜ』
http://yutori7.2ch.net/test/read.cgi/news4vip/1249830540/ のID:PVAf+dux0 ＝ 自動焼人 ★
> 965 ：以下、名無しにかわりましてVIPがお送りします [sage] ：2009/08/10(月) 00:02:09.35 ID:PVAf+dux0
> まぁ何だ。
> 俺の過去の経歴に比べたら、割れ厨なんて鼻くそレベルなんだけどなｗ
> 100人規模の集団サイバーテロの主犯とか、いろいろとな。
----------------------------------------------
この自動焼人 ★メールマガジンの配信停止をご希望される方は
http://qb5.2ch.net/test/read.cgi/sec2chd/1250169591/
にて自動焼人 ★までご連絡ください
0346デフォルトの名無しさん
2009/08/17(月) 20:31:450347デフォルトの名無しさん
2010/03/05(金) 10:13:16EntryとEntryManagerという二つのクラスがあって、
EntryManagerが、複数存在するEntryインスタンスを生成、管理してます。
Entryが、他のEntryにアクセスできるようにしたいのですが、
そうなると、EntryManager<->Entryというお互いに依存関係ができてしまうと思います。
これは悪い設計でしょうか？
また、このような場合のためのデザインパターンなどはありますか？
0348デフォルトの名無しさん
2010/03/05(金) 10:25:56このような場合にインスタンスが、他の兄弟インスタンスや型を知るような依存はしたくない。
多数あるインスタンスが、多対多の関係になることは避けたい。
> そうなると、EntryManager<->Entryというお互いに依存関係ができてしまうと思います。
GoFのMediatorパターンでは、相互作用はMediatorに記述され、
ColleagueはMediatorとだけやり取りして、他のColleagueへは直接関与しない。
少なくとも一対多の関係にしておくことができる。
0349デフォルトの名無しさん
2010/04/12(月) 05:36:42経験というかバックグラウンドがちゃんとあるひとなら伝わるけど
馬鹿に伝えるのは難しいよね
0350デフォルトの名無しさん
2010/04/12(月) 16:07:490351デフォルトの名無しさん
2010/04/29(木) 21:41:13http://apr.2chan.net/jun/b/src/1272544702094.jpg
画像にあるUML図のように
AとB
どちらでプログラムを組むのがいいのでしょうか？
利点などあったら提示してくれると助かります
0352デフォルトの名無しさん
2010/04/30(金) 00:25:140353デフォルトの名無しさん
2010/04/30(金) 02:56:560354351
2010/04/30(金) 18:37:48AはMFCを参考に
Bはjavaを参考に考えました
Webサイトの解析と、それを元に一定の処理を行うというものです
作っている段階でバージョンアップ（修正）もでてくると予想してます
0355デフォルトの名無しさん
2010/04/30(金) 22:44:52継承しているのは不自然に感じるけど、MFCにそんな構造あったっけ？
もしかして、継承と関連の記号を取り違えていないか？
0356デフォルトの名無しさん
2010/05/01(土) 11:33:10「構造体に毛のはえた設計」と言ってました
Cマガは現在廃刊になってます
0357デフォルトの名無しさん
2010/05/04(火) 15:50:23DBーサーバーークライアントー表示
こういうのをクラス図として提出されてどうしようかと悩んだ
私の説明が端折り過ぎたのが原因だろうがこれはあんまりだ
0358デフォルトの名無しさん
2010/05/04(火) 18:04:52べつに いいん・・・
よくねーよｗ
0359デフォルトの名無しさん
2010/05/04(火) 19:48:070360デフォルトの名無しさん
2010/05/08(土) 15:21:19オレは最初データベースと読んでいたが、
なんとアニメの欄にＤＢの文字が・・・
まさかデータベースのアニメ（！キバヤシ風）
と思ってクリックしたらドラゴンボールだよ！
0361デフォルトの名無しさん
2010/05/08(土) 16:29:010362デフォルトの名無しさん
2010/05/23(日) 04:06:32野球ってbatファイル
ピッチャーが開始するまで誰も動かないor動けない
んで、みんなピッチャーに依存してる
ヒットも守備の重箱の隅をつつくようなところに打たないとでない
でオブジェクト指向はサッカー
監督がこういうふうに試合をしてくれって指示だけだし
あとはオブジェクトがメッセージ（ボール）をつないで試合を展開する感じ
0363デフォルトの名無しさん
2010/05/23(日) 05:54:51その辺にしておかないと大変なことになってる
0364デフォルトの名無しさん
2010/05/23(日) 06:19:180365デフォルトの名無しさん
2010/06/03(木) 17:35:34ぁぅあんっぅあああああーーーーーーーーーー
かい～いぃぃいいい～～～さああああん
0366デフォルトの名無しさん
2010/06/03(木) 23:24:58もう…おかしいでしょ。どう考えても何をねつ造しても事実はこうなのですから
↓
http://www.nicovideo.jp/watch/sm10915996
キラー小里議員、赤松広隆君不信任決議案で爆弾発言！
平成22年5月31日衆議院本会議農林水産大臣赤松広隆君不信任決議案（174国会決9賛成の討論で壇上に上がった小里泰弘議員から、爆弾発言！マスコミは一切伝えてません。
http://www.nicovideo.jp/watch/sm10815799
“独裁者”小沢一郎とフジテレビ「黒い密約」疑惑を追求②＊拡散希望
0367デフォルトの名無しさん
2010/06/12(土) 19:21:140368デフォルトの名無しさん
2010/06/12(土) 19:52:160369デフォルトの名無しさん
2010/06/12(土) 21:22:47おい！
0370デフォルトの名無しさん
2010/09/05(日) 13:57:480371デフォルトの名無しさん
2010/09/28(火) 13:24:460372デフォルトの名無しさん
2010/09/28(火) 13:32:36場当たり的に逃げ道を探して回避する(根本的な問題は完治しない)のがバッドノウハウ
本質的な部分を見直して考慮された見通しの良い(とされている)考え方がデザパタ
0373デフォルトの名無しさん
2010/09/29(水) 02:57:51なるほど
ところでデザパタに対して含みを持たせてるのは、
本質的に解決できていないものも含まれていると感じているから？
だとすると、問題を解決する方法として見たとき、バットノウハウとデザパタの境界は
案外曖昧だったりするのでしょうか
違う側面からの解説もｷﾎﾞﾝﾇ
0374デフォルトの名無しさん
2010/09/29(水) 03:07:380375デフォルトの名無しさん
2010/09/29(水) 06:20:55それが急を要しない状況で使われたとき「バッドノウハウ」と呼ばれる気がする。
0376デフォルトの名無しさん
2010/09/29(水) 07:12:030377デフォルトの名無しさん
2010/09/29(水) 08:11:02スクリプト書いて対処したりとか、プログラムの美しさを損なうやつ。
0378デフォルトの名無しさん
2010/09/29(水) 08:41:110379デフォルトの名無しさん
2010/09/29(水) 13:58:19WEBプログラムのクライアントサイドこそバッドノウハウの宝庫だな。
あとはJavaのVMごとにあるバグの回避で実装変えたりとかな。
0380デフォルトの名無しさん
2010/09/29(水) 14:24:03>JavaのVMごとにあるバグの回避で実装変えたり
したことないなあ。どんなのあった？JVMにバグがある場合は
アップデートで乗り切ってるなウチは。tomcatのHttpSession#getSessionId()で
バージョンによってセッション切れの時の挙動が違って回避プログラム書いたけど
まさにバッドノウハウだよね。OOとも何の関係もない
0381デフォルトの名無しさん
2010/09/29(水) 14:39:42でも8年くらい前の話だ。
0382デフォルトの名無しさん
2010/10/10(日) 00:44:37例えば運動方程式を解いて物体の運動を視覚的に表示するプログラムを考えます。
DirectXやOpenGLのようなものは使わず、普通のウィンドウシステムの上で動かすとします。
このとき、フレームレートとか画面の大きさというような情報は誰が持つべきなのでしょうか？
Mがフレームレートの情報を持って、自分からイベントループにコールバックを登録する構造なら、
物体が自律的に運動するさまを自然に表現できますが、
反面、Mがウィンドウシステムに依存することになり、何か変な感じもします。
逆にこれをCが持つとすれば、Mは位置と運動量と時刻くらいしか持たないことになり、
ちょっとMの仕事が少なすぎる気がします。
画面の大きさに関しては、常識的にはVの領分でしょうが、現在の位置に加えて軌跡も表示したい場合、
どこかに画面と同じ大きさのビットマップを持つ必要が出てきます。これはMにあたるでしょう。
0383デフォルトの名無しさん
2010/10/10(日) 20:10:55つか、ビットマップはVだろ…
いや軌跡をビットマップにプロットするモデルと、ビットマップを表示するビューに分ける、
とか考えられなくもないけど、そこまでするほどの例題とも思えない。
0384デフォルトの名無しさん
2010/10/10(日) 23:48:35Ｍに持たせるインターフェイスのデザインをどうするか、どんなものが好ましいのかにもよりますが、
VCペアが問い合わせてくる、ある時刻での物体の正確な位置を返す仕事であれば、Ｍの責務です。
0385デフォルトの名無しさん
2010/10/11(月) 00:08:48モデル側にあるってことは、交換可能な全てのモデルに位置を画像で返す機能をつけることになるが…。
数値だけ返して、画像への描画は別の部分が担当するのではまずいの？
0386デフォルトの名無しさん
2010/10/11(月) 00:32:40ウィンドウサイズなどの情報を抽象化するMを設ける
0387デフォルトの名無しさん
2010/10/11(月) 02:16:400388デフォルトの名無しさん
2010/10/11(月) 10:22:43Model(M)からは、軌跡の集まりを返すだけにし、その表現はPresentation Model(PM)から返すようにするってのは？
V <-- PM <-- M
PMが不要なプロパティを表示する時は、単に無視するか、透過的に扱うようにする。
0389382
2010/10/12(火) 21:36:29軌跡が初等関数で書けるようなものであれば係数を求めて渡すだけですが、
そうでない場合、まさか全ての時刻での座標を覚えておくわけにもいきませんから、
ビットマップを埋めることで軌跡を「求める」ことになるでしょう。
もっと極端な例では、マンデルブロ集合のモデルは必然的に解像度の情報を持つことになります。
0390デフォルトの名無しさん
2010/10/12(火) 21:38:480391デフォルトの名無しさん
2010/10/13(水) 00:57:24> まさか全ての時刻での座標を覚えておくわけにもいきませんから、
むしろ、保持しておいた方がいいと思うけどね。
オンメモりに乗らないくらいの巨大データなら、ファイルなり、DBなりに保存（キャッシュ）する。
または、間引いて保持する。
また、適当な間隔で間引かれたサンプリングデータをもとに、
オンデマンドで表示領域分のデータを計算すれば、全領域を保持する必要はなくなると思うよ。
この辺は、OOPとは関係ない実装の泥臭い部分になるけど。
0392デフォルトの名無しさん
2010/10/13(水) 10:06:32ビットマップの方がメモり喰うのわかってないの？
MVCのVがモニタだろうがプリンタだろうがMは影響を受けないように作るべきで、
どんなサイズでどういう風に表示するかはVが決める。表示内容はMだけど
見た目はVが決める。ビットマップで持ったらVで見た目決められないし
0393デフォルトの名無しさん
2010/10/13(水) 19:39:58全ての座標とは、軌跡上の全ての座標を保持するという意味で書いたんだ。
軌跡以外の点までは保持する必要はないってことね。
例えば、放物線なら、放物線上の点の集まりのみを保持する。
うまく伝えられなくてゴメンね。
0394デフォルトの名無しさん
2010/10/13(水) 19:50:14座標とは、UI上の座標ではなく、ある時刻の計算値のことね。
運動方程式なら、パラメーターを設定すれば、(時刻, X, Y, Z)の集合が計算できるので、その値を保持。
表示する際は、範囲と倍率を考慮して、UI座標に座標変換する。
0395デフォルトの名無しさん
2010/10/14(木) 07:37:500396デフォルトの名無しさん
2010/10/14(木) 11:17:130397デフォルトの名無しさん
2010/10/14(木) 23:04:15最終的に1034x768のbmpに納めればいい情報ならshortのx,yの2点でいいし、
bmpで持つくらいなら1024x768のbooleanの配列で持った方がまだマシ。
同じだけの情報記録できてサイズが小さくてデータが利用しやすいから。
Viewの実装がなんだろうとModelのビジネスロジックは変わらない、
それがMVC。Mの時点で最終表示系を決めたらVの仕事はなんだよｗ
0398デフォルトの名無しさん
2010/10/14(木) 23:11:25扱いが面倒で記憶域の無駄遣い
0399デフォルトの名無しさん
2010/10/15(金) 13:40:38おまえは何を言っているんだ？ｗ
0400デフォルトの名無しさん
2010/10/15(金) 20:28:50要求がはっきりしないけど、例えば同じ座標を通った回数を区別する必要がある場合はどうする?
その必要がないとしても、boolean使ったからってそれほど節約にはならないよ。1バイトなんだから。
そもそも、軌跡を描画するなら普通に考えてビットマップに描いていくのが効率がいいので
内部で二重にバッファ持つ意味がない
0401デフォルトの名無しさん
2010/10/15(金) 20:59:43UＩで、スケール変更して、拡大表示するときは、どうするの？
ビットマップから切り出して、拡大表示させる？
ジャギーでるよ。
その都度、再計算させる？
再計算のコストが高かったら？
レスポンス悪くなるよ。
軌跡の計算結果をもつことは、メモリ効率を悪くしてるかもしれないけど、
最悪、拡大時は補間してレスポンスの悪化を防ぐことも一応可能よ。
ビットマップもジャギー出さずに、補間して拡大するアルゴリズムあるのかな？
■ このスレッドは過去ログ倉庫に格納されています