コンピュータプログラミングについて

Question

質問①
　何でテレビオブジェクトにアクセルペダルが付いているのですか？
　そうするとプログラミング効率が上がるのですか？
　何で誰もそんなもの取り払えと言わないのですか？

質問②
　何で開発環境がことごとく重いのですか？
　そうするとプログラミング効率が上がるのですか？

質問③
　Webシステム開発で使うフレームワークが何種類も生き残っているのはなぜですか？
　なぜいつまで経っても淘汰され切れず、いいとこ取りした決定版が出来ないのですか？

質問④
　ソースコードlが
　cfbjikdnbdznb.szrgug(xfjj.xfhcfh(cfxgjcfjy.xdghdgh(hkgj,xfhjxhf.fgjnfhnj,fhjfhyj.sfgsg)))
　のように、長い文字と点がいっぱいあるのはなぜですか？
　こうなっているとプログラミング効率が上がるのですか？

lv4u · Accepted Answer

分かるところだけ

②：人間は楽をしたいものです。また、前よりも複雑で難しい処理、高度な処理をプログラムにやらせたいと思うもの。
やるべきことが１００から１０００に増えたとき、人間が楽するなら、増分はコンピュータ、つまり開発環境にやってもらうしかない。
それで、どんどん開発環境は重くなりました。
でも、コンピュータの処理能力は、ＣＰＵ高速化、メモリー・ＨＤＤの大容量化、高速化したため、トータルとしてプログラミング効率はアップしました。

③：Ｗｅｂシステムに限りませんが、現在稼働中のシステムは、今後しばらくはメンテしながら使い続けられます。
「あんな腐ったフレームワークなんて捨てちまえ！！」と思う人もいるでしょうが、それが無いとメンテナンスできませんから使われますよね？
そのメンテ担当者は、今年新卒の派遣プログラマさんかもしれない。となれば、「腐ったフレームワーク」だとしても、勉強するために本が売れるかもしれません。
少なくともフレームワークを必要とするプログラマが１人増えることは確かです。そして腐ったものは生き延びます。

「いいとこどりした決定版」までは行かなくとも、「腐った」よりもましな「腐りかけ」の別のフレームワークは誰かが作っていると思います。
でも、「腐ったもの」で作られた既存システムを「腐りかけ」のフレームワークに乗せかえると、修正工数が発生します。再テストも必要です。
新規開発するほどの要望と予算があれば、いいとこどりしたフレームワークが使われるかもしれませんが。

ということでフレームワークではありませんがＪａｖａのような腐った言語で作られたレガシーシステムでさえも、使い続けられるのです。
某銀行のように予算がある部門では、トラブル原因となるＪａｖａを捨てて、ＣＯＢＯＬでシステムを作り直すこともあるみたいです。

④：プログラミング効率、言い換えると開発効率を上げるためには、新規開発を減らす必要があります。

例えば、新築の一戸建てを建てる、あるいは、３０部屋あるマンションを新築するっていうとき、大きな手間（予算）を食うのが水回りです。
もし、大工さんが台所やお風呂場のサイズに合わせて、手作りするなら、金額も上がるし、工事期間も長くなります。
でも、住宅機器メーカのカタログにある売れ線のシステムキッチン、ユニットバスを使えば、金額を安く、工期を短くできます。

つまりは、ゼロから作るのでなく、事前に作られた部品を組み合わせれば、開発効率がアップするということです。

とはいえ、そこに住む人にとって、一生の買い物となる家であれば、カタログにあるセットでは、満足できませんよね？
「このキッチンの上収納は、電動で上下する可動式にしてくれない？コンロは料理好きの妻の要望で、ＩＨじゃあなくガスコンロにして欲しい」
「組み込みの食洗機はいらない、かわりに調味料などが入れられるような収納にして欲しい」
なんて、一部の不要なものを削って、代わりに別の部品を差し込めるようにしてあれば、お客様の要望に素早く対応できます。

そんなお客様の細かなオプション要望を書類にまとめると、システムキッチンだけで２０個くらいの記入欄が必要になるかもしれません。

そして、プログラムも同じことが起こっているわけです。そのため、ソースコードのある関数のパラメータが、最初は３個だったかもしれませんが、要望に応えるために関数（部品）の拡張をし続けた結果、１０個とか１５個になったりするのです。

それでも、そのプログラム部品を使わず、パラメータが少なくて済むようなパーツを新規で作るよりは、はるかにプログラミング効率がアップします。

ちなみに、オブジェクト指向の延長線では、このようなパラメータの数が増える「パラメータ地獄」を防ぐことはできません。
でも、ラムダ式という構文を導入すれば、この地獄をある程度防ぐことが可能になります。

Ｃ＃では、２００７年からラムダ式が使えるようになりました。
Ｊａｖａは、Ｃ＃で使われるラムダ式を横目でみながら、「あれいいなあ、Ｊａｖａにも欲しいよおおおおお」と嘆き、やっとのことで２０１４年のＪａｖａ８からラムダ式が使えるようになりました。

時代に遅れるＪａｖａを使い続けるのは、メンテするからとか、就職に有利という考えなら仕方ありませんが、そういうしがらみが無いなら、情弱ってことかもしれません。

lv4u · Answer

>>たかがListBoxに160種類もの指示がある事に、どうしても納得がいかないのです。

たしかに、「たかがListBoxのために160種類もの指示って・・・」って思う部分もありますよね？
でも、プログラムを使うユーザ側の立場からすると、細かな部分でいろんな注文がでるわけです。
それらのすべてに答えようとしたとき、共通部品（クラス）に対する指示は、どうしても増えてしまいます。

というか、自分が使うプログラムを作っているときでさえ、マイクロソフト提供のクラスのプロパティやメソッドが足りないので、プロパティを追加したり、継承クラスを作ることがあったりしますので、160種類になっていても、「しゃあないなあ」と思っています。

