単一責任の原則（Single responsibility principle）について、もう一度考える | オブジェクトの広場
単一責任の原則（Single responsibility principle）について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle：単一責任の原則 Open/closed principle：オープン/クロースドの原則 Liskov substitution principle：リスコフの置換原則 Interface segregation principle：インターフェース分離の原則 Dependency inversion principle：依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や
Object-Oriented Conference 2024 を楽しもう | オブジェクトの広場
Object-Oriented Conference 2024 （オブジェクト指向カンファレンス）が2024年3月24日（日）に開催されます。オブジェクト指向技術を発信する場から始まった「オブジェクトの広場」も、イベントを楽しみに待ちたいという気持ちを乗せて、歴代編集員がオブジェクト指向に関するおすすめ記事を紹介します。皆さんの興味に合う記事はあるでしょうか。 はじめに Object-Oriented Conference は、オブジェクト指向をテーマにした国内唯一のITカンファレンスです。アーキテクチャや分析設計をはじめ、現場で活かすためのプラクティスなど様々なテーマが扱われます。 そんな Object-Oriented Conference を楽しむ準備をしたいというのが本記事の趣旨。 「オブジェクトの広場」をさかのぼると、オブジェクト指向に関する記事が多く存在します。本記事では、歴代
間違いやすいセキュリティ用語 | オブジェクトの広場
セキュリティ技術としての「署名」と「証明書」はどう違うのでしょうか？「復号化」という用語に違和感はないですか？本記事では、間違いやすい、混同しやすいセキュリティ用語について解説します。 はじめに セキュリティ技術としての「署名」と「証明書」はどう違うのでしょうか？ 「復号化」という用語に違和感はないですか？ 同じ用語を人によって違う意味で使っていて、仕様書の解釈や打ち合わせでのコミュニケーションに困ったことはないですか？ 本記事では、間違いやすい、混同しやすいセキュリティ用語について解説します。セキュリティ分野の基礎知識を得たいITエンジニアのみなさんの参考になれば幸いです。 目次：間違いやすいセキュリティ用語 暗号化と復号「化」？ 暗号方式の種類 ー 公開鍵暗号と非対称鍵暗号は同じ？ 暗号鍵の種類 ー 秘密鍵は secret key？private key？ 呼び方のバリエーション おす
[ 技術講座 ] Domain-Driven Designのエッセンス -目次-｜オブジェクトの広場
［技術講座］ DDD難民に捧げる Domain-Driven Designのエッセンス 第 1 回 ドメイン駆動設計とは 第 2 回 DDDの基礎と実践 第 3 回 大規模なプロジェクトへの適用 DDDパターンカタログ パターン名 参考訳 I. Putting the Domain Model to Work Ubiquitous Language ユビキタス言語 Model-Driven Design モデル駆動設計 Hands-On Modeler 実践的モデラー II. Building Blocks of a Model-Driven Design Layered Architecture 層状アーキテクチャ Smart UI （アンチパターン） 利口なUI Entities エンティティ Value Objects 値オブジェクト Services サービス Modules モジ
[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』（以降DDD）は、「
アジャイルチームを楽しくする工夫 その3 - 今の気持ち | オブジェクトの広場
毎日一緒に仕事をしていれば、チームの空気って何となく感じますよね。でも、「そのあなたの“感じてる”空気って本当にあるの？」「ホントに皆がそう思ってるの？」って改めて訊かれると、「さぁどうなんだろう」と考え込んでしまいませんか。あるいは、あなたの気持ちとチームの空気が違った時、空気を読んで自分の気持ちに蓋をしてしまっている、なんてこと、ありませんか？「今の気持ち」は、開発チームの自主性を後押しするためのアジャイルチームの小さな工夫です。 チームの空気、読めますか？ 「当然、読めるに決まってる！」 ですよね。 でも、ちょっと待ってください。あなたの読んだ、その チームの空気 なんですけど、本当に全員がそう思っているのか、どうやって確認してますか？ もしかして、空気を読んで確認？ その場合、あなたは本当に空気を読めているのでしょうか？ 「うーん、改めてそう訊かれると、困っちゃうなあ……」 こんな
エンタープライズアジャイル徒然草 | オブジェクトの広場
本コラムでは、筆者が「エンタープライズアジャイル」に関係すると判断した雑多なトピックスを徒然なるがままに取り上げて論じていくつもりである。第 1 回は、筆者が最近執筆に関与した書籍「エンタープライズアジャイルの可能性とその実現への提言」 [1] 向けに執筆した「よく見られるアンチパターンと落とし穴」を掲載する。 エンタープライズアジャイルの実現を阻む障害を理解するために、本記事では日本の企業でアジャイル開発を行う際のアンチパターンを説明する。従来の開発方法に大きく手を加えないアジャイル開発風の開発を行うことでは、アジャイル開発の良さは現れないことがよく分かるだろう。 1. 「うちでもアジャイル開発やってみました」アンチパターン 日本の企業でアジャイル開発を試みる場合、明確な失敗ではないものの、単発のお試しで終わることも多いように思える。これを「うちでもアジャイル開発やってみました」アンチパ
ソースコード品質改善パターン | オブジェクトの広場
ソースコードを漸進的に改善するための組織的活動のパターン・ランゲージを作りました。リファクタリングはソースコードの改善テクニックですが、ソースコードの品質改善活動を成功させるためにはリファクタリングだけでは足りません。品質改善を利害関係者も含めたチームの活動として捉えることが必要です。このソースコード品質改善パターンを参考にしてソースコードの品質改善を成功させてください。 ソースコード品質改善パターンとは 筆者は、製造業の組込みソフトウェア開発チームに対してプロセス改善や技術支援のコンサルティングを行っています。そのコンサルティングの中で、ソースコードの品質を漸進的に改善することに成功したチームに共通するコツのようなものをパターン・ランゲージとしてまとめたものが、このソースコード品質改善パターンです。 まだ、数チームの事例分析に基づくものなのでパターン・ランゲージとして練りきれていないとこ
Hansoftでスタートするアジャイル開発 第1回 | オブジェクトの広場
Excelでバックログを管理し、タスクボードで日々の進捗状態を可視化する、これは小さなチームがアジャイル開発を気軽にスタートできるベストプラクティスと言っても過言ではありません。しかし、開発期間が3か月を超えたり、チームメンバーが5人になったり、マルチサイトの開発が始まったりといった状況になると、何かプロジェクトの可視化をサポートし、チームメンバー間のコミュニケーションを促進するより専門的なツールが使えたら、というような気持ちが次第に沸いてきます。 本記事では、以下の構成で、プロジェクト管理ツールHansoftを用いてアジャイル開発をスタートする方法を紹介いたします。 アジャイルプロジェクト管理には 3 つのポイントがある Hansoftとは何か Hansoftでスクラムしてみよう Hansoftのインストールと設定 プロダクトバックログの作成 リリース計画の作成 日々の作業 Hansof
組み込みアジャイルコーチ James Grenning さんインタビュー IN JAPAN | オブジェクトの広場
去る 5 月に東京にて開催された Agile Japan 2013 にてキーノートスピーチおよび TDD のワークショップを担当された James Grenning さんにインタビューを実施させていただきました。 James さんは、組み込みソフトウェア開発におけるアジャイル開発のコーチ・トレーナー・コンサルタント、『 Test Driven Development for Embedded C（翻訳書は「テスト駆動開発による組み込みプログラミング ― C 言語とオブジェクト指向で学ぶアジャイルな設計」）』の著者、アジャイルソフトウェア開発宣言の著者 17 名の 1 人、そしてアジャイルな見積り手法「プランニングポーカー」の考案者でもあります。 2012 年 10 月号で公開したインタビュー記事 *1 に続く本記事では、これから TDD に取り組む人、すでに取り組んでいる人が感じている疑問
C＋＋クラス設計に関するノート
C++が他のオブジェクト指向言語と比べて難しいのは、やはりメモリ管理をプログラマが自分でしなければいけない点だと思います。よくよく注意しないと、削除し忘れたり、同じオブジェクトを2度削除してしまうというエラーが発生します。このノートでは、オブジェクトを「値オブジェクト」と「参照オブジェクト」というカテゴリに分け、詳細設計の段階で注意すべき点を整理しておきたいと思います。 0. はじめに 私自身今までいくつかのプログラミング言語を使ってきましたが、C++ が他のオブジェクト指向言語と比べて難しいのは、やはりメモリ管理をプログラマが自分でしなければいけない点だと思います。例えば、 Person* person = new Person(); と生成したオブジェクトは、使い終わったら次のように削除しなければなりません。 delete person; 生成してすぐ削除するなら簡単なのですが、実際に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
