私が講師をさせていただく、技術講座のご案内です。
2月23日(土)14:30−17:30
東京・品川 楽天タワー2号館
5000円
お申し込みはこちらから。
オブジェクト設計エクササイズ
この講座は、実務経験が3年程度ある技術者で、
● プログラミングはだいぶ覚えたが、設計といわれると自信がない
● ある程度、設計はできているつもりだが、不安
という方むけに「実務で役に立つ」オブジェクト設計の考え方・やり方を知ってもらおう、という講座です。
Java, C#, Rubyなどは「オブジェクト指向」のプログラミングも「できる」言語です。
いっぽう「手続き型」だけで書けちゃう言語でもあります。
業務アプリケーションの開発で、Java は相当使われている言語です。
しかし、多くのコードは手続き型の考え方と習慣で書かれているようです。
そういう手続き型があたりまえの環境で育ってしまうと「オブジェクト」を設計するという発想やスキルを身につける機会がないのが実情だと思います。
この講座は、若手の技術者のみなさんに、「オブジェクトを設計する」という発想と、実際の設計のやり方に触れてもらい、現場に持ち帰って役立ててもらおう、という主旨で開催します。
講座の内容は、日常のプログラミングの時に、ちょっと気にするだけで、みちがえるようにオブジェクトの設計力がアップしていく魔法のような(笑)テクニックの紹介です。
設計に唯一の正解はありません。
いろいろな考え方・やり方があります。
実務で役に立つ設計力とは、いろいろな設計の考え方・やり方を、必要に応じて適切に、使い分けたり、ミックスする力です。
この講座で説明する設計力アップのテクニックは、最初は奇妙に見える以下のルールを使ったプログラミングの実践のススメです。
1.ひとつのメソッドのインデントはひとつまで
2.else 句は使わない
3.すべてのプリミティブ型と文字列型はラッピングする
4.ファーストクラスコレクションを使う
5.1行につきドットは1つまで
6.名前は省略しない
7.クラス50行以内、メソッド3行以内
8.1クラスにインスタンス変数は2つまで
9.getter/setter は使わない
手続き型の発想だと、これらのルールは不思議、あるいは悪い書き方かもしれません。
でもオブジェクトの設計力のスキルアップには、効果絶大の練習方法なんです。
講座では、
● そもそもどういう意味?
● なぜこのルールでプログラミングするとオブジェクトの設計力があがるの?
●(ルールはわかるけど)こういう時は具体的にどうすればいいの?
というあたりをサンプルコードを見ながら、具体的に説明します。
Q&Aの時間もたっぷりとります。
この9つのルールは、コミュニティの勉強会でなんどかお話をさせていただきました。
スライドも公開しています。
オブジェクト指向の設計と実装の学び方のコツ
おおむね良い評価をいただけたと思っていますが、極端すぎるとか、現場では無理、非現実的、というフィードバックもそれなりの数がありました。
「これがオブジェクト指向だというなら、私はオブジェクト指向をやっていないし、やる気もない」というように(言外に)これは「にせもの」のオブジェクト指向である、という意見の方もいらっしゃいます。
オブジェクト指向に一つの明確な定義があるわけではないので、私は、それもオブジェクト指向、これもオブジェクト指向、という感じで受け止めていますが、「極端」であることは、その通りだと思います。
意識的に極端にして、ある「意図」を伝えようとしているルールだからです。
このルールの背景にある考え方は、次の2点に集約できます。
◎ 名前たいせつ
◎ 小さいほうが扱いやすい
この2点は、総論としてなら、みなさん賛成いただけると思います。
でも現場で実際にプログラミングするとなると、
● 名前をいちいち考えているのはたいへん
● 小さく分割しすぎると、見通しが悪くなり、かえってわかりにくくなる
という意見が多くなってきます。
この現場感覚が、実は「手続き型」プログラミングの発想や習慣に、知らないうちに、しばられている。
この手続き型の発想や習慣とは「異なる」発想である「オブジェクト」の発想や習慣を知ることで、設計力が格段にアップしますよ。
これがこの講座の狙いなんです。
「手続き型」の発想や習慣を捨てる必要はありません。
そうではなくて「手続き型」とは別の「オブジェクト」の発想や習慣を増やしていけば、設計力が格段にアップしますよ、ということなんです。
今回の講座では、キーワードとして「オブジェクト」にフォーカスしていますが、「関数型」の発想や習慣も、設計力アップにとても役に立ちます。
また講座の中では「宣言型」とか「論理型」という言葉そのものは使いませんが、そういう考え方を隠し味として使っています。
そうやって考え方の幅を広げることが「設計力アップ」のコツなんです。
私としては5000円は破格の安値だと思っています(笑)。
でも払う側からすれば「5000円払って、休日つぶすだけの価値があるのか?」と思うのが普通の感覚ですよね。
価値がありそうかどうかは、このブログの過去記事や、公開しているスライド を参考にご判断いただければと思います。
<補足>
ブログ過去記事で「関数型プログラミングってエクセル方眼紙だよね」は、しょうもないネタ記事です。まじめに受け止めないでください。
それ以外のエントリは、まじめに書いている(つもり)。
2月23日(土)14:30−17:30
東京・品川 楽天タワー2号館
5000円
お申し込みはこちらから。
オブジェクト設計エクササイズ
この講座は、実務経験が3年程度ある技術者で、
● プログラミングはだいぶ覚えたが、設計といわれると自信がない
● ある程度、設計はできているつもりだが、不安
という方むけに「実務で役に立つ」オブジェクト設計の考え方・やり方を知ってもらおう、という講座です。
その設計は手続き指向では?
Java, C#, Rubyなどは「オブジェクト指向」のプログラミングも「できる」言語です。
いっぽう「手続き型」だけで書けちゃう言語でもあります。
業務アプリケーションの開発で、Java は相当使われている言語です。
しかし、多くのコードは手続き型の考え方と習慣で書かれているようです。
そういう手続き型があたりまえの環境で育ってしまうと「オブジェクト」を設計するという発想やスキルを身につける機会がないのが実情だと思います。
この講座は、若手の技術者のみなさんに、「オブジェクトを設計する」という発想と、実際の設計のやり方に触れてもらい、現場に持ち帰って役立ててもらおう、という主旨で開催します。
現場で生かせるオブジェクト設計力
講座の内容は、日常のプログラミングの時に、ちょっと気にするだけで、みちがえるようにオブジェクトの設計力がアップしていく魔法のような(笑)テクニックの紹介です。
設計に唯一の正解はありません。
いろいろな考え方・やり方があります。
実務で役に立つ設計力とは、いろいろな設計の考え方・やり方を、必要に応じて適切に、使い分けたり、ミックスする力です。
この講座で説明する設計力アップのテクニックは、最初は奇妙に見える以下のルールを使ったプログラミングの実践のススメです。
1.ひとつのメソッドのインデントはひとつまで
2.else 句は使わない
3.すべてのプリミティブ型と文字列型はラッピングする
4.ファーストクラスコレクションを使う
5.1行につきドットは1つまで
6.名前は省略しない
7.クラス50行以内、メソッド3行以内
8.1クラスにインスタンス変数は2つまで
9.getter/setter は使わない
手続き型の発想だと、これらのルールは不思議、あるいは悪い書き方かもしれません。
でもオブジェクトの設計力のスキルアップには、効果絶大の練習方法なんです。
講座では、
● そもそもどういう意味?
● なぜこのルールでプログラミングするとオブジェクトの設計力があがるの?
●(ルールはわかるけど)こういう時は具体的にどうすればいいの?
というあたりをサンプルコードを見ながら、具体的に説明します。
Q&Aの時間もたっぷりとります。
極端すぎるのでは?
この9つのルールは、コミュニティの勉強会でなんどかお話をさせていただきました。
スライドも公開しています。
オブジェクト指向の設計と実装の学び方のコツ
おおむね良い評価をいただけたと思っていますが、極端すぎるとか、現場では無理、非現実的、というフィードバックもそれなりの数がありました。
「これがオブジェクト指向だというなら、私はオブジェクト指向をやっていないし、やる気もない」というように(言外に)これは「にせもの」のオブジェクト指向である、という意見の方もいらっしゃいます。
オブジェクト指向に一つの明確な定義があるわけではないので、私は、それもオブジェクト指向、これもオブジェクト指向、という感じで受け止めていますが、「極端」であることは、その通りだと思います。
意識的に極端にして、ある「意図」を伝えようとしているルールだからです。
ルールの意図
このルールの背景にある考え方は、次の2点に集約できます。
◎ 名前たいせつ
◎ 小さいほうが扱いやすい
この2点は、総論としてなら、みなさん賛成いただけると思います。
でも現場で実際にプログラミングするとなると、
● 名前をいちいち考えているのはたいへん
● 小さく分割しすぎると、見通しが悪くなり、かえってわかりにくくなる
という意見が多くなってきます。
この現場感覚が、実は「手続き型」プログラミングの発想や習慣に、知らないうちに、しばられている。
この手続き型の発想や習慣とは「異なる」発想である「オブジェクト」の発想や習慣を知ることで、設計力が格段にアップしますよ。
これがこの講座の狙いなんです。
「手続き型」の発想や習慣を捨てる必要はありません。
そうではなくて「手続き型」とは別の「オブジェクト」の発想や習慣を増やしていけば、設計力が格段にアップしますよ、ということなんです。
今回の講座では、キーワードとして「オブジェクト」にフォーカスしていますが、「関数型」の発想や習慣も、設計力アップにとても役に立ちます。
また講座の中では「宣言型」とか「論理型」という言葉そのものは使いませんが、そういう考え方を隠し味として使っています。
そうやって考え方の幅を広げることが「設計力アップ」のコツなんです。
高い?
私としては5000円は破格の安値だと思っています(笑)。
でも払う側からすれば「5000円払って、休日つぶすだけの価値があるのか?」と思うのが普通の感覚ですよね。
価値がありそうかどうかは、このブログの過去記事や、公開しているスライド を参考にご判断いただければと思います。
<補足>
ブログ過去記事で「関数型プログラミングってエクセル方眼紙だよね」は、しょうもないネタ記事です。まじめに受け止めないでください。
それ以外のエントリは、まじめに書いている(つもり)。