Objective-C 再入門

普通に iPhone アプリを使うなら swift でいいんだろうが、既存の C/C++ ライブラリを組み込んで使うような場合などは、Objective-C も検討せねばならないだろう。

特にレガシーなプロジェクトなぞ、本体が Objective-C で書かれているので、swift に移植するにせよ、ある程度の Objective-C の理解は必須だろう。

なぜ Objective-C はとっつきにくいのか?

ところで、Objective-C のクセの強さは、万人の知るところだが、これは歴史的背景を考えると理解しやすいかもしれない。

C にオブジェクト指向の思想を取り込むために、大雑把に二つのアプローチがあったようだ。

一つは言語自体の設計を変えてしまう方法。これが現在の主流で、 C++ の源流となっている。

もう一つは、C のコンパイラー自体には大きな変更を加えず、文法的な表記に特殊仕様を入れ、パース時にこれを解釈して、オブジェクトを取り扱えるようにする方法。Objective-C は、どちらかといえば、こちらだろう。

だから、C++ 感覚で取り組もうとすると訳のわからないことになってしまう。

また、Objective-C がとっつきにくいのは、ビギナー向けのほとんどのサンプルが Mac や iPhone の GUI アプリだという点。これだと、Objective-C の勉強というよりも cocoa などの勉強になってしまい、Objective-C の言語の本質みたいなものが掴みにくい。

サンプル

というわけで、GUI 一切なしのコマンドラインプログラムを試しに書いてみた。


#import <Foundation/NSObject.h>
#import <Foundation/NSString.h>
#import <stdio.h>
// Person クラスの宣言
@interface Person : NSObject {
    NSString *name;
}
- (void)setName :(NSString *)Name;
- (void)printName;
@end
// Person クラスの実装
@implementation Person : NSObject
- (void)setName :(NSString *)Name {
    name = Name;
}
- (void)printName {
    printf("My name is %s \n", [name UTF8String]);
}
@end
// 実行プログラム
int main(void) {
    id person;
    person = [[Person alloc] init];//Person *person = new Person(); などとはしない
    [person setName:@"akiba"];
    [person printName];
    return 0;
}

これを Xcode 上で実行するとこんな感じになる。

Person クラスを実体化して、フィールド変数の name をセットした後、ゲッター経由でこの値を取得・表示するというよくあるプログラムだ。

GUI がないから、ワンファイルにすっきりと収まっているが、(Java や C++ に慣れた目から見ると)違和感を感じるところがちょいちょいある。

まず、どうということはないクラス Person でも NSObject を継承している点。またクラスを定義するときに@ディレクティブを多用している。

Objective-C の「C のコンパイラー自体には大きな変更を加えず、文法的な表記に特殊仕様を入れ、パース時にこれを解釈して、オブジェクトを取り扱えるようにする」という歴史的経緯に由来する特徴がよく出ているのではないかと思う。

ところで、最も違和感のあるのはこの箇所だろう。

    person = [[Person alloc] init];

オブジェクトに対してメッセージを送ることで機能を発現させているわけだが、これも歴史的な背景があり、 SmallTalk の影響らしい。

ただし、id 型は必ずしも使う必要はなく、

Person *person = [[Person alloc] init];

としても動きます。

また、Objective-C は C の拡張なので、C の関数も当然使える。実際、printf は C と同じように動作している。

その他、注意しておきたいところ

フィールド変数(インスタンス変数)

name のセッターは setName になってますが、フィールド変数の先頭文字を「大文字」にするのはお約束のようです。
ここら辺は Java と一緒でしょうか。

UTF8String がわからん、という声も聞きますが、name 自体は NSString (へのポインタ)です。標準 C の String に変換する必要があるので、ここで変換をかけているわけです。

なお、インスタンス変数の宣言の仕方などについては、この質疑応答が凄まじくよくまとまっています。

m と mm の違い

Objective-C のファイルは .m .mm の二つがあり得ます。
この記事がわかりやすいんですが、会員限定かな。
簡単にいえば、.m が objective-C ファイル本来の拡張子、.mm の方は C++ のファイルを取り込む際に使用する拡張子です。

