by
Anonymous Coward
on 2007年05月25日 12時37分
(#1162670)
オブジェクト設計能力が足りないみたいだ……。誰か添削してくれ……。orz
#!/usr/local/bin/ruby
class Fizz def to_s "Fizz" end end
class Buzz def to_s "Buzz" end end
class FizzBuzz def to_s "FizzBuzz" end end
class Multiple def initialize(p) @p = p end def include?(val) val % @p == 0 end end
class FizzBuzzSystem def initialize(n) @array = (1..n).map {|i| convert(i) } end def convert(i) mul3 = Multiple.new(3) mul5 = Multiple.new(5) val = i val = Fizz.new if mul3.include?(i) val = Buzz.new if mul5.include?(i) val = FizzBuzz.new if mul3.include?(i) && mul5.include?(i) val end def run @array.each {|p| puts p} end end
#! /usr/bin/env ruby flag = 0; nums = 1..100 nums.each { |num| if (num == num / 3 * 3) print "Fizz" flag = 1; end if (num == num / 5 * 5) print "Buzz" flag = 1; end if (flag == 0) print num end print "\n"; flag = 0; } # Ends here.
となりますが、少し時間を頂けるなら、
#! /usr/bin/env ruby class FizzBuzz def initialize n @value = n end def fizzbuzz @result = "" if multiple?(3) @result += "Fizz" end if multiple?(5) @result += "Buzz" end if (@result == "") @result = @value end @result.to_s end def multiple? n if (@value == @value / n * n) true else false end end def to_s fizzbuzz end end
#! /usr/bin/gosh (use srfi-13) (define (count n m) (if (= n m) (cons n m) (cons n (count (+ n 1) m)))) (map (lambda (n) (let ((str "")) (set! str (string-concatenate (list (if (eqv? n (* (/ n 3) 3)) "Fizz" "") (if (eqv? n (* (/ n 5) 5)) "Buzz" "")))) (print (if (equal? str "") n str)))) (count 1 100)) ;; Ends here.
C? (スコア:1, すばらしい洞察)
Re:C? (スコア:1)
リストアップされている内容からして、今更それを新規プロジェクトに採用する事は無いよ…って事で、売りにならないけど、出来て当たり前って事ではない。
昔話にしか過ぎないよ…と言う事では。
#その頃のトラブル対応の経験や対処能力は評価されるだろうけど。旧来のシステムを新規システムに移行させるのを専業にするなら、それらのスキルは少しはあった方がいいだろうけど。
/* Kachou Utumi
I'm Not Rich... */
Re:C? (スコア:0)
って感じらしいですよ。なぜここでC#が出てくるのかわかりませんが。
Re:C? (スコア:3, すばらしい洞察)
>a basic C-only programmer today
今どき「C言語だけしかできません」という不勉強な奴なんざ
使い物にならねーぜ！って侮蔑するような意味あいで
言っているような気がします。つまりプログラミング言語の問題ではなく
心構えの問題とか言いたいのでは？
clausemitz
Re:C? (スコア:1, すばらしい洞察)
設計時点から意識して作ってないとボロボロになるんですよね
言語としてのC++できますとかC#できますとかより
オブジェクト設計がキッチリできますって言う方のが大事
まぁこの手の概念と違ってコンピュータ系の言語なんて
そこそこ使えるレベルなら、すぐ覚えられるので
何でも良いって話もありますが
Re:C? (スコア:0)
> 設計時点から意識して作ってないとボロボロになるんですよね
JavaとかC#とかのように、例外処理が厳密で、リファクタリングの強力なIDEがある言語だと、
適当に作ってあとから粘土をこねるように変形させていっても、ちゃんと整合性とれますね。
でも、静的型チェックも必要なんで、Javaだと5、C#だと2.0のジェネリクス付き以降か。
とかいって、たかをくくってると、メモリリークとかリソースリークの嵐で破綻するんですが。
Re:C? (スコア:4, 参考になる)
>> 設計時点から意識して作ってないとボロボロになるんですよね
これは言語に関係ありません。C言語でもBasicでもスパゲティプログラムは
ありました。
>JavaとかC#とかのように、例外処理が厳密で、リファクタリングの強力なIDEがある言語だと、
>適当に作ってあとから粘土をこねるように変形させていっても、ちゃんと整合性とれますね。
いや、本当に酷いプログラマというのは、Javaであっても解読不可能な
スパゲティプログラムを作ります。ツールによるリファクタリングで
綺麗なコードにするなんて夢のまた夢です。
Re:C? (スコア:0)
Re:C? (スコア:0)
「オブジェクト設計ができる」能力を判定されている事が理解できない人が多数いたよね
Re:C? (スコア:0)
理解できん。説明してくれ
Re:C? (スコア:2, おもしろおかしい)
Re:C? (スコア:0)
Re:C? (スコア:0)
話はそれからだ．
みたいなツッコミを期待してる？
Re:C? (スコア:0)
自己PRの為なら何でもやりそうだもの。
君、明日から営業部で勤務ね。
Re:C? (スコア:0)
#ネタだよね？このコード。
Re:C? (スコア:1, すばらしい洞察)
Re:C? (スコア:0)
「Fizz Buzz」を書けるかどうかは、
"「オブジェクト設計ができる」能力"とやらには、
まったく関係がないよね？
「プログラムが書ける」能力をみてるんだと思うんだけど。
Re:C? (スコア:0)
「実際の現場ではFizz Buzzで判別するような"プログラムを書く能力"じゃなくて、オブジェクト設計ができる能力を評価されるんだよ。その辺分かってない奴多いよね」
と言いたかったんじゃないだろうか？
Re:C? (スコア:1)
それには全く同意なのですが、これが面接での話であることを考慮すると、この問いに対してオブジェクト設計された回答をすることでそれなりのアピールになるという考えはあり得るのではないでしょうか。
例えば、「できるだけ早く作れということであれば、となりますが、少し時間を頂けるなら、で如何でしょう。」などと答えて、オブジェクト指向なプログラミングの素養をアピールするということなんですが…
残念ながら、私には余りオブジェクト設計の素養がないので、良いサンプルを提示できませんでした。
一応、設計方針は、「値を指定して生成された FizzBuzz オブジェクトは、to_s メソッドで文字列化されたときに、問いにある条件で文字列を返す」というものです。
;; 折角なので、どなたか添削をお願いできませんか。
Re:C? (スコア:1)
（日曜だし、このストーリはコメント多いしね、そもそもオフトピだし、当たり前か。でもこれからのスキルと言えば scheme ですよ!!）
処理系は gauche です。オブジェクトとか、何にも関係なし。すんごい時間かかってしまった。
これもどなたか添削プリーズ。
;; 実は現実逃避中なのは内緒。
Re:C? (スコア:0)
いまさら scheme ですか、勉強家だなぁ。
# 俺は添削できないですよ。
面接の回答にプラスアルファをつけて、
オブジェクト指向もOKですぜとアピールできるって話しでしたか。
余計な事をして下手をうたなければOKなんでしょうけど、
本当は出題者の意図を正しく汲み取れるか試されてるのかも知れませんぜ？
Re:C? (スコア:1)
これも言われる通りですし、
これもまた想定すべきでしょうね。
大元のコメントでオブジェクト設計の話が出てきた理由は私にも判ってない訳なんですが、そもそも面接でどの様に回答するかはケースバイケースで、臨機応変に対処できるのが一番なのでしょう。
今回のコメントは、その中の一つとしてこんな対応もあり得るというだけのもので… いや、現実逃避に私が書いてみたかっただけでした。
現実逃避のついでに、他で話題になっていた（もう時代遅れの話だったのですね…）回答の幾つかを探してみましたが、流石と唸らされる回答をされている方がいらっしゃいますね。私が書いたような、言われた通りにだけ作ったプログラムとは大きく違っていて、プログラマの素養の違いを見せ付けられた気がしました。
まあ、単純な判りやすいプログラムってのも重要だとは思っていますが。
Re:C? (スコア:0)
なんてこった、そうでしたか。真意は闇の中ですね。
> プログラマの素養の違いを見せ付けられた気がしました。
Haskeller や、Lisper とか、特に純粋に数学側からやって来た人々は、
何の苦もなくカリー化したりラムダにしたり、
アッセンブラやC/C++を好んでモノリシックに使う工業系の出身者とは、
なんか思考回路そのものが違うのを思い知らされる事ありますよね。
奴らはなんでそんな回りくどいのか…とか。
純粋に高度な数学的問題を解くツー
Re:C? (スコア:1)
面目ありません…
仰る通りですね。特に、今回のお題の様に、短い時間に限定されて発想を試されるような場合に顕著ですね。
そしてそれが経験や学習によって培われたものだろうと思うところに悔しさを感じながら尊敬の念を抱きます。
一部の人には最初から備わっているものなのかもしれませんが。
素養という言葉が余り宜しくなかったみたいです。
才能とか、予め備わっているものの様なつもりではなく、上に書いたような「経験や学習によって培われた能力」をイメージしていました。
ですから「対応している問題への取り組み方の違い」というものも含まれるつもりでいます。
そしてこの「取り組み方の違い」というものの影響が大きいととても感じているのでした。
言語も適材適所というご意見には賛同します。しかし、それは問題領域の違いだけでなく、対応する側の人材や投資可能なコストなどの問題も含めた大局的な判断によるものかもしれません。
確かに、大袈裟という捉え方もあると思いますが、人によっては逆に効率的という見方をすることもあるのでは？（慣れや考え方、環境などの問題で、優劣を示すものではありません）
Re:C? (スコア:0)
Re:C? (スコア:2, 興味深い)
Re:C? (スコア:0)
使えない人を現場に寄越されたときに辞める決心がつきましたよ。
そういう采配する人たちとはとてもじゃないが仕事はできない。
Re:C? (スコア:0)
もうあんな仕事は受けたくない。仕様書起こしなおして一から作り直したほうがまし。