DelFusa Blog 総本山

プログラミングの話題とかです。

NEW | PAGE-SELECT | NEXT

≫ EDIT

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

| スポンサー広告 | --:-- | comments(-) | trackbacks(-) | TOP↑

≫ EDIT

シンプルできれいなソースコード


   ∧,,∧    ソースいじりまくりで
  ミ,,゚Д゚彡   頭痛い。
   ミ つ旦)~~
 @ミ   ミ   
   ∪''∪

最近、ソースコード量は極力減らしたほうが
いいんじゃないかと思うようになってきました。

昔、若いころは若気の至りもあって
人の作るソースはなんて汚いんだ!と思って
ざくざく削除しまくって、
毎日毎日、大幅にソースが減っていくという経験をしたもんなのですが

今、再び、思いっきりプログラムマミレの仕事をしてみると

全然腕は落ちていないんですが

それにしても、今までの効率のよいプログラミングの視点が
少し変わった感じがします。


久しぶりに出会ったのはこういうコードです。

VB.NETなので、概念的なものを日本語で書きますね。

ダイアログ画面をたくさん作る必要があり、共通化もされていないのは
よくあるチーム開発での問題点なのですが、それはよいとして

あるダイアログのForm に MyCaption プロパティが作ってありました。

そのMyCaption を保持するためのm_MyCaptionメンバーが宣言してあって
Form生成時にFormのタイトルにそのm_MyCaptionが代入されているコード。

わかります?
通常のForm.Textを使わずに自前でプロパティ用意しているわけです。



これって、やっぱり相当にムダじゃないか?

どうも抽象化(?)にこだわるあまりに
物事の本質から遠ざかっているように思えます。

DialogForm.Text := "文字";
(.NETはフォームのタイトルはテキストプロパティです)
とすればいいところを、

DialogForm.MyCaption = "文字"となっていて
そのタイミングで何か動作するのなら理解できますが

MyCaptionを普通の一般的なプロパティと同じく
メンバー文字列の宣言とプロパティの実装が記述してあり
フォーム生成時にタイトルに代入されているコードがあり

そういう記述が至る所にあって、
プロジェクトの暗黙の了解的なコードになっていっているわけです。

これはちょっといただけない....




そこでふと、Delphiにおいてもこの現象があるということに気がつきます。

次のコードを書くことは、よくやりませんか?
TForm1略
Private
 FValue: Integer;