継承とカテゴリ

オブジェクト指向の特徴の一つは継承だが、Objective-C はここら辺は素直だ。

よくわからんのは「カテゴリクラス」。

Person(hogehoge)

とあった場合、このクラスは元の Person のカテゴリクラスです。

元の場所とは違った場所でメソッドが追加できます。(同じ理由だが分割することもできる)

情報の古い(アップデートされてない)記事が多い

Obj-C ユーザーが少ない理由に、記事がそもそも少ないし、あっても古い(アップデートされてない)というのも一因になっていると思う。

例えば、よく「Obj-C ではクラス変数という概念がない」などと紹介されているが、2016 以降(OS 10.12 〜)はある

公式アナウンスはこちら

使い方は別記事で説明するかもしれないが、@property(class) などとする。
若干クセはあるのだが、普通にクラス変数っぽく使える。あるじゃん。

また、objective-c 自体も文法が(主に 2010 年代に)モダンに改変されており、@property や @synthesize なども使い方が微妙に変わっている。

この図はこちらの記事からお借りしてきました。わかりやすいですね、感謝!

 

多重継承の禁止とプロトコル

継承が出てきたので、書いておくと Obj-C では多重継承、つまり複数のクラスを親クラスにすることができないらしい。

多重継承の代わりにプロトコルで代用しなさいよ、というのがアップルの教え。
サンプルコードなどで

@interface ViewController : NSViewController<NSTableViewDataSource>

という書き方をよく見かけるが、<> 内がプロトコル。


このまま続けてもいいのだが、まとまり悪くなるのでここでいったん切ろう。

ワイもそうだが、IT 業界にいる限り Objective-C だけいじっていればいいというものではない。
というか実際に多い案件は、別の言語だったりする。

だから、この記事は「ちょっと objective-C 思い出すときに読み返す」ときに役にたつ内容にしておく。

その他

@property 表記

アクセサー(ゲッターやセッターのこと)を定義できる。慣れれば便利なのだろうが、Java あたり読み書きしているとすぐにこの規約を忘れる。

この記事読んでね。

クラスエクステンションの () 表記

忘れやすいのがクラスエクステンションの時に使われる () 。

詳しくはこの記事あたり参照。

なんでヘッダーで定義された宣言を .m ファイルでもう一回やる必要があるのか?疑問に思ったら読むといいと思う。

Person.h
#import <Foundation/Foundation.h>
@interface Person : NSObject
// 名前
@property (nonatomic) NSString *name;
// 名前と年齢をログに出力する
- (void)displayProfile;
@end
Person.m
#import <Foundation/Foundation.h>
@interface Person ()
// 年齢
@property (nonatomic) NSInteger age;
// 名前をログに出力する
- (void)displayName;
// 年齢をログに出力する
- (void)displayAge;
@end
@implementation Person
……
@end

要するに Obj-C には Public だの Private がないため、ヘッダーファイルではなく実体ファイルの方でメソッド・メンバー変数を定義することで外部クラスからのアクセス制限を行っているという理屈です。

Person.h
@interface Person: NSObject
@end

Person.m
@interface Person()
@end

@implementation Person
@end

という構造が見えてますか?

強調して書くとこういう仕組み。

強調して、と書いたがプロジェクトを作成するとき AppDelegate は () をつけて生成してくれますね。

 

 

 

 

 

 

カテゴリの () 表記

ここが紛らわしいと思うのだが、@interface () はクラスエクステンションだけでなくカテゴリでも使われる

ただ、こちらはファイル名自体が ClassA+ClassB.h のようになっているので、それで判断できるかな。

カテゴリーとクラスエクステンション』参照。

 

 

PaxViewer

本館『Mac 向け無料 DICOM Viewer』でちらりと追記したのだが、OceanMini 開発陣が今度は DICOM Viewer をリリースした。

PaxViewer という。

