タグ

designとjavaに関するkiyo_hikoのブックマーク (10)

  • 書籍『APIデザインの極意』(3): 柴田 芳樹 (Yoshiki Shibata)

    APIデザインの極意 Java/NetBeansアーキテクト探究ノート 作者: Jaroslav Tulach出版社/メーカー: インプレスジャパン発売日: 2014/05/23メディア: 単行(ソフトカバー) 目次です。 日語版によせて 訳者まえがき 序章:なぜ新たなデザインが必要なのか 【第1部 理論と正当性】 第1章 現代的なソフトウェア構築の技芸 第2章 APIを作成する動機 第3章 優れたAPIを決定づけるもの 第4章 絶え間なく変わる標的 【第2部 実践的設計】 第5章 必要以上に公開しない 第6章 実装ではなく、インタフェースに対してコーディングする 第7章 モジュール方式アーキテクチャの使用 第8章 クライアント用とプロバイダ用のAPIを分離 第9章 テストの容易性に留意する 第10章 他のAPIとの協調 第11章 APIの実行時の側面 第12章 宣言型プログラミング

    書籍『APIデザインの極意』(3): 柴田 芳樹 (Yoshiki Shibata)
  • java-jaで例外処理の話をしてきました - 西尾泰和のはてなダイアリー

    ブログを書くまでがjava-jaですが、もう眠いのでとりあえず1行だけ書いて、あとは徐々に書き足す。 会場を無料提供してくれたグリーさん、ありがとうございます! 誰かが検査例外の話をするだろうと思って書かなかったら結局誰も言及しなかった、Javaのコミュニティなのに。 っていうか聴衆が100人もいると、もしかしてそもそも「検査例外ってなに?」って人もいたんじゃないか?「検査例外がOCPを壊す」とか「Liskovの置換原則のLiskov」とか通じてるんだろうか?とりあえず直和型が通じてないことだけはひしひしと感じた。 Twitterの自分の発言を転載しておく。 ちなみにZen of Pythonでも「エラーを握りつぶすな」と書いてあります 禅 of Python: 20の格言 「例外はそもそも何のため」ってところ、ざっくり省いたんだけどもそういうところのほうがニーズあったかね?? 「C#1.

    java-jaで例外処理の話をしてきました - 西尾泰和のはてなダイアリー
  • Java 暗号化拡張機能 JDK5.0

    Java Is the Language of Possibilities Java is powering the innovation behind our digital world. Harness this potential with Java resources for student coders, hobbyists, developers, and IT leaders.

    kiyo_hiko
    kiyo_hiko 2011/08/21
    「意味」とか「価値」とかよく出てくる。この辺の感覚は参考になる。「やれること」と、「やるべきこと」は違う。
  • 高慢と偏見(1)隣は何をする人ぞ:Press Enter■:エンジニアライフ

    ふつーのプログラマです。主に企業内Webシステムの要件定義から保守まで何でもやってる、ふつーのプログラマです。 高学歴で長い経験に自信を持つエンジニアは他人の話を聞かなくなる、というのは広く世に知られた真理の1つである。 K自動車ICTシステム部の三浦技術担当マネージャは、そのようなエンジニアの生き見のような人だった。初めに言葉ありき。私が聞いた三浦マネージャーの最初の言葉はこうだ。 「オブジェクト指向など、実業務では使いものにならない!」 私の名前は川嶋ミナコ。横浜市内の某所にオフィスを構えるシステム開発会社――いわゆるベンチャー企業というやつ――に勤務しているエンジニアだ。社員数は20人前後。最近は受託開発の案件はほとんどなく、大手ベンダやエンドユーザーのシステム部門に常駐して開発を行うことが多い。 K自動車への常駐もその1つだった。部品調達システムの大規模なリニューアル中で、あちこ

    高慢と偏見(1)隣は何をする人ぞ:Press Enter■:エンジニアライフ
    kiyo_hiko
    kiyo_hiko 2011/04/06
    「オブジェクト指向など、実業務では使いものにならない!」・・・か・・・漢だ。。。
  • ドラゴンボールで学ぶオブジェクト指向 改 - 達人プログラマーを目指して

    ドラゴンボールといえば、大変に人気の高い国民的、いや世界的な漫画、アニメですが、昨日匿名ダイアリーでドラゴンボールをネタにしたオブジェクト指向の解説がホッテントリに入っていました。 ドラゴンボールで学ぶオブジェクト指向 多くの人に親しみやすい題材でオブジェクト指向の考え方を解説するというのは非常に興味深い試みなのですが、オブジェクト指向の説明としては不適切なところがあり、ちょっと残念な内容になっています。私自身ドラゴンボールの専門家(ドメインエキスパート)ではないため、不正確なところがあるかもしれませんが、ストーリーを思い出しながら、私なりにドラゴンボールをネタとしたオブジェクト指向の解説にリトライしてみたいと思います。 なお、オブジェクト指向でもプログラミング言語によって表現できる内容が異なるため、当然設計技法は違ってきます。ここではJavaC++、C#、Visual Basicといっ

    ドラゴンボールで学ぶオブジェクト指向 改 - 達人プログラマーを目指して
  • Javaが創成期に目指したオブジェクト指向とは(1)~導入 | URIN HACK

    Javaは創成期に何を目指し何を解決したかったのか ― を考えることで、オブジェクト指向(プログラミング)に対する理解を深めることができます。 連載は、非オブジェクト指向言語が持つ問題をJavaがどのように解決したかを知ることで、オブジェクト指向の質を理解することを目的としています。非オブジェクト指向の代表格としてC言語を主として扱いますが後半ではC++の問題にも触れます。 (JavaC++のように静的な(固い)オブジェクト指向プログラミング言語の問題を、Rubyなどの動的な(柔らかい)言語が、どのように解決したのかについて、別の連載テーマとして取り上げる予定です。) 「オブジェクト指向」という言葉(の少し歴史的な話) Java以前のオブジェクト指向はソフトウェア開発に直結する技術でしたが、Javaによって爆発的に「オブジェクト指向」という言葉が広まって以来、徐々に設計や要求定義と

    kiyo_hiko
    kiyo_hiko 2011/02/19
    構造化とOOは相反しない、延長線上・・・分かる気がする。自分はCからPerlに進んだ者だけど、Perlで構造化しまくったら、いつの間にか全部クロージャーになってた(クロージャーはオブジェクトと非常によく似ている)
  • Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか? - 達人プログラマーを目指して

    プログラミングと設計は来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の

    Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか? - 達人プログラマーを目指して
    kiyo_hiko
    kiyo_hiko 2010/12/04
    本質を理解出来ない奴にどんなに素晴らしい道具(言語やOSS)を与えても無駄。そんな上流が多いのが問題。http://gihyo.jp/lifestyle/serial/01/software_is_beautiful/0004の「大切なのは開発言語やツールではない」に通じるものを感じた。
  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
  • Administrative Quarantine

    Your system administrator has blocked your computer or device. Please contact the system administrator.

    kiyo_hiko
    kiyo_hiko 2010/11/29
    「インヘリタンスは、 基本クラスの『特殊な例』を作成する目的にのみ使われるべき機能である。 」
  • 開放・閉鎖原則

    今回は、開放・閉鎖原則のお話です。 これも、リスコフの置換原則と同じかそれ以上に、ソフトウェア開発者の方には有名な原則ですね。 これも、開発の現場では、みんな知ってるにもかかわらずないがしろにされがちな原則です。 英語でopen・closed principleですので、OCPと略されたりもします。 ソフトウェア開発者でない方には、この原則の概念を理解していただきたいと思います。 この原則によって、あなたの生活からストレスが軽減される…かもしれません。 ソフトウェア開発者の方には、この原則の重要性を再認識していただきたいと思います。 コンテンツ計画は、細かければ細かいほど失敗しやすい例: 旅行計画オープンでクローズドオススメ計画は、細かければ細かいほど失敗しやすい 何か重要なやるべきことがあるとします。 すごく楽しみにしてた観光だとか、失敗できない仕事だとかそういうことです。 そんなとき、

    開放・閉鎖原則
    kiyo_hiko
    kiyo_hiko 2010/11/24
    これは座右の銘レベル「計画は、細かければ細かいほど失敗しやすい」
  • 1