Ognacの雑感

# re: 設計レベルでのOOPを解って欲しい 2007/09/20 2:08 Mr.T

Mr.Tです、こんにちは。
>これがお気に召されないみたいで
結局、人間は感情/感性で動く典型みたいな話になりますね...それまでの経験から判断するのはよいのですが、それをかたくなに守らなくてはいけないと思い込む、これは反面教師になりますね。

# re: 設計レベルでのOOPを解って欲しい 2007/09/20 9:45 シャノン

あまりOOPと関係が無い話のような…。
非OOPだって類似ロジックをまとめることはできますが、この設計者はそれでも嫌がるでしょうからね。
経理には明るくありませんが、入出金伝票を振替伝票の派生とするのはあまりよろしくないような…。

# re: 設計レベルでのOOPを解って欲しい 2007/09/20 12:51 まりり

本質的には、OOPとは関係なさそうに見えます。
派生しようが、別のクラスにまかせようが、同じような処理なのでどこかにまとめます、という話ですよね。

振替伝票でzz日だけどこれは共通部分と固有部分の2つに分かれます。出金伝票と入金伝票は振替伝票の共通部分をそのまま利用するのでxx日とyy日、と説明するだけなのでは？

お客さんだってPMだってリーダだって、その人の理解できる言葉で話せば通じないことはないですよ、きっと。

# re: 設計レベルでのOOPを解って欲しい 2007/09/20 13:00 Ognac

>あまりOOPと関係が無い話のような…。
>伝票の共通部分をそのまま利用するのでxx日とyy日、と説明するだけなのでは？

うーん。私の捉え方が変わっているのかな、ご承知のように入金伝票と出金伝票は片方を現金に固定した振替伝票であるので、「振替伝票を規定クラスにして派生させる」という捉え方をしています。預消費税と支払消費税も消費税から派生すると捉えてうまく思想的にまとまります。
謂われるに外部の人には共通部品化や関数の標準化という話をしています。
それにも関わらず、業務面からみて、入金伝票/出金伝票/振替伝票の3サブシステムで設計書も3種類を要求されたりするので上記のエントリーとなりました。もちろん製造段階では共通化して実装しているのは秘密です。

# re: 設計レベルでのOOPを解って欲しい 2007/09/20 13:54 シャノン

> ご承知のように

知りませんでしたｗｗ

> 入金伝票と出金伝票は片方を現金に固定した振替伝票

振替伝票は両方に任意の項目を書けますよね。
入出金伝票は、片方は現金に限られますよね。
一般的に、基底クラスで出来ることが派生クラスでできないのは良くない設計だと思います。
全ての伝票には貸方、借方というプロパティがあるのは明らかですから、振替伝票と入出金伝票の共通の基底クラスとして抽象伝票を作るという形がいいような気もします。

# re: 設計レベルでのOOPを解って欲しい 2007/09/20 14:06 melt

＞もちろん製造段階では共通化して実装しているのは秘密です。
グッジョブですねｗ

# re: 設計レベルでのOOPを解って欲しい 2007/09/20 16:43 Ognac

>全ての伝票には貸方、借方というプロパティがあるのは明らかですから、振替伝票と入出金伝票の共通の基底クラスとして抽象伝票を作るという形がいいような気もします。
そうですそうです。軽はずみでした。振替伝票の下位レベルクラスを規定にすべきですね。
アドバイスありがとうございました。

# re: 設計レベルでのOOPを解って欲しい 2007/09/20 22:58 中博俊

私は反対ですね。
設計書は非正規化されているべきだと思います。
業務単位に切り分けているんであれば、なおのことその業務としての流れを重視し、おかしいところがないかどうかを調べます。

それをまとめるかどうかは作りの問題。

工数はそれこそテクニカルな話なので、関連付ける意味はないです。
3, 0.5, 0.5でいいでしょう。

# re: 設計レベルでのOOPを解って欲しい 2007/09/21 0:44 Ognac

>私は反対ですね。
御大に反対されたらシュンとなりそうですが、業務側(顧客)から見る業務設計書のあり方と製造側から見た設計書の違いだと思うのです。
成果物が 要件定義書/外部設計書/内部設計書の3部の時は外部設計書以下はOOP視点で良いと思うのです。
成果物が 外部設計書/内部設計書の2部の時は内部設計書がOOP視点かな。
成果物が 設計書ひとつの時...どうしよう..PG任せになるのかなぁ。.....混乱してきましたので後日の宿題にさせて下さい。

# re: 設計レベルでのOOPを解って欲しい 2007/09/21 9:12 中博俊

外部設計書は物語です。
お客さんが見るものです。
そこにあるものだけで一貫性があるべきです。
これはあそこに、あれはあそこにという文書は読みにくいというかお客さんに読ませる物語としては失格です。

# re: 設計レベルでのOOPを解って欲しい 2007/09/21 9:37 シャノン

外部設計書はそうですね。
でも内部設計書は正規化すべきですよね。
で、今してるのは内部設計と製造の話ですよね。
外部設計書にクラス図なんて出てきませんよね。

# re: 設計レベルでのOOPを解って欲しい 2007/09/21 11:46 Ognac

>お客さんが見るものです。
>外部設計書はそうですね。

認識はあっていると思うのです。業務面からみれば業務ルールが明確になればよいので、実装技術云々は二の次になります。
製造側からみれば実装を意識した設計であって欲しい。その意味でOOPを意識した物理設計をして欲しいとか考えるのです。
業務設計と実装設計の定義(境界)が不明だったので話がずれてしまったと思います。
設計者は両方が解る人でありたいですが、無いものねだりなのですかねぇ。

# re: 設計レベルでのOOPを解って欲しい 2007/09/21 16:23 中博俊

両方わからなければ辞めてもらわなきゃね。

# <url>http://www.multipleinsurquotes.com/|insurance quotes</url> igvxp <url>http://www.cheapairflights4you.com/|cheap flights</url> =-]] <url>http://www.instantinsurquotes.com/|discount auto insurance</url> %-O 2012/10/04 11:49 Maud

<url>http://www.multipleinsurquotes.com/|insurance quotes</url> igvxp <url>http://www.cheapairflights4you.com/|cheap flights</url> =-]] <url>http://www.instantinsurquotes.com/|discount auto insurance</url> %-O

# <url>http://www.leadinglifeinsurancebrands.com/|senior life insurance</url> >:[ <url>http://www.autosinsurance4u.com/|free car insurance quotes</url> 6533 <url>http://dynamicteencompany.org/|cheap auto insurance</url> 2012/10/23 2:31 Kaeden

<url>http://www.leadinglifeinsurancebrands.com/|senior life insurance</url> >:[ <url>http://www.autosinsurance4u.com/|free car insurance quotes</url> 6533 <url>http://dynamicteencompany.org/|cheap auto insurance</url> =-(((