テクノロジックアートは、「最先端の技術でユーザーニーズに応える」を合言葉に、独自のUML/モデル駆動開発メソドロジーを武器に、皆さまのシステム開発を成功に導きます。 UML/モデリング モデリングスペシャリスト集団が長年蓄積したノウハウをもとに、モデリングを「活用」するためのトータルなソリューションをご提供し、保守性と再利用性の高いシステムを実現します。
Technologic Arts | トップ
テクノロジックアートは、「最先端の技術でユーザーニーズに応える」を合言葉に、独自のUML/モデル駆動開発メソドロジーを武器に、皆さまのシステム開発を成功に導きます。 UML/モデリング モデリングスペシャリスト集団が長年蓄積したノウハウをもとに、モデリングを「活用」するためのトータルなソリューションをご提供し、保守性と再利用性の高いシステムを実現します。
２つのオブジェクト指向ーメッセージ・パッシングと抽象データ型 - Hot Heart, Cool Mind.
オブジェクト指向には、もともとアラン・ケイが創案したメッセージ・パッシングのオブジェクト指向と、その後、抽象データ型から発展したオブジェクト指向の２つがあって、その２つは、プログラム言語の機構の面からは共通する要素も多いのだけどプログラミングに対するビジョンという点では相当に異なっている、という見方があります。 これに関しては、id:sumim さんが「二つのオブジェクト指向とそれぞれのメリット」という行き届いた論考を公開しておられて、僕などはそれを読んで頭を整理した口です。 その後、それを踏まえて自分なりに両者の違いを考えてツイートしましたが、言葉足らずな点もあったので、内容を整理するとともに加筆しました。 言語機構に惑わされるな この２つのオブジェクト指向は、実現する機構の面では似ています。オブジェクト指向の３要素として「カプセル化、継承、ポリモフィズム」があると言われますが、そうした
- まさーるのページ
石井 勝 masarl@nifty.com まさーるのページにようこそ！ このサイトでは，オブジェクト指向やプログラミングの話題を扱っています．書いていることはXPやデザインパターンなどですが，最終的には，どうすればSEが行っている作業を面白くし，仕事を楽にできるか，ということを目指しています．それでは，どうぞ． [プロフィール] [リンク集] [編集後記] [Cotton Bolls] What's New NUnit Converter ver 1.0.0 ― 2004/07/04 Contents Eclipse Quick JUnitプラグイン (2003/12/23) Eclipse上でJUnitの起動，テストコードと実装コード間のエディタ切り替えを簡単に行うためのプラグインです． JUnit Diffプラグイン (2003/12/23) JUnitが出力するエラーメッセージのd
BPStudy#151〜オブジェクト指向、モデリング、設計 LT大会[リモート開催] - 資料一覧 - connpass
2020年3月30日(月)に開催されたBPStudy#151〜オブジェクト指向、モデリング、設計 LT大会( ) のまとめです。 Read more >>
![BPStudy#151〜オブジェクト指向、モデリング、設計 LT大会[リモート開催] - 資料一覧 - connpass](https://cdn-ak-scissors.b.st-hatena.com/image/square/e8a3269a3d2c237b3f9cdf1e21050270a5e920de/height=288;version=1;width=512/https%3A%2F%2Fimg.logmi.jp%2Farticle_images%2FPF7bBRWj5P2pv5mRZGFNeL.jpg)
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ
YAPCでおもしろ発表してきた - hitode909の日記
YAPCでおもしろ発表してきた． はてなブログの開発を振り返って設計の進化と最高の設計を紹介するという話． speakerdeck.com なぜか大人気発表みたいになってて，会場満員で，すみませんこんなところに来ていただいてすみませんというかんじだった． 紹介した本はこちら．予約投稿で仕込んであって，発表終わったら，こちらから買ってくださいとかやろうと思ってたけど，すっかり忘れてた． YAPCの発表で紹介した本 - hitode909の日記 質問たくさんいただいて，よいかんじにおさまったと思う． 「難しくて挫折するという問題がありますよね」「歯を食い縛って実装しろって書いてあった」 #yapcasiaE— そらは (@sora_h) 2015, 8月 21 Q: 「コメントの良い書き方は？」 A: 「オブジェクト指向入門下巻に書いてあります」 ↓ 「買って読みます。」 #yapcasiaE
オ・ト・ナのカプセル化再入門 - Qiita
よく、初心者向けの教科書に「とりあえずprivateを指定し、必要な物はpublicにしましょう。」と書いてありますが、これは大きな間違いです。 最初にアクセス修飾子を熟知しておかなければ、Java という言語を扱う上で最良の設計を行なうことは難しいでしょう。 そんな教科書は今すぐ窓から投げ捨てるか、ちり紙代わりに使いましょう。 Package パッケージは Java のクラス郡をまとめるための仕組みです。主に利用する目的として、以下の 2 点ががあります。 名前の衝突を避ける事が出来る。 パッケージによるアクセス制御を行なえる。 これらを利用する事で Facade デザインパターンを忠実に実現することができます。 Java のカプセル化においてこの仕組みは必要不可欠でしょう。 Design patterns 次に、ソフトウェア設計において基本的な 2 パターンを紹介します。 Facade
チームとして少ないミスで素早くアプリを継続的・持続的に作り続けるためのメソッド - Qiita
この投稿は DroidKaigi で話そうと思ったけど採択されなかった RejectedKaigi な内容です。 プログラムは、書けば書くほど複雑になります。行数が増え、分岐や繰り返しが増え、メソッドが増え、クラスが増え、パッケージが増え、管理するものは日に日に増えていきます。これらのものを使う側からすると、使うものが増えるということは、それだけ覚えることが増えることになります。勿論、IDE やエディタプラグインによって、そのような労力が極力減らされることもありますが、覚えることが少ないに越したことはありません。 この記事では、IDE やエディタプラグインはひとまず脇に置き、チームでコミュニケーションを取りながらコードを書くという観点で、従来のプログラミングのプラクティスを基に、開発時のミスを少なくし、チームで素早くアプリを作り続けていく方法論を深めていこうと思います。 Agenda 型を
Python の super() 関数の使い方
Python でスーパークラスのインスタンスメソッドを呼び出すときに使える super() 関数の使い方をご紹介します。 Python 3 の場合 まずは例を見てください。 class Dog: def __init__(self, name): self.name = name class UltraDog(Dog): def __init__(self, name, type_): super().__init__(name) self.type = type_ ud1 = UltraDog("taro", "akita") print(ud1.name) このコードでは、 Dog のサブクラス UltraDog の __init__() メソッドの中で super().__init__(name) という書き方を使ってスーパークラス Dog の __init__() メソッドを呼び出
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
数理科学的バグ撲滅方法論のすすめ 第4回 関数型言語とオブジェクト指向，およびOCamlの"O"について
関数型言語とオブジェクト指向は相容れない，という説をよく聞く。たしかに「オブジェクトは状態を持つ」「関数型プログラミングでは，できるだけ破壊的代入を行わない」とすれば，二つの概念は矛盾しているようにも思われる。また，技術的観点以外にも，「とかくシンプルさを好む多くの関数型言語プログラマが，何かと物事を複雑にする（と思われている）オブジェクト指向を嫌っている」という面があるかもしれない。 しかし，個人の好き嫌いはさておき，実際問題として，関数型言語とオブジェクト指向は大いに関係がある。むしろ，基礎理論については，ほとんど同じコミュニティの人たちが取り組んでいる，と言ってもいい。例えば，以下のような研究が，1980年代から現在に至るまで行われている。 関数型言語のモデルであるλ計算という体系において，オブジェクトを表現する研究（参考リンクなど） λ計算にならい，（プロトタイプベースの）オブジェ
そのオブジェクト指向入門は間違っている（大げさ） - Webアプリエンジニア養成読本 AdventCalendar2014 25日目最終日！ - uzullaがブログ
はい、Webアプリエンジニア養成読本 AdventCalendar2014です。突然トリをやる事になってしまったので、どうしたもんかとおもいます…。 「最終日だぞ…ちゃんとかかないといけない…しかしネタはない…そうだリンク集を作ろう！」とか思ったんですが、そもそもアドベントカレンダーってリンク集だよねって気付いて愕然としているクリスマスの夜です。現在朝の4時、これを書き終えて寝たい。 さて…何を話そう ここまでWebアプリエンジニア養成読本アドベントカレンダーということで続けてきました。そして今日は25日、ついに最終日です！ Webアプリエンジニア養成読本 Advent Calendar 2014 - Qiita Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus) 作者:和田 裕介,石田 絢一 (uz
権限管理を実装するときの地味な話 - ✘╹◡╹✘
「あるユーザがXをYできるかどうか」というメソッドを定義したいとき、Userに実装するよりも、Xに実装した方がうまくいくことが多かった。例えば「ユーザが投稿を編集できるか」という、ブログの共同編集のような機能で使うやつで考える。つまり、User#can_edit?(entry) みたいなやつにするか Entry#editable_by?(user) みたいなやつにするかという話になる。 後者の方でうまくいった理由は、Webアプリだとログイン中のユーザが存在しない場合というのがあるが、後者ではuserがnilの場合でも対応できたというのと、Userクラスが長大にならなかったという点 (Abilityクラスとかを全ての場所で統一して使えている場合はそれで良いので各自適当にやっていってほしい)。あとメソッドの命名規則の問題があって、名詞形 (例:User#name) か、xxx?で終わるメソッド
（あなたの周りでも見かけるかもしれない）インスタンス変数の間違った使い方 - Qiita
（2021-8-28追記） この記事の改訂版を書いてみました。改訂版の方が易しい内容になっているので、プログラミング初心者の方はこちらを参考にしてみてください。 はじめに：「引数があるよりは、ない方が良い」？ 先日、同僚の西見さん（@mah_lab）がこんな技術ブログを書いていました。 インスタンスメソッドとクラスメソッドはどのようにして使い分けるべきか？（Rubyの場合） 同じ内容を僕だったらどういうふうに書くかな～？と思って、ちょっと書き始めてみたんですが、わかりやすく実践的な説明をするのは意外と難しく、内容も西見さんのブログとほぼ同じになりそうだったので、途中で断念しました。 というわけで、インスタンスメソッドとクラスメソッドの使い分けが未だにあやふやだという方は、ぜひ西見さんのブログを読んでみてください！ ・・・なんですが、1点だけ気になる点がありました。 それはインスタンスメソッ
getter/setterとはなんだったのか - プログラマーの脳みそ
Javaのgetter/setterのお話。 僕は当時を語るには若すぎるのだけど、過去を振り返って書いてみる。当時を知る人は誤りがあれば指摘してほしいし、情報があればコメントなりトラックバックなりして欲しい。前世紀の話というのは今となっては探すことがなかなか難しくなりつつある。 「privateな変数にpublicなアクセサを定義する」？ - ネットの海の片隅で getter/setterとは何か Javaのオブジェクトにフィールドがあったとして、そのフィールドに値を設定するメソッドがsetter(せったー)、そのフィールドの値を取得するメソッドがgetter(げったー)と呼ばれる。慣習としてsetterはsetXXX(int value)といった様にsetから始まる名前をつけ、引数はひとつ。戻り値はvoid型。getterはgetXXX()といった様にgetから始まる名前をつけ、引数はな
「オブジェクト指向の価値ってよく分からないですよね」について - manie's blog
そういえばCORBAとかROSEとかUMLとかやってた気がします。 プログラミング勉強中の人にオブジェクト指向とは何なのかを何となく伝えたい話 - かまずにまるのみ。 「オブジェクト指向の価値ってよく分からないですよね。」 誕生の歴史を知ればよい。環境によっては価値がある。 コンピュータは情報数学と電子回路から誕生した。電子回路は半導体によってハードウェアからソフトウェアとなり、機械語（そしてアセンブリ言語）が必要になった。C言語はアセンブリ言語に配列と構造体を加えたものだ。手続型言語ではデータ構造とアルゴリズムを同時に設計するが別々の保守が必要だった。保守は同時にやるべきだ。データ構造とアルゴリズムを同時に同じ場所で実装し保守出来る仕組みがクラスだ。 情報数学と電子回路 情報数学は乱暴に言えばビット演算学だ。NOTとORとANDを使ってあらゆる命題論理を電子回路で置き換え可能な式に書き下
再考: GoF デザインパターン - Qiita
本投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 本が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代にカタログ化された 現代のプログラミングと合致しないものが多い 「オブジェクト指向における～」と断っている以上、OOPに絡める必要があった パターンのいくつかに「多態性を用いると便利」という蛇足がついている 挙げたパターンに根拠がない 「とりあえず、23個ほ
- 石井勝さん追悼
このたびの尼崎の事故には、私も大変お世話になった石井勝さんが 含まれていた、ということを、昨日友人からのメールで知らされました。 石井さんは、masarlさん、というハンドル（ニックネーム）で知られ、 日本のオブジェクト指向界で、数多くの功績を残されています。 石井さんの遺されたコンテンツは、御友人の森さんのサイトに保存されています。 特に、Robert C. Martinのオブジェクト指向の原則を、彼自身の本に 先立って C++ Report 誌の記事からまとめたり、Bertrand Meyer のOCP(開放閉鎖原則) を使ってデザインパターンの本質を見極めたり、さらに、Kent Beck の JUnit Testing Framework の内部構造を紹介したり、という記事を 1999 年という非常に 早い時期に行っています。まさに、日本のOOのアンテナであるとともに、その 分かりや
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
- Niftyの過去ログ集 - むすんでひらいての法則
Amazon.co.jp: オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES): アラン・シャロウェイ (著), ジェームズ・R・トロット (著), 村上雅章 (翻訳): 本