Public
 Property Value (略
そして、GetとSetには、FValueに代入しているだけ

これが、オブジェクト指向の、、、至高のプログラミングだとか何とか勘違いしちゃって
「隠ぺいはしなきゃいけない」なんだとか思いこんじゃって作りますよね。普通。

漏れも今まで作っていましたけど、、、、


こんなコード、そもそも必要なんですかと。

Valueに代入タイミングで何かをする必要があるのなら
プロパティ実装することは、当然なのですが
Valueに代入タイミングで何も動作する必要がないのなら
そもそもメンバーを隠す必要ないわけです。

TForm1略
Private
Public
 Value: Integer;

これでいいんですよ。


全くもって、ソースが短い。
そして必要なタイミングがやってきたら、Propety Valueに変更する柔軟さがあればいい。


Form1.Valueを使う側からすれば、
パブリックのメンバーであっても、
パブリックプロパティであっても、ソースは一緒に使えるわけです。
(参照渡しの挙動が若干違うとかいう、重箱隅は却下)

むしろ、Form1.Valueがプロパティの場合は
Form1.Valueを使う側からすると
「隠ぺいされているには何か理由があるはずだ、プロパティアクセスで
 オーバーヘッドができるかもしれない。」
なんて変な思考が割り込んできてしまうから使いにくい。

隠ぺいする必要がなく、代入タイミングで何もしないのなら
フィールドはパブリックで公開。

これが正解だと、今日、気がつき、


柔軟さに対応できるのがリファクタリングということだなあ。と
軽く気がつきました。

ということで「オブジェクト指向=隠ぺいする必要あり。」

という、ルールにしばられることもなく、

本当にシンプルなコードをきれいに効率よく
実現するには、常に固定観念など持つ必要がないんだなと、いうわけかと。

…まあいいんですけどね。その人がその人好きにかけばね。


漏れは、より美しくシンプルに書きますけれども。ミ・ w・彡
スポンサーサイト

| 未分類 | 19:23 | comments:8 | trackbacks(-) | TOP↑

COMMENT

勘違いしておられるようですが、振る舞いを変えずに内部を修正することをリファクタリングというのであり、変数とプロパティでは参照渡しの挙動以外にもアドレス取得の可否や継承による可視性の変更やオーバーライドの可否などといった様々な違いがあるため、リファクタリングとは到底呼べないと思います。
そもそもクラスを使うこと自体、手続きのみで構成するプログラムに比べてオーバーヘッドがありますから、プロパティのオーバーヘッドを気にするなどという考え方はまさに木を見て森を見ずといったところではないでしょうか。
もちろん自分だけが使うコードならどう書いても自由ですが、他人も使うコードではどう使われても問題ないようにすべきです。他人が使うのですから、変数とプロパティの挙動の違いが影響するコードが書かれることもあるでしょう。その場合、あなたの仰る「リファクタリング」で解決することは不可能ですよね。

| | 2009/07/23 23:12 | URL | ≫ EDIT

いえい!!

皆さんも大変ですね。

プログラミングの基本は、ウォズニアックなんかのように
楽しむことが第一なのに、最近はクラスだのフレームワークだの
つまらんの~
(枠にはまって面白くね~~...って言うかついていけない?)

あっしの場合は、最近チームワークと言う重荷は全くないので
自分の好きなように作っとります。
(勿論コメントや最低限の事はしとりますが)

片田舎なので、東京みたいに儲かりませんが、自分を貫いて
行きたいなと・・・

最近、C#も少しやらざるを得なかったけど、Delphi+PHPで全てOK!

こちらの、ブログも自分の為に書いている訳で自由に書いて下さいませ!!

| musa | 2009/07/24 00:32 | URL | ≫ EDIT

とりあえず、「良いソースコード」をもっと読むべき。
もちろんDelphiに限らず、で。
悪いソースばっかり見ててもなかなか理解は進まないと思います。
オープンソースで長い間、保守されてきてるものとか、ね。

| tokibito | 2009/07/24 10:47 | URL | ≫ EDIT

おやおや、このブログはコメントがつくくらいに、人気があったんだ!(w

リファクタリングという定義なんですが、
外部にはFunction Aを公開していて
内部的にFunction Bを使用している場合、内部のFunction Bの引数などは変更しても、外部のAは変更されないのは、リファクタリングの定義としてあってますよ....とかって、、、くどくど説明してもしょうがないか....WikiPediaにも定義はあいまい、みたいな記述もありますね。

プロパティのオーバーヘッドを問題にしているんじゃなくて、行数が増える事での不要な混乱を........って、まあ、これもいいか。

わかる人にはわかるってことで。よろしくです。

俺が勘違いしている、ということでしたら、勘違いしないコードを書いていってください。

| ミ・д・彡 | 2009/07/24 11:51 | URL | ≫ EDIT

お返事

musaさんにお返事
プログラミングは楽しいですね。

「チームワークという重荷」
確かに。。。そういう視点ももてますね。
本来は違うんですが、

コミュニケーションが取れて、エクストリームな
プログラミングが行えると、
ソースが、どんどんいいものに進化していくので
楽しいんですけど、他人の作った不完全なものにあたって
『修正したくない』という足かせを感じるときはありますね。
---
tokibitoさんにお返事
では、とりあえず、
Delphiでの「良いソースコード」のオープンソースとして
DelFusaLibraryをもっと読みます。

あれこそ、良いソースコードの塊でしょう。(w
Delphiプログラマなら全員よむべき。
あれを読むことで
何が共通化で何が汎用的かを知ることができるでしょう。

なーんちゃってね。冗談ですよ。

最高によいソースとは
ソース内部を読まなくても、使って便利だという
『部品化』にあるので、
一般的なきれいなソースを学ぶために、人のソースを
読むことはあまり、ないかな。

他人流ではなく、我流でいまのところは
シンプルできれいなソースをかけるので、それでよいですよ。

必要な分野の必要なものに関しては知りたいですけどね。

今は、DelphiでのEmEditorPluginでのスレッド化について知りたいです。
よいソースコードでオープンできれいさを求められるものが
あったら教えてください。
2chのEmEditorスレで俺が何を作っているのかを知ることができますよ。

---

| ミ・д・彡 | 2009/07/24 12:52 | URL | ≫ EDIT

あと、EmEditorPluginで、サイドバーというパネルを使うものの、簡単なサンプル、Delphiでの実装を知りたいです。エクスプローラプラグインや、アウトラインプラグインのようなもの。

これは作りたい。よいサンプルがあったらいいなあ。

| ミ・д・彡 | 2009/07/24 13:01 | URL | ≫ EDIT

お久しぶりです。

ソースの分量とか、些細な事に気を使っていたら、本来のゴールから遠のきません?自分一人で見切るのが面倒な規模になれば特に。

5年前かな?Java のプロジェクトを指揮してたとき、リフレクションを使って汎用的にアクセスするためにデータコンテナに限り public な定義を許可したことはあるけれど。
独自フレームワークを使って、サーバからリッチクライアントに自動でパラメータを渡すための仕掛けが必要だったため、開発コストとの兼ね合いで限定的に使いましたよ。

ただ、基本的にフィールドを直接 public にするのは、数行短くするためだけのトリックに近く、オブジェクト指向ではなく、構造化的な解と言えるのでは?私は推奨しません。
また、過剰なまでに短く書くとかは、自己満足の範囲になってきますので、自分だけが使う。あるいは、完全に自分の指揮下にあるプロジェクトならば好きにすればよいと思うけれど、
チームで動く場合、誰もが自分と同じ理解レベルで意識して動けるわけでもないし、冗長な書き方であっても、周りが理解できる内容の方が経験則として良いと考えます。
逆に、これはチーム全体のレベルやら職場の風土、個々の経験してきた状況によって、コードの質は大きく変わりうるということでもあります。

で、推奨しない理由としては、この方法には致命的な問題があって、クラスとインターフェイスに関する概念やらパターンに関する理解を深めていれば自明なのだけど、インターフェイスが使えなくなります。
インターフェイスを介してフィールドを制御できないので結局プロパティやらメソッドが必要になるわけです。また、複数のクラスを束ねるためには、それらの親クラスしか使えない事になります。
クラスに対して横串で処理することはできなくなります。

旧来の Delphi の組み方では、あまりインターフェイスを積極的には使わないから、気にならないかもしれませんが、昨今のオブジェクト指向言語においてインターフェイスはスマートに多重継承やらの問題を解決できる強力な機能ですので、その選択肢を失ってしまいます。

ただ、インターフェイスもトリッキーな使い方があるため、この辺はアーキテクトの腕次第なところはあると思いますが。

| じ~る | 2009/09/02 10:44 | URL | ≫ EDIT

こんにちは~~

なかなかこき使われていて、今日は眠いです。
仕事があってありがたい話ですが

とある中枢部分の機能を、
何年かやってたり半年前に入っている人と
同じように、1週間で仕上げて、とかいう無茶をいわれていて
その無茶をけっこうな勢いで仕上げてしまったりするので
まいっちんぐな感じです。

さてさて、フィールドpublic化は必要となったときに
瞬間的にFValueとValueプロパティに変更できるから、という事です。
FValueに代入するだけのValueプロパティには何の価値もないですので
無駄なコードだと思います。

プロパティというよい仕組みは、Value代入時に処理が必要になった時に
Value変数をValueプロパティに置き換える事ができるということかと思います。

> チームで動く場合誰もが自分と同じ理解レベルで意識して動けるわけでもないし、
それはごもっともです。よくわかります。

> インターフェイスを介してフィールドを制御できないので
> クラスに対して横串で処理することはできなくなります。
なるほど。なるほど。
Delphiでは後発な機能でもあり、あまりインターフェースが利用されていませんが
そのような点は利点ですね。
勉強になります。

ありがとうございます。
最近は.NET漬けな感じですが、インターフェースをばりばりと
とはいかないので、学んでおきます。
コメント、ありがとうございます。

| ミ・д・彡 | 2009/09/05 02:19 | URL | ≫ EDIT















非公開コメント

PREV | PAGE-SELECT | NEXT

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。