以前、ＤＯＳ環境でつかうアプリ用の共通部品（米国製）のソースをみていたとき、「こんなに設定値が多いのって、めんどくさいなあ」なんて思っていたことありましたけど、いざ共通部品をつかって実用のアプリを作り出すと、「足りない機能を、この部品に追加したいけど、影響範囲が広範囲だからどうしよう？」なんて悩んだりしました。
まあ、長い時間かけて、そのＣソースと格闘し、ＧＵＩ部分の機能拡張をしましたけど、現在のＣ＃であれば、似たようなものが極めて短期間に完成させることができてしまいます。

ところでＣ＃の源流を探ると、今は無きボーランド社のDelphiにたどり着くそうです。
Delphiを始めて使ったとき、その機能に驚いたものですけど、最近は、Ｃ＃の拡張された機能を応用することで、いままで思ってもみなかったようなことが可能となり、生産性が大幅アップして、その当時と同じような驚きを感じることがありますね。

tknakamuri · Answer

>ListBoxは160個のプロパティ/メソッドを持っています。

多くはControlから継承しているはず。
描画や配置、イベントを考えるとこんなものですよ。
このくらいでびびってはいけません。
GUI部品というのは共通部分が結構複雑なんです。

大部分は共通なので、個別に覚えることは
僅かです。大変なのは最初だけです。

因みに腕時計の比喩は不適切でしょう。
電子部品のデータシートを思い浮かべるのが適切。

lv4u · Answer

>>そもそも、オブジェクトが無用なプロパティ/メソッドを多く含んでいるのは、
クラス設計から失敗している、いやもっと言えば、クラスという概念には致命的な欠陥があるのではないか？と思ったのです。

無用なプロパティ／メソッドなんて無いと思います。
ただ、メソッドの機能拡張などによって、使われなくなった古いプロパティ・メソッドっていうものはあるでしょうね。

新規開発する方からみれば、それらは”無用なプロパティ・メソッド”に思えるかもしれませんが、古いバージョンから使っている人にとっては、それらは”必要なプロパティ・メソッド”となります。

そして、マイクロソフトでは、質問者さんと同じように、「古いプロパティ・メソッドが表示されるなんて邪魔なだけだ！」と考える人がいるので、ある程度バージョンが進んだ段階で、そういうプロパティ・メソッドは削除されています。

ですので、勉強のために、ネットで探したサンプル・プログラムをビルドしようとすると、「そんなプロパティ・メソッドは無いよ！」と怒られたりしました。
「ネットで公開しているのだから、このサンプルって動いていたはずだよなあ？？」と疑問に思って、改めてサイトの日付を見ると、しばらく前の古い日付だったりしますね。

なお、クラスという概念は有用ですけど、最近のＣ＃では、開発手法においてクラスの地位は低くなって、ラムダ式やLinqとかリフレクション、そして、メタ・プログラミングの技法が重視されているように感じられますね。
なんというか、古い”クラス”という定番商品のみに注目しすぎて、２倍、３倍、あるいは１０倍の開発効率アップを生み出す、これらの新しいテクニックが無視されているという感じがしてしまいます。

そういう点からみると、「クラスという概念には致命的な欠陥があるのではないか？と思ったのです」という質問者さんの考え方は、現象的に当たっている部分があるっていえるかもしれません。

tknakamuri · Answer

>Visualstudio等で"オブジェクト名."をキー入力すると、
>プロパティやオブジェクトの候補がたくさん出てきます。

う～ん、.netの話なんだろうか?
全く具体性がないので何が失敗だとかんじているのか
見当もつきませんね。

私もフレ－ムワーク設計をしたことがありますが、
ソ-スの解りやすさと汎用性/再利用性は相反するもの。
検索した程度でわかるはずありません。そんなミクロレベルの
話より前に、まず設計の基本方針と目的の理解が必要です。

lv4u · Answer

No.1です

④の質問を勘違いしていました。
パラメータの数が多いのじゃあなく、長い修飾子になっていることが質問でしたね。

オブジェクト指向になってソフトの部品化が進んでゆくと、おおざっぱに見て同じ機能だけど、細かな部分で機能の違うソフトの在庫部品がどんどん増えてきます。
それらの部品を重複しない名前で管理するとなると、ＷｅｂのＵＲＬと同じように点で切られた長い文字列になってしまいます。

また、短い名前だと、似たようなソフト部品がまったく同じ名前になる可能性が増えます。
長い名前にすれば、重複するのを防ぐことができます。

プログラミング効率としては悪くなりますけど、必要悪ですね。

対策として、タイピング数を減らすために、マイクロソフトのVisualStudioでは、強力な文字補完機能が導入されています。
これでタイプ数が減ると同時に、タイプミスを減らすことに大きく役立っています。

tknakamuri · Answer

質問① 何のはなし？
質問② 今時i5以上なら何を使っても重くないです。
セレロンならあきらめましょう。
質問③ 用途、規模、使い方により必要とされるものが違うから。
質問④ わかり安いコードは饒舌です。
饒舌なコードは簡潔だけど、名前は長くなります。

コンピュータプログラミングについて

分かるところだけ

>>たかがListBoxに160種類もの指示がある事に、どうしても納得がいかないのです。

>ListBoxは160個のプロパティ/メソッドを持っています。

>>そもそも、オブジェクトが無用なプロパティ/メソッドを多く含んでいるのは、

>Visualstudio等で"オブジェクト名."をキー入力すると、

No.1です

質問① 何のはなし？

似たような質問が見つかりました

関連するカテゴリからQ&Aを探す

デイリーランキングこのカテゴリの人気デイリーQ&Aランキング

マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング