アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
javaでイイと思う (スコア:0)
javaが無難だと思う。
javaだとフレームワークやらEJBなんか使ってれば、
大規模システムでも、実際にコーディングする部分はそれほど
多くないけど、phpなんかだと、基本的な機能まで一から作って
いくって感じで工数がかかると思うし、一から作ってくから
当然バグが多く出るだろうし。
この問題はコーディングが綺麗か汚いかとは別問題だからコーディング規約はあまり関係ないと思う。
Re:javaでイイと思う (スコア:1)
EJBにすれば人件費が浮くとか、後戻り作業がなくなるとか、ありもしない幻想を本気で信じてる人がいる。そういう人って、なぜかコンピュータに詳しい人に多い。
素人より中途半端な知識の持ち合わせた人のほうが騙しやすいということなんだろう。
Re:javaでイイと思う (スコア:1)
Sun ONE ASとPostgreSQLでは、JDBCドライバが合わなかったようで使えなかったです。
ここが解決すれば、使いたいのですが。
使えたらうれしい人ってどれくらいいるものでしょう。
okome
Re:javaでイイと思う (スコア:1)
>javaが無難だと思う。
質問。
Javaって「設計から落としやすい」ですか？
というか、そうだとしたら、それは何故？
ふつーのOOP言語なら、「設計からの落とし易さ」はどれも同じようなもんだと思うが。
ちなみにUMLとJavaの相性は、(巷で言われてるのと反して)全然良くないっすね。
だいたい、オブジェクト間の「参照」とUMLのクラス図の「関連」みたいな
基礎的な部分からして、考え方が全然違うじゃん。
＃これは他の言語も似たようなものだが。
まあRubyで特異メソッド使いまくったら尚更UMLで描きにくくなる、とかいう面はあるが、
それ言ったらJavaだって無名クラス使いまくればUMLで手におえなくなるわけだし。
Re:javaでイイと思う (スコア:0)
>みたいな 基礎的な部分からして、考え方が全然違うじゃん。
そりゃ当たりまえですよ。UML はモデリング言語であって実装言語では
ないんですから。実装レベルの概念でしかモデル化できないんだったら最初から実装言語で書いた方がましです。
業務分析の段階では、オブジェクト間の整合性を
Re:javaでイイと思う (スコア:1)
>実装レベルの概念でしかモデル化できないんだったら最初から実装言語で書いた方がましです。
「モデリング」にも色々あるはずなのにも関わらず、
UMLはそのうちの1つ(?)の方法しか提供してないのが、痛いんだと思います。
それこそOOPはモデリングから実装までの概念の地続きっぷりが売りなのですから、
たとえば、ふつーのプログラム言語と同じ意味の「参照」が
UMLみたいなモデリング言語の「関連」を表すための概念として採用されても、よかったはず。
だって、あの「参照」って、プログラムの中でしか通用しないような変てこりんな概念では、ないでしょ？
＃UMLの関連に正にソックリな概念がそのまま実行時環境に実装されてるシステムってのを見たことが有ります。
＃この言語(?)と同じ概念で巷の多くの言語が実装されてるんだったら、違和感もなにも無かったんですが、ねえ…
逆に、モデリングと実装の乖離を甘受(笑)したとすると、
今度は多くのUML描きツール製品が「嘘つき」だということになります。
実装言語とUML図との往復なんて、定義できるはずがないのに、
そういう機能がしばしば売りになってますので。
＃そうそう。Roseで、関連の集約を「◆--」にするか「◇--」にするかの切り替えが
＃「By Value」「By Reference」というC++的な区別で表現されてますね。
＃これなんかモデリングの差を「唯一の」実装概念の差にマップしちゃった
＃という大間違いの例ですね。無茶苦茶やん。
あと、UMLに搭載されてる関連以外の概念も、結構扱いが無茶苦茶です。
たとえば「クラス」って何？とか。
多くのプログラム言語の「クラス」と同じ程度に低能なもの
(多重分類も動的分類も出来ない)を意味してるならば、
クラスの隣(?)にある「関連」という概念の抽象度の高さ[*]と噛み合わないし、
もっと抽象的[*]なもの(例えば多重/動的分類も出来る)として定義されてるなら、
動的分類をクラス(図)がサポートしてないのが変。
＃[*] 注：
＃あれを抽象度と呼ぶのには違和感を感じますが…
＃「抽象度が高い」のと「普通のプログラム言語がサポートしてない」のとは、イコールではないです。
＃例えば、言語の「参照」がああいう姿として実現されているのは、なにも
＃「抽象度を下げようとして(というか、下げざるを得ないから)」ああした、というわけではないでしょう…
UMLって細かく見ればツッコミ所満載です。
それこそ実装寄りなのか抽象度高くしようとしてるのかがワケワカ。
-----------
「オブジェクト指向」は幸か不幸か、色々な流儀が存在します。流儀に基づいて作られた言語の数も、それくらい(or以上)有る。
で、どっちかってーとUMLは、それらの中に混じって、また1つの新しい流儀が登場しただけ、という風に見えます。
つまりあれも言語でしかないんです。困ったことに、実装言語から見て「メタ言語」とか「抽象言語」とか呼べるほどに
上の世界にイっちゃったりは、していない。イっちゃってるものこそが求められているはずなのにです。
1つの概念セットを提示しただけであって、それはJavaともRubyとも(その他恐らく殆どどの言語とも)似てないし、
それらのスーパーセットでも抽象セットでもメタセットでもない。
両者の間は、人間が高度な(^^;思考を介在させてやっと「翻訳」出来るというだけです。
そのため、我々はUMLを使う(そして後で実装言語に落とす)ときに、相も変わらず「インピーダンスミスマッチ」に悩まされます。
それを無くすのが目標だったはずなのに、UMLはわざわざ新たにミスマッチを1つ増やしてしまった(だけ)…
まあ、いい加減な絵をいい加減に読み書きするためだけなら、あれでも多少は役立ちますが、
妙な売り込みかたの成果のせいか(笑)、世の中は必ずしもUMLに「いい加減」な使われ方だけを求めない。
困ったもんです。
＃というわけで、気軽にちょいと、かつ「正式なやり方にしばしば違反しつつ」描く場合には、
＃UMLは重宝してます。
＃ただしその場合、今度は困るのは、UMLを描くツールが大抵「軽便」ではないという点。
＃ささっと図を描けないんす。
＃ideogramic UML [ideogramic.com]ならOKかどうかはまだ試していませんが。
>コーディングに移ってはいけません。設計段階でコラボレーション図か
>シーケンス図を起こして「参照」とか「メッセージ呼び出し」のような
>実装可能な概念の組み合わせに落し込んでやることが必要です。
好意的に言ってもそれは「現状のUMLとの付き合い方」ですね。
で、わざわざ付き合う必要が、
Re:javaでイイと思う (スコア:0)
ツール屋の金儲けのネタであって、付き合うだけ時間のムダ
だと思います。コミュニケーションツールであると割り切って、
VISIOで描いた図で済ませる程度の付き合いが、UML との
適切な距離の取り方でしょう。極論を言えば、UMLが最大の
実力を発揮するのはホワイトボードの上でしょう。
「参照」という概念はプログラム外でも見られますが、
「関連」という曖昧な概念をすべて置き換えるには全く
不十分です (だって両端に自然言語で「ロール名」が
書けて、「承認する」みたいな曖昧な表記でとりあえずは
済ませられるんですよ
Re:javaでイイと思う (スコア:1)
>ツール屋の金儲けのネタであって、付き合うだけ時間のムダ
あはは。それもそうですね。
ただ問題は、金儲けネタのつまらんものが
UML(のツール)のうち変換自動化機能「だけ」なのか？という疑問です。
>極論を言えば、UMLが最大の
>実力を発揮するのはホワイトボードの上でしょう。
たしかにRoseに数十万円(かける人数分!!)を払うのはアホらしいものを感じてます。
＃MSWordでDocumentを統一するだけでもゲイツ税がアホらしいのに、
＃遥かに高いツールを制式Documentとして採用しちゃうと、Rational税が更に悲惨…
問題は「コミュニケーションツール」という位置付けが何なのか？なんだろうな。
UMLという言語をカタコトでも話して、まあそれなりの意思疎通を図れればよし、
という程度の期待しかしないならば、前述したようにそれはそれなんですが、
UMLの定義を厳格に真に受けると、UML自体の仕様の不備(表現力の不足や蛇足)やツールの不備に
延々と付き合わされて、生産性が低いったら…
さて本題。
>「参照」という概念はプログラム外でも見られますが、
>「関連」という曖昧な概念をすべて置き換えるには全く
>不十分です
ん？なんで置き換えないとならんのでしょう？
(あの)参照と(あの)関連って、抽象度だのなんだのにおいて、
そんなに違う位置に位置していないと思います。
>(だって両端に自然言語で「ロール名」が
>書けて、「承認する」みたいな曖昧な表記でとりあえずは
>済ませられるんですよ?!)。
なにか驚くに値しますか？
そういう実装言語を作りゃいいじゃないですか。
＃てゆーか有るし。
つまり、所詮は「関連」だって実装言語にそのまま落とせる概念なんです。
逆にいえば、UMLみたいな位置付けの言語が「参照」を採用しても
べつに悪くなかっただろうなとは思います。
だって「参照」と「関連」の違いって、単に単方向か双方向かの違いだけでしょう。
つまり「参照」を逆向きにも自動的に張る仕組みが有れば、それで同じモノになります。
＃他にも色々実装手段はあります。そしてそれを(いちいちプログラマがやるんじゃなく)自動的にそうなるようにすることも可能。
というか、逆に言えば、単方向と双方向をオプションの切り替えだけ(見た目も矢印が違うだけ)で
表現するってやり方が、本当に抽象度が高いかどうか怪しいです。
もっと全然違うものかも知れないものを「兼用」して合体させてるだけ、かも知れないのに。
あと、曖昧な表記ですって？
もし識別子として日本語が通る言語ならば、「承認する」って
そのまま書いてコンパイル通るじゃないですか？
曖昧でもなんでもないじゃないですか？
＃どーでもいいがJavaは日本語とおりますね。変数名とかは日本語でOKみたい。こないだ気付いて爆笑した。
＃ただしJavaはClassファイル名がClass名と同名であることが義務付けられてるために、
＃ファイル名としてその日本語名が処理できない環境ならば、アウト(^^;
＃Win上のJDKでは、javacどころかjarすら日本語ファイル名が処理できないようで…なんだかなあ…
それとも「済ませられる」ってのを「処理まで記述しないと完結しない」という意味で
捉えてらっしゃいますか？
だとしたら、それはなんか変です。とりあえずオブジェクト(指向)ならば、
処理はさておいて先ずクラスと「属性」の定義を脊髄反射的に済ますことが出来る。
つまり望みのクラスに「承認する」という属性を作ればいいんです。
数十秒で書けるでしょ？コード補完機能のついた環境ならsetter/getterまで作っても殆ど時間を要しないし、
そもそも「思考の抽象性」も損なっていない。
＃型を考えるのは面倒(=抽象性を妨げる)ので、型なし言語のほうが便利です(^^;
そして、昔のエライ人も言っているように、属性さえ(きちんと)設計できれば、後はなんとでもなります(^^;
つまり、属性決めたところで話を一段落させていいんです。
>ビジネスロジックとマシン語のインピーダンスミスマッチの
>総量は不変なので、「人間の高度な思考」の必要量は一定
それはマシン語に展開した後の総量を見れば同じでしょうけど、
人間に課される量、つまり展開される前の量、は変化するんじゃないですか？
俺が個人的に「足し算と掛け算の違い」と呼んでいる現象(?)がコレに当たるんだと思います。
たとえば10を表現する際に加算しか使っちゃいけないというルールなら、3+7だろうが2+8だろうが
合計は10になる(当たり前)ですが、積算も使ってよくなれば2*5とか出来る
Re:javaでイイと思う (スコア:0)