●●ｵﾌﾞｼﾞｪｸﾄ設計は何故流行らないの？（2）●●

俺ハード屋さんだったけどそんなもん知らんな。
WorkViewなら知ってるが

>>949
もまえPGだよな仕様書よんでね
http://www.pcisig.com/members/downloads/specifications/pciexpress/PCI_Express_CEM_r2.0_cb.pdf

コテハン二人が完全に荒らしてるな
あからさまな自演も悲惨すぎる

田舎の走り屋レベルでも車体構造分かってるよ

田舎の痛車使いですら、それぐらい解かってるのになw

>>938
自分の乗る車にも興味を持たないドライバーだから、クビになったって事だろう。

>>949
じゃ、半導体の共有結合の話からいってみようか。

>>658 先生！
知らないんで、そ、その半導体の共有結合に説明お願いします。

>>959
真性半導体であるところのSiやGeはIV属だからして、最外殻の電子は4個なわけだが
共有結合することにより8個あるように振舞うわけさ。んで僅かな不純物を入れることで
電子が余ったり (N型半導体)、足りなくなったり (P型半導体) するわけだね。
でもって、めんどくさいからあと自習。ぐぐれ。

以下、各自予習しておくこと。
　　ダイオードとトランジスタ
　　バイポーラかユニポーラか
　　論理ゲートとデコーダ
　　フリップフロップ、カウンタ
　　ワイアードロジックからマイクロコンピュータへ
　　高級言語の登場
　　制御の抽象化、データの抽象化
　　ソフトウェア・パターン

でも職業PGやSEはなーんも知らんでもなれるらしい。

電子回路専攻だから前半はなんとかなる
でさらに後半のものも勉強したら潰しが利いて使い捨てにされないプログラマになれますか？

>>960-961　先生有難うございました。全然分からなかったでが
>でも職業PGやSEはなーんも知らんでもなれるらしい。
は激しく理解出来ました。

>>961
高級言語云々以降の記述が薄いね。
・・・本当に薄いのかも知れないけど。

>>962
使い捨てにされないプログラマになるためのスキルは自分で選択汁

>>964
薄いのは俺の知識。関数型とかSmalltalk系OOPLとか知らんし。

> ワイアードロジックからマイクロコンピュータへ
> 高級言語の登場
この間に
ノイマン型アーキテクチャの発明
マシン語の登場
アセンブラ出現
Unixの製造
Unixを移植しやすくするための言語C登場
さまざまなプログラム言語、言語の方言乱立により規格化の機運が高まる
とかが入る必要があると思う

オブジェクト的プログラムの話は多いけど、設計の話は少ないからじゃね？

オブジェクト指向分析が今一流行らない理由。それは、多分、日本の平均的な
技術者の英語力不足も一因だと思うんだ。
オブジェクト指向分析の基本は、ドメインに存在する概念を擬物化し、名詞を
クラスや属性に、動作や振る舞いをメソッドへと、抽象化していく作業なのに、
その仮定で、ドキュメント（DB設計書やクラス設計書）へ記載されるキーワード
の扱いが中途半端で、trnsts とか shipdt とか chkflg とか何だかぱっと見、
よく意味のわからない識別子が使われてしまうんだよな。
メソッド名にしても、addSyohizei みたいに和洋折衷になったり、isExist みた
いに、間違った英語表現になったりしてるのをよく見かける。
エラーもせっかく例外という抽象化表現があるのに、いまだに旧態依然のエラー
番号で管理してたりとか。

そもそもプログラミング言語の文法が英語をもとにしてて、英語名と相性がいい
ものなのに、そのメリットを無視して変な名前をつけてるせいで、オブジェクト
指向が本来もたらす分かり易さという恩恵が、日本人に対しては半減されているん
じゃないかと思ったりする。

>>968
結局英語解かればOOもできるなんて
どっかのDQN族議員級の低能な発言をするなw

ビリーにでも入隊してろこのｸｿﾋﾟｻﾞ

>>969
「英語できない→OOできない」
を「英語できる→OOできる」に勝手に変換すんな
おまえもうPGやめろ