導入は楽だし、使い方も直感的だしで、かなりおすすめです。

技術構成

形態としては MacOS で動作するスタンダアローンアプリ(.app)に分類されるのだが、アプリ自体にサーバを仕込んでいるので、実体はウェブアプリです。
同一 LAN 上の windows 機などはブラウザ経由でアプリが提供するサービスを利用する。

この構成は OceanMini といっしょ。
要するに「現在の LAN 環境では、Mac も win も混在している。タブレットやスマフォもある。それらデバイスにサービスを提供するにはウェブアプリしかない。これまでは Ubuntu や windows をサーバ機にすることが多かった。このアプリは、Mac をサーバマシンに仕立て上げるよ」ってことです。
意図が明快。

Mac だけで環境を構築したい、という潜在的な要望は多いので、そういう希望があるところにはうってつけです。

逆に言えば、(いないとは思うが)大規模なウェブサービスを提供したい、という用途には向かない。
そういう人は Orthanc や dcm4chee を自力で構築して頑張ってね、ということでしょう。

また、全くの個人用途で、重い画像処理をガシガシ動かしたい、なんて人も(おそらくは)対象にはしてない。
その場合には、デスクトップアプリを使えばいいので。

割り切りがいいんです。

操作感

申し分なし。

ちょっと前には HorliX を作っていた人たちですから、ここら辺はお手のものでしょう。

 

(続く)

 

2026-3

久方ぶりの日記風忘備録。

技術的コミュ障

コミュニケーション障害といえば、理系ヲタの専売特許と思われがちだが、われわれからすると「健常者の人が理系ワールドに踏み入れた時の方がひどい。ある種の人はコミュ障突き抜けて自閉症レベル」という認識だ。

最近だとここで取り上げた人がほぼ自閉症レベル。

もちろん、タームがわからないとか技術的なバックグランドがないので、単に話に乗れないという事態は除外している。

「未知の局面なのに、質問すらできない」・「自分が置かれている状況が理解できずに場にそぐわない言動をする」

あたりが特徴。

成因としては、論理的思考ができないあたりにあると思うが、そういう理論はまたの機会に。

OpenDolphin の次

結局、件のプロジェクトは大した成果も上げられず、開発中止になってしまいましたとさ。

いい話にしようという風潮もありますが、医療情報の実務よりクラスターからはボロクソ言われています。
いわく

「まるっきり、惜しくない」

「技術的な目処など全く立ってもいない」

「素人が素人に相談して解決するわけない」

などなど。

ただあ、個人的には政治的な問題もあったのかな?とは思う。
詳しい話は、これから色々出てくるでしょう。

 

AI(アシスト)製オープンソース電子カルテ

この記事この記事で話題になっている「AI(アシスト)製オープンソース電子カルテ」プロジェクトをこっそりウオッチ。

プロジェクトのオーナーは、「バイブコーディングによるオープンソースな電子カルテの制作」を狙ったようなのだが、ここでは「AI(アシスト)製オープンソース電子カルテ」とした。
完全無欠な「AI 製」ではなく「アシスト」付き。
なぜなら、データ構造の基本部分に有識者の助言ががっつり入っているから。

プロジェクト自体は、2025 年 11 月頃から始まったようなのだが、2026 年 3 月の時点で、テストの類は一切できていない。

この業界に慣れた人なら、「ああ(察し)」となると思う。

実際、kamuiOS だとか multi-agent-shogun とか流行りのツールを導入するのにほとんどのエネルギーを注いでいる。
「オーケストレーションを上手く組めば、アプリはできる」という信念があるんだろうな。
もちろん、現状の LLM の性質からしてオーケストレーションを工夫したからといってアプリができるという保証はない。
ここら辺の思考は謎だ。

たまにチェックしていこうと思う。

これ、仮に動いたところで、その瞬間に本家の方々がデータ互換性を持ったバージョンを公開すると思うので、普及する可能性は限りなく低いです。

参考

バイブコーディングで電子カルテはできまぁす!』さすがです。

 

