この前ケント・ベックさんの実装パターンという本を読んだんだけども。 ソースはコミュニケーションをとるように記述する必要があると述べていた。 その中で、○○Implのネーミングはひどいと言っている。 たしかに実装クラスとインターフェースで区別を付けたいというのはわかる。 ○○Implだと実装クラスが複数ある場合は区別できないのも困る。 それのサブクラスを作って拡張するときにはなんと命名するのだろう? ○○ImplExtとでも、○○ImplSubとでも付けるのだろうか? 考えてみるといろいろ疑問に感じてきた。 そこでJavaのパッケージはどうなんだろうと思って調べてみた。自分の経験からJavaパッケージに○○Implって付いてるのはあまり見たことないので・・・無いのではないかなと思ったけども。 結論から言うと20クラスが○○Implだったり○○ImplFactoryとか命名されていた。(※イン
私は或るシステムの開発(プログラム)を担当しているのですが、 資産のファイル名の命名規約に疑問をもっています。 例えば以下のようなファイル名にすると... DH01UVN001.java DH01UVN002.java public void unshu_mikan () { : DH01UVN001 dbmgr = new DH01UVN001( DH01UVN002.NORMAL_VALUE ); : } のような記述をメソッドにしなくてはなりません。 クラスが以下の機能であるとすると、 DH01UVN001 DB接続クラス DH01UVN002 定数クラス DH01UVN001.java → DBManager.java DH01UVN002.java → SystemConst.java という方が自然だと思います。メソッドも以下のようになるわけです。 public void un
追記)2016-05-31 最近の私のJavaScript OO は以下の方式に統一しています。 1)抽象オブジェクトの定義(クラスベースOO言語でいうクラス) 「コンストラクタを Named NOOP Function とし、そのprototypeプロパティに属性や、実装を定義する」 2)具象オブジェクトの生成(クラスベースOO言語でいうインスタンス) 「ファクトリ関数内で new 演算子を用いて生成した新しいオブジェクトにプロパティを追加して返却」 3)継承はプロトタイプベースな単一継承を行って派生オブジェクトを作る。 4)多重継承は、条件付き多重継承とも言い換えられる Mixin を利用。 複数の親オブジェクトの特徴を受け継ぐ Mixin オブジェクトを動的生成して単一継承した派生オブジェクトを作る Q.コンストラクタ内に属性定義しないのか? A.しないです。多重継承を動的に行うため
クラスの抽象化を考えるとき、「抽象クラス」にすべきか、 「インターフェイス」にすべきか。 それを決め クラスの抽象化を考えるとき、「抽象クラス」にすべきか、 「インターフェイス」にすべきか。 それを決める際のもっとも 明確な基準を教えて下さい。 誰でも簡単に理解できるような 「○○なら抽象クラス、××ならインターフェイス」という 明解な判断の基準をぜひ知りたいのですが。 *All Aboutガイドからの大質問特集の質問です。 回答する際は、Yahoo!知恵袋トップから特集内容をご確認ください。*
7.1 Builder パターンとは 第7章では、Builder パターンを学びます。builder とは、建築者や建築業者などを意味する単語です。Builder パターンとは、同じ作成過程で異なる表現形式の結果を得るためのパターンです。 例えば、家を建てることを考えてみます。完成する家がどのような家になるかというのは「家の構築過程」と「素材」大きく2つの要素で決定されると考えてみてください。「作成過程」とは、「どのような順番で、どこに何を配置していくか」というようなことであり、「素材」とは、「柱には何を使って、壁には何を使って・・・」ということであると考えてください。 このとき、「作成過程」には、"平屋を建てるための作成過程" や "2階建ての家を建てるための作成過程"、または "少し変わった平屋を建てるための作成過程" など様々なものが考えられます。同様に、「素材」にも、"柱は木で、壁
たしかに使い方によっては非常に読みづらくなるのは事実だから、「あまり多用しないでほしい」という気持ちもわからないではない。 でも、このサンプルでそれを言うのはあんまりじゃなかろうか。 以下のようなメソッドチェーンは読むのが困難だ。 my $loader = Loader->new; my $book = $loader->load( 'Book' )->build loadメソッドが自分自身( $loader )を返却して、そこからbuildが呼ばれたのか、他のオブジェクトが返却され、そこからbuildがよばれたのかがわからない。 だから、あんまりメソッドチェーンを多用しないでほしい。Mojoのソースコードを読んでいてそう思った。 http://d.hatena.ne.jp/perlcodesample/20090217/1233844169 ふたつめの文をそのまま英語として、名詞と動詞に
仕事としてコードを書くようになって3週間が経ったので ここらで所感をまとめてみたいと思う。 ベンチャーと大手企業の違いみたいなことを書いてもいいんだけど、 正直今のところ「あまり変わらない」印象。 それもそのはず、現職もエンプラ向けの仕事。 SIと仕事のやり方はかなり似ている。 ので、純粋にプログラマとして思ったことを。 スパゲッティコードとの出会い この3週間で触ったのはウチの会社で改修・保守をやっているシステムの バッチや管理画面の細かい修正など。 コードは全てPHPだった。 この辺は一番経験のある言語だったので助かった・・・と思った。 が、意気揚々とソースを見て愕然とした。 処理ベタ書きのずらずら続く手続き型の処理は序の口。 関数を定義する代わりにベタ書きスクリプトを外出しにしてrequire 意味不明な変数名 同じ処理をしているはずなのに名前だけ違う関数達 無計画なテーブル定義 業
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く