>>968
addSyohizei に関してはアレだけど、isExist は英語圏の人でも普通にやるぞ。
Goggleのソースコードサーチでもかけてみろ、禿。

英語力は重要だが、それは最新技術を読むためと、英語をベースとしたプログラミング言語になれる為。
英語の文法能力なんていらねーんだよ。

ワンモアセッ！

ここでビリーバンドなしで参加しているブリジェットを見てみよう

>>969
ちがう、英語だけ解ってもダメ。ただ英語へ変換できる能力があった方が
より理解し易くなるし、表現方法も洗練されてくると思う。

JavaのBean規約で、述語にはisをつけるって決まってるから
isExistはしかたなくやってるんだよ。

英語英語って、
おまぃらかぶれるのは結構だが、
作業してる連中が「英語ができること」で集められてるか？
言語と経験年数だけだろ。
たまにメソッド名や変数名に必死になって英語表記しようとする奴がいるが、
英語にこだわりすぎて、逆に可読性が落ちてることに気づかない奴がいる
重要なのはそういうセンス。英語がどうこうなんてのは二の次。

インチキだから流行らない

>>976 例を書いてくれなきゃ解りにくい。もしかして自分のこと言ってんのかw

>>977 インチキな奴に言われたかない。

>>978
似非PG発見

>>980
なんだよ書けねぇのかよ、説得力無い奴だなぁ。もう辞めたら？

>>976
全然関係ないけど、最近はTOEICの点数取るのを義務付けられてる企業は多い。
繰り返すけどOO云々には関係ないと思う。

>>981
電球自演やめたら？

TOEIC一級です

ちっ、バレたか。

>>984
新しいな

あれだ策士策におぼれる。ってやつ
オーバーライドを多用することだけを考えて作ったりとか。
そーゆーことでそ？
javaで構造化、これでいいよ。インターフェイスは定数書き込むだけ。

だけどフレームワークと職場には多多異性が必要だよね。

TOEICって級じゃないだろw

ん？
おれは2段だぞ

実際、OOは慣れの問題でもある。
初めての言語がJavaでOOで組んでいる人もいるが、論理を明確に説明出来なくても、
問題なく設計出来ている人も多い。その人達に聞くと、構造化の方が難しいと言っている。
確かにそうだ。OOの場合は最初は物体をオブジェクトにして考えるからブレが少ない。
それに対して構造化は要求をフローに変換してから考える。つまり変換作業が必要だ。
問題なのは「変換に慣れてしまった人」が「新たにOOをやる場合」である。
まあ、やらなくてもいいんじゃね？

>>990
>まあ、やらなくてもいいんじゃね？
ならばなぜ今までOOPL使用時の利点を何十もレスしたのか？

>>991
すまん、途中まで書いていて、疲れて適当になった。

なんといういい加減さ、それがおじゃばクオリティー

>>990
OOは勉強を始めた所なのでなんともいえないが、
構造化ってのは人間側の思考とプロセッサの最大効率との折衷案という側面を持つ。
人間にある程度わかりやすく、かつプロセッサに都合のいいように
合理的な細分化を行う必要がある。
もともとは大規模なシステムを多数の小規模の物にして普通の人間でも
把握しやすいようにという思想が根底にあるし、それが目的。

対するオブジェクトなんちゃらはコンサルが放つ銀の弾丸という側面を持つんだろ。
ここでその本質を目にすることは無茶苦茶少ないし。

だから、業務フローを表現するのにはオブジェクト設計は適さないんだって
せいぜい画面に貼り付けるチェックボックスとか、プルダウンとか、
文字列とかの「部品」を設計するのに役に立つぐらい

業務フローはフローチャートが適する
データーベースは変化していく集合を扱うのでOOは適さない。

.NET Framework にしても、JavaAPI にしても、STLにしても、
オブジェクト指向で、とってもきれいに使い易く設計してある。
構造化設計より、よっぽど合理的で解り易い。
これみて、ＯＯを否定する奴は、自分にこういう設計ができない
からひがんでるだけとしか思えないんだが。

多分オレが頭悪いからなんだけど、OO勉強しだした頃は、どうあがいてもうまくｲﾒｰｼﾞが湧かなくて、挫折しそうになった。

習うより慣れろってな

せん

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。