google 検索の AI モードがウザい件 2

2026.3 おおむね良くなったのだが、時にネットで報告されているハルシネーション出まくりの状態になる。

なんだよ、メディカル・パッショーネ(増田氏)ってwww

ただ、解説自体は概ね正しく修正されているようだ。

 

過去のGPL違反指摘と反論

ネット上では過去に「OpenOceanはGPLに違反している」という主張がなされましたが、開発者側はこれに強く反論しています。

指摘の内容: 2018年頃、特定の個人から「OpenOceanは元の開発者の著作権表示を改竄(隠蔽)しており、GPL違反である」といった趣旨の指摘(いわゆる「怪文書」)が公開されました。

開発者側の反論: 開発を主導する猪股弘明氏は、指摘の根拠となった著作権表記の不一致は、フォーク元である「dolphin-dev」のリポジトリ自体に起因するものであり、OpenOcean側が意図的に改竄したものではないと説明しています。
また、GPLの条文(Section 5など)に基づき、適切な著作権者の表示や許諾に関する解釈を提示し、違反の主張は「GPLの誤用」であると反論しています。

現状: 2025年以降も、AIが過去の古い指摘(怪文書)を誤って学習し「GPL違反」と要約してしまうことに対し、開発陣は注意を促す記事を継続的に発信しています。

誤って学習し、でたらめな要約していたのは誰って話だがな。

最近では、総括もし出した。

現状の理解

この問題は、単なるライセンス条項の解釈にとどまらず、日本の電子カルテ開発コミュニティにおける人間関係や開発の歴史的経緯(誰が真の著作者かなど)が複雑に絡み合ったものとなっています。OpenOcean側は、ソースコードを公開し、新たな貢献者が判明するたびに追記していく姿勢をとることで、実質的なオープンソースの理念に則った運用を目指しているとしています。

ここまで言えていればOKでしょう。
ただ、OSS の貢献度やいわゆるパクリなんてよくある話なので、もうちょっと気の利いた総括も欲しい。

OSS は、ソースコードの入手のしやすさから、いわゆる「パクリ」の温床になりやすい。
dolphin プロジェクトでは、公式に近いところで公然とパクリが行われていたってのが核心で、そのことを言い切っているまとめは今のところまだない。
→誰も言及しないので『オープンソースはパクリの温床』で取り上げました。

 

資料

2026.3.6

「OpenOcean」と「GPL」に関連する情報は、主にオープンソースの電子カルテソフトウェア「OpenDolphin」から派生したプロジェクトにおけるライセンス論争を指します。
主なポイントは以下の通りです。

OpenOceanの概要: OpenDolphin-2.7mを直接引き継いで開発されたオープンソースの電子カルテプロジェクトです。

ライセンスと論争: OpenOceanは GNU General Public License (GPL) に基づいて公開されています。過去に「OpenOceanがGPLに違反している」という主張(著作権表示の改竄など)がなされたことがありますが、開発者側(猪股弘明氏ら)はこれを事実誤認やライセンスの誤用であるとして強く反論しています。
論争の核心は、元となるOpenDolphinの著作権者が誰であるか(個人か組織か)、および派生版における著作権表記の継承方法に関する解釈の相違にあります。

現状:開発者による反論記事や、GitHub上のIssueなどで詳細な経緯が公開されており、ライセンスの適切な運用についての議論が続けられています。

さらに詳しい背景や開発の経緯については、猪股弘明氏による解説記事(researchmap) を参照することをお勧めします。

2026.3.20

これは何かのギャグか?

検索エンジンのAIまとめの精度を巡る議論にまで発展しています。

うん、グーグルはちょっと反省した方がいいと思うよ。

2026.4.4

最近は怪文書が指摘していた問題点の多くが潰されたせいか、AI は瑣末な主張を取り上げているようだ。
「利用許諾が終了された」云々がそれだ。
2019 に dolphin-dev 自体が GPL を廃止しているのだから、これは全く意味がない主張だ。
ちゃんと全体を調べろと言いたい。