MYSTERY ZILLION

CalmHill

Object-Oriented ဆိုတာကတော့ လူတော်တော်များများနဲ့ မစိမ်းတဲ့စကားလုံးပါ။ အခုနောက်ပိုင်း ပေါ်တဲ့ Programming Language တွေအားလုံးနီးနီးက Object-Oriented ကို Support လုပ်ကြပါတယ်။ နောက်ပြီးတော့ Programming လေ့လာတဲ့လူတော်တော် များများလည်း Object-Oriented ကိုလေ့လာကြပါတယ်။ ဒါတောင် တစ်ခါတစ်လေမှာ Object-Oriented ရယ် Programming Language ကိုမကွဲပြားကြဘူး။ Object-Oriented Programming ဆိုတာဘာလဲမေးရင် C++ လို့ပြောတဲ့လူ တော်တော်များများ တွေ့ဖူးပါတယ်။ ဒါတွေကတော့ ကျောင်းတွေမှာ Object-Oriented Programming ဆိုပြီး C++ နဲ့သင်ရာကနေ Object-Oriented Concept ကို Language နဲ့ကွဲအောင် မသင်နိုင်ခဲ့လို့ပါ။ Object-Oriented Programming ကနေ ဆက်ပြီးတော့ Object-Oriented နဲ့ပါတ်သက်ပြီး သိသင့်တာတွေကို အပိုင်းလိုက် ရေးမယ်လို့ စိတ်ကူးပါတယ်။

Object-Oriented Programming ကိုဘာလို့သင်သလဲဆိုရင် ရည်ရွယ်ချက်က သိပ်မများပါဘူး 1. Data Abstraction 2. Polymorphism 3. Code Reusability ဆိုပြီး သုံးမျိုးပဲရှိမယ်။ အသေးလေးတွေ ခွဲပြောရင်တော့ သုံးမျိုးမက ထွက်လာဦးမှာပါ။ 1. Data Abstraction အတွက်ဆိုရင် Real World Entity တွေကို Class တွေနဲ့ ကိုယ်စားပြုနိုင်ရမယ် Operation တွေကို Abstract Level လုပ်နိုင်ရမယ်။ ဆိုလိုတာက Operator Overloading လိုဟာတွေကို Data Abstraction ထဲကို ထည့်ချင်ရင် ထည့်ပြောလို့ရတယ်။ 2. Polymorphism ဟာလည်း အင်မတန်အရေးပါမယ် သူ့ကိုသုံးတဲ့အတွက်ကြောင့် Code တွေကျစ်ကျစ်လစ်လစ်ရှိသွားမယ်။ Abstract Data Type တစ်ခုတည်းကို ကိုင်ပြီးတော့ Specific Data Type တွေအားလုံးကို Access လုပ်လို့ရမယ်။ 3. Code Reusability ဟာ Software Development မှာအင်မတန်အရေးပါတယ်။ စနစ်ကျတဲ့ Code Reusability ဆိုတာက Copy and Paste လုပ်တာမဟုတ်ဘူး။ Object-Oriented Concept အရဆိုရင် Code Reuse လုပ်တယ်ဆိုတာ Inherit လုပ်ယူလိုက်တာပဲ။ Source Code ကနေလုပ်တာ ဖြစ်နိုင်သလို Binary Library ကနေလုပ်ယူတာလည်း ဖြစ်နိုင်တယ်။ Object-Oriented Programming သင်ဖူးတယ်ဆိုရင် ဒါတွေကို ဘယ်လိုရေးရမယ် ဆိုတာကို သင်ဖူးတာပဲ။

Object-Oriented Programming ကိုတတ်တယ်ဆိုရင် Object-Oriented Software Engineering ကိုလုပ်တတ်သလားဆိုတော့ မလုပ်တတ်သေးပါဘူး အများကြီးကျန်နေပါသေးတယ်။ Object-Oriented Programming တတ်တယ်ဆိုတာ Object-Oriented Design လုပ်ထားတဲ့ Software တစ်ခုကို Implement လုပ်တဲ့နေရာမှာ ဒါမျိုးဖြစ်အောင် ရေးပေးဆိုပြီး ခိုင်းလို့ရတဲ့ အခြေအနေပဲရှိပါသေးတယ်။ Object-Oriented ဆိုကတည်းက အရေးကြီးဆုံးက Real World မှာရှိတဲ့ အရာတွေကို Software ထဲမှာ Class တွေအနေနဲ့ Represent လုပ်နိုင်ရပါမယ်။ ဒါကြောင့် Object-Oriented မှာဆိုရင် Implement မလုပ်ခင်မှာ Design Model ဟာအင်မတန် အရေးပါပါတယ်။ Model မှားရင် ဆက်ပြီးတော့ Implement လုပ်လို့မရတော့ပါဘူး။

ဥပမာပြောရရင် တက္ကသိုလ်တစ်ခုက ကျောင်းသားတွေရဲ့ Information တွေကို ထိမ်းမယ့် System တစ်ခုရေးမယ်ဆိုရင် Model ထဲမှာဘာတွေပါမလဲ ဆိုတော့ Student, Professor, Module စတာတွေပါမယ်ပေါ့။ ဒီနေရာမှာ Relation တွေရှိဦးမယ် Student တစ်ယောက်မှာ Module အများကြီး ယူလို့ရတယ်။ Module တစ်ခုမှာ Student အများကြီးရှိမယ်။ Module တစ်ခုကို Professor တစ်ယောက်ပဲသင်တယ် Professor တစ်ယောက်ကတော့ Module အများကြီးသင်တယ် စတာမျိုးတွေကို ကြိုပြီး Model လုပ်ယူရပါတယ်။ ဒီအချိန်လောက်အထိက Object-Oriented Programming ကိုကောင်းကောင်း လေ့လာခဲ့ရင် လိုက်မှီသေးတယ်။ Model တစ်ခုကို ပြောလိုက်တာနဲ့ Code ရေးရမယ့်ပုံစံတွေက ပုံသေရှိနေတယ်။ အဲ့ဒီပုံသေဖြစ်နေတတ်တဲ့ Code လေးတွေကို Design Pattern လို့ခေါ်ပါတယ်။

Design Pattern ဆိုတာကနေစပြီးတော့ Object-Oriented Programming ကိုပဲသင်လာတဲ့လူက မသိတော့ဘူး။ ဘယ်လောက်ပဲ အတွေ့အကြုံရှိတဲ့ Object-Oriented Programmer ဖြစ်ပါစေ Object-Oriented Modelling မလေ့လာဖူးရင် Pattern တော်တော်များများကို မသိနိုင်ပါဘူး။ Pattern တွေကလည်း သိပ်တော့ အများပါဘူး အသုံးများတဲ့ Pattern တွေက Abstraction-Occurance, General Hierarchy, Player-Role, Singleton, Observer, Delegation, Adapter, FaГ§ade, Immutable, Read-Only, Proxy, Factory ဆိုပြီးရှိပါတယ်။ Pattern ဆိုတာက မြင်ဖူးနေကျ တွေ့ဖူးနေကျ အရာတွေပါ ဒါတွေကို နာမည်တပ်ထားတာပါ။ Code ကိုမြင်လိုက်ရင် သြော်ဒါကိုခေါ်သလားဆိုပြီး နားလည်သွားပါမယ် ဒါပေမယ့် Object-Oriented Modelling ကိုလေ့လာဖူးတာမျိုး ဒါမှမဟုတ် Object-Oriented ကိုသုံးပြီးတော့ Development လုပ်တဲ့အလုပ်မှာ လုပ်ဖူးတာပဲဖြစ်ဖြစ် မရှိလို့ကတော့ ရှိသမျှ Pattern အားလုံးကို မြင်ဖူးတယ်ဆိုတဲ့ Programmerဆိုတာမရှိပါဘူး။ Pattern တစ်ခုချင်းကိုတော့ နောက်ပိုင်းဆက်ရေးပါ့မယ်။

Modelling မှာပြဿနာတော်တော်လေးရှိပါတယ် Domain Model ဆိုတာက ကိုယ် Implement လုပ်မယ့် Environment ကိုဖော်ပြတဲ့ Model ပါ။ Domain Model ကမြင်သာပါတယ် ပြောပြလိုက်ရင် Programmer လည်းနားလည်ပါတယ် ဒါပေမယ့် အဓိကပြဿနာက Domain Model တစ်ခုတည်းနဲ့ အလုပ်လုပ်တဲ့ Software တစ်ခုထွက်မလာပါဘူး။ အနည်းဆုံးတော့ အပေါ်ကနေပြပေးမယ့် User Interface တော့ပါရဦးမယ်။ နောက်ပြီးတော့ ဘာတွေထပ်ပါနိုင်မလဲဆိုတော့ Non-Functional Requirement တွေလည်း ထပ်ပါလာဦးမယ်။ အဲဒါတွေကို အဓိကထားတဲ့ Model ကိုတော့ System Model လို့ခေါ်ပါတယ်။ ဒီတော့ Software တစ်ခုကို Object-Oriented Implement လုပ်တဲ့နေရာမှာ Model တွေအများကြီးပါလာ တတ်ပါတယ်။ ဥပမာ- Domain Model, UI Model, Non-Functional Requirement Model စသည်ဖြင့် အများကြီးထွက်လာတတ်ပါတယ်။ Model တစ်ခုချင်းကို စနစ်တစ်ကျ Map လုပ်ပေးနိုင်မှသာ Object-Oriented နဲ့ တည်ဆောက်တဲ့ Software လို့ခေါ်ပါတယ်။ ဘယ်လို Map လုပ်မလဲအပေါ်မှာလည်း ထပ်ပြီးတော့ နည်းစနစ်တွေထွက်လာပါတယ် Model-View Controller ရယ် Application Layering Model ရယ်ကတော့ လူသုံးများပါတယ်။

Object-Oriented ကိုသုံးခြင်းအားဖြင့် အကျိုးရှိနိုင်တာတွေကတော့ အများကြီးရှိပါတယ်။ ဒါပေမယ့် Software House တော်တော်များများကတော့ Object-Oriented သုံးပြီးတော့ Develop လုပ်တယ်ဆိုတာ ရှားပါတယ်။ တော်တော်များများကတော့ Rapid Application Development ပဲသုံးပြီး အလွယ်ရေးကြပါတယ်။ ထွက်လာတဲ့ အကျိုးဆက်တွေကတော့ ပြင်ရခက်ပါတယ် ထပ်ထည့်ရလည်း အင်မတန်ခက်ပါတယ်။ တော်တော်များများ Object-Oriented သုံးရင် Development Time ကြာတယ်လို့ ယူဆကြပါတယ်။ Modelling မှာကြာတယ်ဆိုတာ လက်ခံပါတယ် ဒါပေမယ့် Model ပြီးသွားရင်တော့ Development ဟာစနစ်ကျတဲ့အတွက် အင်မတန်မြန်ပါတယ်။ CASE Tools တွေသုံးရင် Model ပြီးတာနဲ့ Code ရဲ့ တစ်ဝက်ပြီးတယ်လို့ ပြောနိုင်ပါတယ်။ ဆက်ပြီးတော့ CASE Tools တစ်ခုကိုသုံးပြီး Modelling, Pattern, MVC, Layering ဘယ်လိုလုပ်မလဲ တစ်ခုချင်းစီဆက်ရေးပါဦးမယ်။ လိုအပ်ချက်ကတော့ Object-Oriented Programming Language တစ်ခုခု တတ်ရပါမယ်။ UML ကိုလည်း အနည်းနဲ့အများ နားလည်ရင် ဖတ်လို့ပိုအဆင်ပြေပါလိမ့်မယ်။ UML အတွက်တော့ Modelling မှာအကြမ်းပြောဦးမှာ ဖြစ်လို့ မသိလည်း ပြဿနာတော့ သိပ်မရှိပါဘူး။

ajminn207

I am studying programming, I like what you write and it is useful for me. Please, give the self-learners your hand and write more articles like this one.
Thank you very much!

AKM

saturngod

OO ဟာ ကျွမ်းကျင်ရင် development လုပ်တာ မြန်ပေမယ့် စသုံးကာစ လူတွေအတွက် RAD လောက်မမြန်ဘူးဗျ... OO ကိုသုံးတဲ့အခါမှာ အဆင့်ဆင့်တွေ စဉ်းစားရေးဆွဲရတယ်။ ဒါကြောင့် နောက်ပိုင်းပြင်ဆင်တဲ့အခါ အသစ်ထပ်မံ ဖြည့်စွက်တဲ့အခါ အရမ်းကို အဆင်ပြေတယ်။ အဆင့်ဆင့်ရေးဆွဲ စဉ်းစားရတဲ့အတွက်ကြောင့် RAD လောက် မမြန်တာအမှန်ပဲဗျ။ အမှန်တိုင်းပြောရင် ကျွန်တော် OO ကို တတ်တယ်ဆိုရုံပဲ RAD လောက် ကျွမ်းကျင်မှုမရှိဘူးဖြစ်နေတယ်။ OO သုံးမယ်ဆိုရင် UML ကို မဖြစ်မနေရေးဆွဲရတော့မယ်။ ငယ်ငယ်က တစ်ခေါက်လုပ်ဘူးတယ်။ ကျောင်း project အတွက်ပေါ့။ project တစ်ခုလုံး OO concept နဲ့ စဉ်းစားပြီး UML တွေဆွဲ ပြီးတော့ လက်တွေ့ရေးတော့ UML အတိုင်းလုပ်တာအဆင်မပြေ :D အဲလောက် OO ပိုင်တာ.... UML ပြန်ပြင် code ပြန်ရေးကြည့်နဲ့ တော်တော်အချိန်ကြာသွားတယ်။ OO မကျွမ်းကျင်ပဲ Project တွေလုပ်ရတာ တော်တော်ဆိုးတယ်ဗျ။ OO မပါပဲ အဲဒီ project ကို ရေးလိုက်တာ ၁ ပတ်နဲ့ပြီးသွားတယ်။ OO နဲ့ လုပ်တာ ၁ ပတ်အတွင်းမပြီးတာနဲ့ နောက်ဆုံး RAD ဖြစ်သွားတယ် :P

အဲတုန်းက ငယ်သေးတာရယ် concpet မမိတာရယ်ကြောင့် develop လုပ်ရတာ နှေးနေတာဖြစ်ကောင်းဖြစ်မှာပါ။ နောက်ပိုင်း project ကြီးလာလေ OO က အရေးပါလာလေပဲ။ XML တွေနဲ့ လုပ်တဲ့အခါမှာ OO က လုံးဝအရေးပါတယ်။ OO မသိရင် XML manage လုပ်ရတာအရမ်းခက်တယ်ဗျ....

kotharthar

ကျောင်းမှာ Programming Language နဲ့ မကွဲတာကတော့ အမှန်ပါပဲ။
ဒါပေမယ့် Coding မပါဘဲ နဲ့ OOP concept တွေချည်းချပြနေလို့လဲ စာသင်သားက လုံးစေ့ပတ်စေ့နားမလည်။
အမှန်ကတော့ OOP ဟာ Programming Language (C++ တို့ JAVA တို့) က အတင်း ဖန်တီးထားတဲ့ နည်းလမး်မဟုတ်ပါဘူး။

Software Development လုပ်တဲ့အခါ စနစ်ကျတဲ့၊ လုပ်သင့်တဲ့ နည်းလမ်း၊ ဖြေရှင်းမယ့် ပြသနာကို
software ကမ္ဘာထဲ ကိုလွယ််လင့်တကူ ပြောင်းလဲ ပုံဖော်လို့ရမယ့်နည်းကို ချမှတ် လမ်းညွှန်ထားတာပါ။
ဒီနည်းက ကောင်းလွန်းလို့ Programming Language ကို ဖန်တီးတဲ့အခါ OOP ရဲ့စည်းမျဉ်းစည်းကမ်းတွေ
ကို လိုက်နာနိုင်အောင် ဖန်တီးပေးလာကြရာက OOP ဟာ popular ဖြစ်လာသပေါ့။

Programming Language တွေဟာ OOP ကို support လုပ်ပုံခြင်းမတူကြပါဘူး။
တစ်ခါခါ ဇဝေဇဝါဖြစ်ရပါတယ်။ ဥပမာ
C++ မှာ Multiple Inheritance လုပ်လို့ရပါတယ်။
JAVA မှာမရပါ။
အဲဒီအခါ OOP ဟာ Multiple Inheritance ကို လုပ်ခွင့်ပေးသလား မပေးဘူးလားဆိုတာ
ဇဝေဇဝါဖြစ်လာပါတယ်။

OOP Design လုပ်ရာမှာလည်း C++ သုံးမှာလား Java သုံးမှာလားပေါ်မူတည်ပြီး
Multiple Inheritance လုပ်သင့်မလုပ်သင့် စဉ်းစားစရာဖြစ်လာပြီး၊ ပိုဆိုးတာက (လူများရင်)
အငြင်ပွားစရာဖြစ်လာပါရော။

C++ တို့ JAVA တို့ကျတော့ compile language မို့လို့ ထားတော့
Ruby မှာကျတော့ Class Definition ကို run time မှာ Programatically update လုပ်နိုင်ပါသေးတယ်။
Polymorph နဲ့သွားမရောနဲ့ဦးနော်။ run time မှာ အခြေအနေပေါ်မူတည်ပြီး class ရဲ့ methods တွေ
variable ကိုလိုတိုးပိုလျှော့လုပ်နိုင်ပြန်ရော။

Inheritance လုပ်ထားတဲ့ Class က Parent ရဲ့ method ကို ခုပဲ support လုပ်လိုက်
ခုပဲ support မလုပ်လိုက်နဲ့ ရယ်ရတယ်။ ကဲ ဒီလို feature တွေကို OOP က လုပ်ခွင့်ပေးမယ် မပေးဘူး သတ်မှတ်မထားပါဘူး။
Language ဖန်တီးသူတွေက ကောင်းတာလေးတွေထည့်ထားတာပါ။

အများအားဖြင့်တော့ Project တိုင်းမှာ Design Time ကိ်ု လုံလောက်တဲ့ အချိန်မပေးပါဘူး။
(ပွင့်ပွင့်လင်းလင်းပြောရင်) Programmer ကိုယ်တိုင်ကလည်း Design (UML) တွေဆွဲရမှာပျင်းပါတယ်။
လက်တွေ့ အခု code လုပ် အခုရနေတာပဲ၊ ပြသနာတွေ့တော့ မီးစင်ကြည့်ကတာပေါ့ ဆိုတာမျိုးလုပ်ကြပါတယ်။
နောက်တစ်ခု အထက်မှာ ပြခဲ့သလိုပဲ Design မှာတော့ Multiple Inheritance။ Language က Java ကိုသုံးမယ်။
ကဲ ပြသနာတက်ကရော...ဒီ့ထက် ဆိုးတဲ့ အပိုင်းတွေရှိသေးတယ်။
လိုရင်းကတော့ အတွေ့အကြုံနည်းကြတဲ့ အချိန်မှာ ဖြစ်နိုင်ရင် OOP ကို မသုံးဖြစ်ကြဘူး။

Programmer တွေအနေနဲ့ ကိုယ်တိုင်က ကိုယ့်ဟာကို အကျင့်လုပ်ပြီးသုံးပါမှ OOP ကိုနိုင်လာမှာပါ။
ကျွန်တော့်ရုံးမှာတော့ Ruby SCript တွေရေးရင် တောင် Class တွေ Module တွေခွဲပေးရပါတယ်။
မဟုတ်ရင် Supervisor က အားကြီး စိတ်ဆိုးပါတယ်။ ဒီလိုဆိုတော့ လဲ ရှိသမျှ function တွေကို
Class ထဲမှာ static method အဖြစ် ပြုံထည့်ပေးလိုက်တာပေါ့ ဟီး ဟီး။ (ကဲ..တောင်းချင်ဦးဟဲ့ Class။ မှတ်ကရော။)

CalmHill

Concept & Implementation ခွဲမြင်နေတာက ပြောရမယ်ဆိုရင်တော့ အဲဒီနှစ်ခုကို ခွဲသင်လို့ပါ။ ပြောရမယ်ဆိုရင် UML ကိုသင်လိုက်တာက ပုံဆွဲသင်သလို သင်လိုက်လို့ပါ။ စာမေးပွဲမေးခွန်းကို ပိုင်းဖြတ်ပြီးဖတ်တတ်ရင် အမှတ်ပြည့်ရတဲ့ Class Diagram တွေထွက်လာပါတယ်။ ဒါပေမယ့် သင်မျှကတော့ ပလုံကနဲ့တောင် မမြည်နိုင်တော့ပါ။ ဖြစ်နိုင်မယ်ဆိုရင် UML Diagram ကို Code Interpretation နဲ့တွဲသင်သင့်တယ်ဗျ။

Language ကွဲရင် Code Interpretation ကွဲပါတယ်။ Java မှာ Assocation သုံးတာနဲ့ C++ Assocation လုပ်ပုံချင်းကတော့ ကွဲပါတယ်။ အရှင်းဆုံးပြောရရင် C# မှာပါတဲ့ Properties ရယ် Java, C++ မှာယူဆတဲ့ Properties မတူပါဘူး။

Multiple Inherit ကတော့ တုတ်ထမ်းဒါးထမ်း ပြောရမယ်ထင်တယ်။ ခက်တာက တစ်ခါတစ်လေတော့လည်း လိုတဲ့နေရာက လိုနေပြန်ရော။ အဲဒီအချိန်ကျရင်တော့ မရတဲ့ဟာနဲ့ ရေးမိရင်တော့ ပြဿနာတက်ပြန်ရော။

အခုတော့ UML နဲ့အစအဆုံး ဘယ်လိုလုပ်တယ်ဆိုတာ အကြမ်းရေးထားတယ်။ နောက်နေ့မှ Diagram + Code ကို Language သုံးမျိုးလောက်နဲ့ နည်းနည်းစီရေးမယ်။:D ဒီတစ်ခါတော့ ရေးစရာ တော်တော်နဲ့မကုန်တော့ဘူး အရှည်ကြီးရေးရမယ်ထင်တယ်။:D

CalmHill

Object-Oriented Modeling ဆိုရင်တော့ UML ကိုရှောင်ချင်လို့မရပါဘူး။ UML ဆိုတာက လွယ်လွယ်ပြောရရင် ပုံဆွဲပြီး System ကို Model လုပ်တာပဲ။ ဘာထူးခြားသလဲဆိုတော့ အရင်ကဆိုရင် Requirement စုတာကနေ နောက်ဆုံးအထိကို Formal Specification အရ အကုန်လုံးစာနဲ့ သေသေချာချာသိမ်းရတယ်။ Specification တွေမှာ အကုန်လုံး အဆင့်အလိုက် Format ရှိတယ်။ Domain Site ကိုသွားပြီး ဗလာစာအုပ်တစ်အုပ်နဲ့ မေးမြန်းပြီးမှတ်လာခဲ့ ပြန်ရောက် Programmer တွေခေါင်းချင်းဆိုင်ပြီး မနက်ဖြန်စရေးမယ်ဆိုပြီး ခွဲတမ်းချရေးတာမဟုတ်ဘူးဗျ။ Requirement Specification မှာဆိုရင် Standard တွေအများကြီးရှိတယ် IEEE Standard သုံးတဲ့လူက သုံးကြတယ် စုံနေတာပဲ။ ပြောရမယ်ဆိုရင်တော့ Formal Specification ကလည်း အသေးစိတ် အကုန်ပါတော့ ကောင်းတာပါပဲ ဒါပေမယ့် Document ကိုအမြန်ဆုံး လုပ်ချင်တယ်ဆိုရင်တော့ တစ်ချို့အဆင့်တွေကို ကျော်မှပဲ မြန်ပါတယ် မဟုတ်ရင်တော့ အနည်းနဲ့အများတော့ ကြာပါတယ်။

UML မပေါ်ခင်ကတည်းက ပုံဆွဲပြီး သုံးကြတာက ရှိနေပြီ။ အရင်တုံးက Object-Oriented Modeling Technique ဆိုတဲ့စာအုပ်မျိုးတွေမှာဆို အခုသုံးနေတဲ့ UML နဲ့ဆင်တဲ့ ပုံတွေသုံးနေကြပြီ။ ဒါပေမယ့် တစ်ယောက်နဲ့တစ်ယောက် သုံးကြတာမတူဘူး။ ဒါကြောင့်အားလုံး ပေါင်းပြီး စနစ်တကျသတ်မှတ်လိုက်မှ Unified ဖြစ်သွားတာကို အကြောင်းပြုပြီး Unified Modeling Language လို့ခေါ်တာပါ။ UML မှာကတော့ ဖြစ်နိုင်သ၍စာမရေးပါဘူး အကုန်လုံး ပုံတွေနဲ့ပဲကိုယ်စားပြုတယ်။ Requirement တွေအတွက်ဆိုရင် Formal Specification မှာဆိုရင် စာမရေးမနေရပါ ဒါပေမယ့် UML မှာဆိုရင်တော့ Use Case Diagram ဆွဲတတ်ရင် အလုပ်ဖြစ်တယ်။ Stick Man ရယ် Oval ရယ်နှစ်ခုသုံးတတ်ရင် အလုပ်ဖြစ်ပြီ။ ဘယ်သူတွေပါတယ် ဘာတွေလုပ်ရမယ် ဆိုတာတွေက အဲဒီနှစ်ခုကို စနစ်တကျသုံးတတ်ရင် Requirement ကို Specify လုပ်လို့ရပြီ။ Requirement ကို Validate လုပ်တာက ပိုတောင်လွယ်သေးတယ် ပုံကို Customer ကိုပြပြီးရှင်းရင် သူလည်းပိုမြင်သာတယ်။

နောက်တစ်ဆင့်အနေနဲ့ Domain Model အတွက် ဘာတွေပါမယ်ဆိုတာတွေကို စပြီးလုပ်ရတော့မယ်။ ဒီတစ်ခါကတော့ Programmer တွေတိုက်ရိုက်သက်ဆိုင်တဲ့ အပိုင်းကိုရောက်ပါတယ်။ အရင်ဆုံး Real-World Entity တွေကို Class တွေနဲ့ ကိုယ်စားပြုရပါတယ်။ ဒီနေရာမှာ Class Diagram တွေကိုသုံးရပါတယ်။ နောက်ပြီးဘာတွေ ပါလာမလဲဆိုတော့ Class တစ်ခုနဲ့တစ်ခု ဘယ်လို Relation တွေရှိတယ်ဆိုတာမျိုးတွေ ပါလာမယ်။ အရေးကြီးတာက UML ဆိုတာ ပုံနဲ့ System ကိုကိုယ်စားပြုတယ်ဆိုပေမယ့် ဒီနေရာမှာတော့ Class Diagram ကိုမြင်တာနဲ့ Programmer တစ်ယောက်ဟာ Diagram လို့မမြင်ပဲ Source Code အဖြစ်မြင်နိုင်ရပါမယ် Diagram ကိုမြင်တာနဲ့ Skeleton Code အဖြစ်ဘာသာပြန်ပြီး ချရေးနိုင်ရပါမယ်။ Diagram နဲ့ Code Structure ကိုတွဲမြင်တတ်မှသာ UML ကိုနားလည်တယ်လို့ သတ်မှတ်လို့ရပါတယ်။ Diagram Notation ကိုပဲသိတယ်ဆိုရင်တော့ အဲ့ဒီ့ Programmer ဟာ UML မတတ်ဘူးလို့ ပြောရပါမယ်။

နောက်ထပ်တစ်ဆင့် အနေနဲ့ကတော့ အလုပ်ဆိုတာ အဆင့်ဆင့် လုပ်ရတယ်ဆိုတော့ System ထဲမှာ အလုပ်တွေကို အဆင့်ဆင့် ဘယ်လိုလုပ်မယ်ဆိုတာကို Diagram ထပ်ဆွဲရပါတယ်။ ဒါကိုတော့ Sequence Diagram လို့ခေါ်ပါတယ်။ Sequence Diagram မသုံးချင်ရင်တော့ Collaboration Diagram ကိုသုံးလည်း ရပါတယ်။ ဒါပေမယ့် Sequence Diagram ကပိုပြီး အသေးစိတ် ဖော်ပြလို့ရသလို ပိုပြီးတော့လည်း ဖတ်ရလွယ်ပါတယ်။ Sequence Diagram ကိုဘာလဲမေးရင် Message Passing လို့တစ်ချို့ကပြောပါတယ်။ Message Passing ကိုဘာလဲလို့ ထပ်မေးလိုက်ရင်တော့ ဒီဘက်က Message ကိုဟိုဘက်ပို့သလို့ လျောက်ပြောတတ်ပါတယ်။ တစ်ကယ်က Message Passing ဆိုတာက ရှင်းရှင်းလေး Function Call လုပ်လိုက်တာကိုခေါ်တာပါ။ ဒီတော့ ဘယ် Function ကနေ ဘယ် Function တွေကို အဆင့်ဆင့် ခေါ်မလဲဆိုတာကို စနစ်တကျ ဖော်ပြထားပါတယ်။ ဒါကိုလည်း Code တွေအနေနဲ့ မြင်တတ်ရပါမယ်။ ဒီအဆင့်တင်ကိုပဲ စိတ်ထဲကနေရေးလိုက်တာ Code ကတော်တော်လေး ပြီးနေပါပေါ့လား။

နောက်ထပ်တစ်ဆင့်ကတော့ State Diagram တွေကိုသတ်မှတ်ရမယ်။ အဲဒီနေရာမှာ State ဆိုတာကလည်း တော်တော်လေးပြောရခက်တယ် မေးလိုက်ရင်ဘာတွေပြောလေ့ရှိသလဲဆိုတော့ Software ထဲမှာ ရှိတဲ့ အခြေအနေတစ်ခုကနေ တစ်ခုကို ပြောင်းတယ်လို့ ဖြေတတ်ပါတယ်။ ဒါဆိုရင် အခြေအနေဆိုတာ ဘာလဲဗျာလို့ ထပ်မေးလိုက်ရင် အတိအကျ ပြန်ဖြေတတ်တဲ့လူက ရှားပါတယ်။ တစ်ကယ်တမ်းက ရှင်းရှင်းလေးပါ State ဆိုတာ Class ထဲမှာရှိတဲ့ Variable တွေထဲက တန်ဖိုးတစ်ခုကို State တစ်ခုလို့ခေါ်တာပါ။ Variable ထဲကတန်ဖိုးပြောင်းတာဟာ State ပြောင်းတာပါပဲ။ အဓိကကတော့ အထဲမှာရှိတဲ့ တန်ဖိုးပြောင်းတဲ့ အပေါ်မှာမူတည်ပြီးတော့ Function Calling ပြောင်းတာပါပဲ။ ဘာလဲဆိုတော့ Condition တွေပေါ့ if, case ဒါမျိုးတွေ အဲဒီနေရာတွေမှာ ပါမှာပေါ့။ Sequence မှာက အလုပ်တစ်ခုအတွက် Function တွေကိုဘယ်လို ယူသုံးရမယ်ဆိုတာ ပြထားတယ်။ State မှာက ဘယ်အလုပ်ဆိုတာကို Variable တွေအပေါ်မှာ မူတည်ပြီးတော့ ခွဲခြားပေးတယ်။ ပြောရမယ်ဆိုရင် Code ကပြီးလုပြီးခင်တောင် ဖြစ်နေပါပြီ။

နောက်ထပ် ဘာတွေရှိသေးသလဲဆိုတော့ Code တွေပြီးသွားရင် Component တွေထွက်လာမယ် ဒါတွေကို ဘယ်လိုထားမလဲဆိုတဲ့ Diagram တွေရှိသေးတယ်။ ဒါပေမယ့် အသုံးနည်းပါတယ် မသုံးသလောက်ပါပဲ။ UML မှာက Design မှာ Code အတွက်ပါ Specify လုပ်ပြီးသားပါ။ Code ကိုကြည့်လိုက်တာနဲ့ Design နဲ့ Code ကိုက်မကိုက်ဆိုတာက အသိသာကြီးပါ လုံးဝလိမ်လို့မရပါဘူး။ အပေါ်မှာ ပြောပုံအရဆိုရင် Design ပြီးရင် Code အဖြစ်ဘာသာပြန်လိုက်ရင် Software ကပြီးပြီလို့ ဖြစ်နေပါတယ်။ အဲဒီလိုမဆိုလိုပါဘူး Infrastructure ပြီးတယ်လို့ဆိုလိုပါတယ်။ Function တွေထဲက အလုပ်တွေကတော့ ကိုယ်လုပ်ချင်တာအပေါ်မူတည်ပြီး ရေးရဦးမှာပါ။

Design ပြီးရင် Code အဖြစ်ဘာသာပြန်တာလည်း ပျင်းစရာကောင်းပါတယ် ဒါကြောင့် Design ကို Code အဖြစ်ပြန်ပေးတဲ့ Software တွေကိုသုံးရင် အင်မတန်မြန်ပါတယ်။ ကိုယ်အတွက်ဘာပဲ လုပ်စရာကျန်သလဲဆိုတော့ Function ထဲက အဓိကအလုပ်တွေပဲ ရေးစရာလိုပါတော့တယ်။ နာမည်အကြီးဆုံးကတော့ Rational Rose ပါဒါပေမယ့် အင်မတန် စျေးကြီးပါတယ်။ Rose ကကောင်းလည်း အင်မတန်ကောင်းပါတယ် Code တော်တော်များများကို ထုတ်ပေးနိုင်ပါတယ်။ Object-Oriented မဟုတ်တဲ့ Language Code တောင်ထုတ်ပေးပါတယ်။ Visual Studio ထဲမှာပါတဲ့ UML Tools ကတော့ ပုံဆွဲလိုက်တာနဲ့ Code ကထုတ်ပါလို့ပြောစရာ မလိုပါဘူး တစ်ခါတည်း ထုတ်ပေးပြီးသားပါ Code မှာပြင်လိုက်ရင်လည်း Diagram မှာပြင်ပြီးသား ဖြစ်ပါတယ်။ ကျွန်တော်ကတော့ Tigris ကထုတ်တဲ့ ArgoUML ကိုသုံးပါတယ် Open-Source ဆိုတော့အလကားရပါတယ် သူကတော့ C++, C#, Java, PHP စတဲ့ Code တွေအဖြစ်ထုတ်ပေးနိုင်ပါတယ်။ Software တွေဘယ်လိုကောင်းကောင်း မဖတ်တတ်လို့တော့ မရပါဘူး လက်နဲ့တော့ ပြင်ရတာပါပဲ ဘယ် Software မှကိုယ်တိုင်ရေးသလို Code မျိုးမထွက်ပါဘူး။ နောက်ပိုင်း ဆက်ရေးမယ့် စာတွေမှာပါမယ့် Diagram တွေက ArgoUML နဲ့ဆွဲမှာပါ။ နောက်နေ့မှ Class Diagram Notation တွေကို ဆက်ရေးပါဦးမယ်။

saturngod

good မယ်ထင် do သာ do ... UML က ကျွန်တော့်အသည်းစွဲဗျ.... programming ထက် UML ကို ပိုသဘောကျတာ... နောက်ပြီး pseudo, Flowchat ကိုလည်း သဘောကျတယ်... UML အကြောင်း good တယ်ဗျာ... :P ကျောင်းတုန်းက လူပျိုကြီးနဲ့ တွေ့ရင် မဆိုးဘူး... :D

CalmHill

Software Architecture Changes ဆိုတာက ပြောမယ်ဆိုရင် တော်တော်ဆိုးပါတယ်။ Backward Compatible မဖြစ်တာကပိုဆိုးပါတယ်။ Maintainable ဖြစ်တဲ့ Software ဆိုတာက နောင်တစ်ချိန်မှာ အပြောင်းအလဲ ဖြစ်ခဲ့ရင် Developer တွေအတွက် ဘယ်လောက် အထောက်အကူပေးမလဲဆိုတဲ့ အတိုင်းအတာမှာ မှီခိုပါတယ်။ သူနဲ့အပြိုင်စဉ်းစားရမှာကတော့ Scalable ကိစ္စကိုပါ။ ဘယ် Software မဆို နောင်တစ်ချိန်မှာ Function အသစ်တွေထပ် ထည့်ရမှာပါပဲ ထပ်ထည့်လိုက်တဲ့ Function အသစ်တွေဟာ အရင်ရှိပြီးသားကို မထိခိုက်ဘူးဆိုရင် ဒါဟာ Scalable ဖြစ်တယ်ပြောရမှာပါ။ UML နဲ့ ဒီဇိုင်းဆွဲတယ်ဆိုတာကလည်း ဘယ်အချိန်မှာ ပြင်ဆင်ရမယ် ပြင်ရင် ဘယ်အပိုင်းတွေကို ထိခိုက်သွားမယ်ဆိုတာကို မြင်သာအောင် ဆွဲတယ်ဆိုလည်း ပြောလို့ရပါတယ်။

ကျွန်တော့် အတွေ့အကြုံအရဆိုရင် ဆွဲပြီးသား အားလုံးသဘောတူပြီးသား ဒီဇိုင်းတစ်ခုကို Implement လုပ်နေရင်းမှာ ပြင်ချင်ရင်မလွယ်တော့ပါဘူး။ ပြင်လိုက်ရင် အပိုင်းလိုက်ခွဲပြီး Implement လုပ်နေရတာ ဖြစ်လို့ တစ်နေရာပြောင်းလဲတာနဲ့ တစ်ခြားထိခိုက်မယ့် အပိုင်းတွေကိုပါ စဉ်းစားရပါတယ်။ Implement လုပ်နေရင်း Change Management လုပ်ရတာ အင်မတန်ခက်ခဲသလို ကုန်ကျစရိတ်လည်း များပါတယ်။ ဒါကြောင့် အတွေ့အကြုံရင့်တဲ့ Software Architect တွေသာလုပ်ရဲပါတယ်။ Implement ပြီးသွားရင်တော့ နောင်ကိုဆက်ပြီး တိုးချဲ့ဖို့အတွက် လက်ရှိဒီဇိုင်းကို မပြင်သင့်တော့ပါ။ ဖြစ်နိုင်ရင် ရေးပြီးသား Code တွေထဲမှာ အမှားပြင်တာကလွဲရင် နောက်ထပ် Version အတွက် ထပ်ပြီး Code တွေထပ်မထည့်သင့်ပါ။ Version အသစ်အတွက် ရည်ရွယ်မယ်ဆိုရင် ဖြစ်နိုင်သမျှ Inherit လုပ်ပြီး ထပ်ပြီးတိုးချဲ့ဖို့သာ ကြိုးစားသင့်ပါတယ်။ ဒါကြောင့် Object-Oriented Design တွေဟာ Software အကြီးတွေ ရေးမယ်ဆိုရင် မရှိမဖြစ် လိုအပ်လာပါတယ်။

အခုနောက်ပိုင်းမှာ Mission Critical မဟုတ်ရင်တော့ Open Source ကိုလူတိုင်းနီးနီး သုံးလာကြပါပြီ။ ဒီတော့ အခုခေတ် Developer တွေက အရင်ကနဲ့နည်းနည်း ကွဲပြားလာတာက အရင်ကတော့ ကိုယ်သုံးတဲ့ Development Tools တွေကို ဝယ်သုံးပါတယ်။ အခုနောက်ပိုင်းတော့ Development Tools တွေကိုက Open Source တွေများလာတော့ ကိုယ်သုံးတဲ့ Development Tools ကိုတစ်ခါတစ်လေ လိုအပ်ရင်ကိုယ်တိုင် ပြင်ဖို့လိုအပ်လာရင် ပြင်ရပါတယ်။ ပြဿနာက Open Source တွေရဲ့ Version တွေက လူတွေအများကြီး ဝိုင်းရေးကြပြောင်းကြ ဆိုတော့ အပြောင်းအလဲ အရမ်းမြန်ပါတယ်။ အဲဒီမှာဖြစ်လာတာက ကိုယ်သုံးဖို့ ပြောင်းထားတဲ့ Module တွေကသူတို့ထုတ်တဲ့ နောက်ပိုင်း Version တွေမှာ Architecture ကိုပြောင်းပြီး တစ်ခြားပို့လိုက်လို့ကတော့ ကိုယ့်ဟာကတော့ အသစ်မှာ သုံးမရတော့ပါဘူး။ Version အဟောငး်ကိုပဲ ဆက်သုံးနေလို့ကလည်း မဖြစ်ပါဘူး ကိုယ်ရေးထားတာကို သုံးဖြစ်တယ်ဆိုပေမယ့် တစ်ခြားအမှားတွေကိုတော့ ကိုယ်တိုင်လည်း မပြင်နိုင်ပါဘူး။

အရင်တစ်ပါတ်လောက်က PostgreSQL ကိုအထဲက Module တွေကို ပြင်ထားတဲ့ System တစ်ခုကို Performance စမ်းဖို့အကြောင်းပေါ်ပါတယ်။ ပြင်ထားတာတွေက ၂၀၀၈ နှစ်အစပိုင်းလောက်က ပြင်ထားတာပါ။ ပြင်တယ်ဆိုပေမယ့် သူ့ဟာကိုပြင်တာမဟုတ်ပဲ ကိုယ်လိုချင်တဲ့ Feature တစ်ခုရဖို့အတွက် အသစ်ထပ်ထည့်ထားတာပါ။ ဒါပေမယ့် သူ့ထဲကပါပြီးသားတွေကို ခေါ်သုံးရတာတွေလည်း ရှိပါတယ်။ စမ်းမယ်ဆိုတော့ Compile လုပ်တာကိုက တော်တော်ခက်ပါတယ် နောက်တော့ တော်တော်လေး ကြံဖန်ပြီး လုပ်လိုက်မှ Library တစ်ခုထွက်ပါတယ်။ ထွက်လာတဲ့ Library ကို PostgreSQL မှာထပ်တပ်တာ ဘယ်လိုမှမရပါဘူး။ သုံးလေးရက်လောက် ဆက်တိုက်လုပ်တယ် မရပါဘူး မမှားပဲနဲ့ထပ်တပ်တာ မရဘူးဆိုတာ တော်တော်ထူးဆန်းပါတယ်။

နောက်ဆုံးဘယ်လိုမှ အဖြေရှာမရတာနဲ့ အကုန်တစ်စစီပြန်စစ်တော့မှ အရင်သူတို့သုံးတာက 8.1 အခုသုံးနေရတာက 8.3 ဒါပဲခြားနားတယ် ကျန်တာကတော့ အကုန်တူတယ်။ တစ်ကယ်ကတော့ အဟောင်းက အသစ်မှာမရဘူးဆိုတာ မဖြစ်နိုင်ပါဘူး Backward Compatible တော့ဖြစ်ရပါတယ်။ ဒါပေမယ့် အသေအချာစစ်လိုက်တော့ 8.1 နဲ့ 8.2 ကြားမှာ Library Function တွေကို အထဲက Code တွေကို မပြောင်းပဲ Function နာမည်တွေကို ပြောင်းထားတယ်ဆိုတာကို တွေ့ရပါတယ်။ အကုန်လုံးအသေးစိတ် ရှာကြည့်လိုက်တော့ PostgreSQL နဲ့ပါတ်သက်တဲ့ Forum တွေမှာ ပြောင်းလိုက်လို့ ပြဿနာတက်တဲ့လူတွေ ဆွေးနွေးထားကြတာ အများကြီးဖြစ်နေပါတယ်။ နာမည်ပဲပြောင်းတယ်ဆိုတော့ အကုန်လုံးပြောင်းသမျှကို Search & Replace နဲ့အကုန် ပြန်လုပ်ရပါတယ်။ ဆက်လုပ်ပြန်တော့လည်း မရပြန်ဘူး ဒါနဲ့ အပြောင်းအလဲ ထပ်ရှိသေးသလားကြည့်တော့ 8.2 နဲ့ 8.3 ကြားမှာ Library ထပ်ရေးမယ်ဆိုရင် Format ပြောင်းတယ်ဆိုပြီး ဖြစ်နေပြန်ပါတယ်။ ကိုယ့်ဟာက အရင် အဟောင်းဖြစ်နေလို့ သူ့အသစ်နဲ့ကိုက်အောင် တစ်ခါပြန်ပြောင်းရပြန်ပါတယ်။ သူတို့ဟာသူတို့ Function နာမည်တွေ မလှလို့ပြောင်းတာက ရှိပြီးသားလူတွေ ပြဿနာအကုန်တက် ကုန်ပါတယ်။

အခု MZ မှာလည်း Project အကုန်လုံးကို စမ်းလို့ ကျေနပ်တဲ့အခြေအနေ ရောက်တာနဲ့ Open Source အဖြစ်ထုတ်ပေးနေတာကို တွေ့ပါတယ်။ အိုနာဂိုင်ရယ်, Mobile အဘိဓာန်ရယ် Linux Zawgyi Keyboard ကိုအဓိကတွေ့ပါတယ်။ ကိုယ့်ပရောဂျက်ကို Version အသစ်အဖြစ်ဆက် လုပ်နေကြတာပါပဲ ဒါကြောင့် အကြံပေးချင်တာက မူရင်း Architecture ကိုမပြင်ပဲနဲ့ Extending လုပ်တဲ့နည်းကိုပဲ သုံးရင်အဆင်ပြေမယ်ထင်ပါတယ်။ တစ်ချို့ကလည်း ကိုယ်တိုင်းစမ်းကြည့်ရင်းနဲ့ ထပ်ထည့်ကြည့်ထားတာတွေ ရှိလာမယ်ဆိုရင် ရှိပြီးသားကိုပြန်ပြင်တဲ့နည်းနဲ့ Version အသစ်ထုတ်လိုက်ရင် တစ်ခြား Developer တွေ Extend လုပ်ထားတာတွေနဲ့ ပြဿနာတက်လာနိုင်ပါတယ်။ ဒါကြောင့် ရေရှည်အတွက် Maintainable & Expendable ဖြစ်အောင်လုပ်ရင် ပိုကာင်းမယ်လို့ အကြံပေးချင်ပါတယ်။ ဘာလို့လဲဆိုတော့ Commercial Software တွေ Architecture ပြောင်းတာက သူ့အထဲက Developer တွေပဲ ပြဿနာဖြစ်တာ ဆိုပေမယ့် Open Source ပြောင်းတာကတော့ အခုနောက်ပိုင်းမှာ ထိခိုက်တဲ့လူတွေပိုများပါတယ်။

Beginner

ကျေးဇူး ကိုလူပျိုကြီး...:77::77:

Your discussion is very nice.

အခုမှဘဲ OO ကိုနားလည်သွားတော့တယ်။

CalmHill

ရပ်ထားတာလေးတွေ ပြန်ဆက်လိုက်ပါဦးမယ်။ ဒီနေ့တော့ အလွယ်ဆုံးနဲ့ အသုံးအများဆုံး Pattern ကိုစကြမယ်။ Code ကိုမြင်လိုက်လို့ကတော့ ဒါတော့တို့လည်း သိတာပေါ့လို့ ပြောကြမှာပါပဲ အသစ်အဆန်း မဟုတ်ပါဘူး။ Pattern တွေထဲမှာ အသုံးအများဆုံး Pattern ကိုပြပါဆိုရင်တော့ General Hierarchy ကိုပြရမှာပါပဲ။ စပြီးတော ရေးကာစလူဆိုရင် General Hierarchy ကနည်းနည်း ပြဿနာလုပ်ပါတယ်။ မြင်သာတဲ့ ဥပမာပြောရရင် File System တစ်ခုမှာဆိုရင် File ရယ် Directory ရယ်ဆိုပြီး နှစ်မျိုးရှိမယ်။ Directory ထဲမှာ File ရယ် Directory ရယ်ပါလို့ရတယ်။ ဒါကို သူပြောတဲ့အတိုင်းဆွဲရင် အလုပ်လုပ်တဲ့ Class Diagram တော့ အောက်မှာပြထားသလို ထွက်လာပါတယ်။ သုံးလို့ရပါတယ်။

Code ကတော့ အောက်မှာပြထားသလိုထွက်ပါတယ်။


public class File
{
    public Directory myDirectory;
}


import java.util.Vector;
public class Directory
{
    public Vector myFile;
    public Vector myDirectory;
}

General Hierarchy နဲ့ဆွဲရင်တော့ အောက်ကလိုထွက်ပါတယ်။

Code ကတော့ အောက်မှပြထားပါတယ်။


public class FileSystemItem 
{
    public Directory myDirectory;
}


public class File extends FileSystemItem
{

}


import java.util.Vector;
public class Directory extends FileSystemItem
{
   public Vector  myFileSystemItem;
}

အဲဒီမှာ အပေါ်က ဒီဇိုင်းလည်း သုံးလို့ရတာပဲ ဘာကွာသလဲမေးတော့ အပေါ်ကကောင်က Zero to Many Association နှစ်ခုကွဲသွားတော့ Vector နှစ်ခု ကြေငြာထားရတယ်။ နောက်ပြီးတော့ File ရော Directory ရောကို Abstract ယူသုံးလို့ရတဲ့ Abstraction မပါဘူးဖြစ်နေတယ်။ ဆိုလိုတာက Variable တစ်လုံးတည်း ကြေငြာပြီးတော့ File ရော Directory ရော နှစ်ခုလုံးကို ကိုင်သုံးချင်လို့မရဘူး။ အောက်မှာပြထားတဲ့ ဒီဇိုင်းကတော့ Abstraction တစ်ခုပါတယ် အဲဒါပါလိုက်လို့ Association လည်း တစ်ခုပဲရှိတယ်။ ဒါမျိုးကမှ Polymorphism ကိုအကျိုးရှိရှိအသုံးချတဲ့ Structure လို့ပြောရမယ် ဒါ့ကြောင့် Optimized Design လို့ပြောလို့ရပါတယ်။။ အပေါ်မှာရေးထားတဲ့ Code တွေက ကျွန်တော်ရေးထားတာ တစ်ခုမှမပါဘူး ကျွန်တော်က ArgoUML ထဲမှာ ပုံတွေကိုဆွဲလိုက်တယ် Code ကို Java နဲ့ထုတ်ပြီး နည်းနည်းတိုအောင် Comment တွေကိုဖျက်ထားတာပဲ ရှိပါတယ်။ ArgoUML ကဘာသာပြန်ထားတာက Bi-Direction နဲ့ Code တွေကို ထုတ်ထားတာပါ။ Java မဖတ်တတ်ရင်လည်း ကိစ္စမရှိပါဘူး ArgoUML ထဲမှာသာ ပုံကိုဆွဲလိုက်ပါ C#, C++, PHP ကြိုက်တာသာ ထုတ်ခိုင်းလိုက်ပါ။ ဒါပေမယ့် အလကားရတဲ့ Software တို့ရဲ့ထုံးစံအတိုင်း အနည်းနဲ့အများတော့ အမှားပါပါတယ်။

white

[quote=လူပျိုကြီး;40891]ရပ်ထားတာလေးတွေ ပြန်ဆက်လိုက်ပါဦးမယ်။

ကိုလူပျိုရေ...
အချိန်ရခဲ့ရင် ဆက်ရှင်းပါဦး။ ကျေးဇူး အရမ်းတင်ပါတယ်ဗျို့။ \:d/

Endless Love

ဂလုပျိုရေ..ဆက်ရေးထားနော်။
နာ အကုန်လုံးကို Copy လုပ်ထားတယ်။
ပြည့်စုံသွားပြီဆိုရင် eBook လုပ်ပြီးတော့ ရောင်းစားမလို့ :D
ဟီး ဟီး နောက်တာ ချိတ်ဂျိုးရ၀ူးနော်

CalmHill

ဒီခေါင်းစဉ်အောက် ဝင်မကြည့်မိလို့ ပြောနေတာတွေ မသိဘူးဖြစ်နေလို့ပါ ဖတ်မယ့်လူရှိတယ်ဆိုရင် ဆက်ရေးပါဦးမယ်။ ဒါပေမယ့် အရင်လိုတစ်နေ့တစ်ခုရေးနိုင်တဲ့ အခြေအနေကနေ ပို့တစ်ခုကို နည်းနည်းချင်းခွဲရေးနေရတဲ့ အဖြစ်ရောက်နေလို့ သုံးလေးရက် တစ်ခုတော့ ပြီးအောင်ကြိုးစားရေးပါဦးမယ်။

Ye Htet

ဆက်ဆွဲထား ကိုလူပျိုကြီး။ အားပေးလျက်ပါ။:6:

[quote=လူပျိုကြီး;44034]ဒီခေါင်းစဉ်အောက် ဝင်မကြည့်မိလို့ ပြောနေတာတွေ မသိဘူးဖြစ်နေလို့ပါ ဖတ်မယ့်လူရှိတယ်ဆိုရင် ဆက်ရေးပါဦးမယ်။ ဒါပေမယ့် အရင်လိုတစ်နေ့တစ်ခုရေးနိုင်တဲ့ အခြေအနေကနေ ပို့တစ်ခုကို နည်းနည်းချင်းခွဲရေးနေရတဲ့ အဖြစ်ရောက်နေလို့ သုံးလေးရက် တစ်ခုတော့ ပြီးအောင်ကြိုးစားရေးပါဦးမယ်။
အားပေးနေပါတယ်ဗျာ.. ဆက်ရေးပေးပါ ဗဟုသုတတော်တော်ရတယ်ဗျ... မသိတာတွေလဲသိရတယ်.
ကျေးဇူးတင်ပါတယ်ဗျာ..:77::77::77:

binary

UML ကအသည်းစွဲဆိုရင်....နာလည်းပါတယ်ဟေ့...ကျောင်းတုန်းက UML ဆရာမကိုတောင်သတိရမိသေး..:)))

binary

princeakarit

ဒီတစ်မျက်နှာလုံး save လုပ်သွားတယ်နော်။ :) :)) :P =))

thar5oe

[quote=binary;44215]uml ကအသည်းစွဲဆိုရင်....နာလည်းပါတယ်ဟေ့...ကျောင်းတုန်းက uml ဆရာမကိုတောင်သတိရမိသေး..:)))

မေသန်းနု (စိတ်ဆိုးနဲ့ ဆရာမနာမည်မမှတ်မိတော့လို့) ကိုပြောတာလား။ သူ့ကိုဆိုရင်ကျွန်တော်လဲသတိရတယ်ဗျာ။ သူသင်ပေးလိုက်လို့သာ uml ကိုမကြောက်တော့တာ။ ဆရာမကျောင်းမှာဆက်ရှိနေတုန်းပဲလားမသိဘူးဗျာ။ လာမယ့်လထဲမှာလဲကျောင်းသူ/သားဟောင်းတွေရဲ့ ဆရာဆရာမအဟောင်းတွေကို ဆရာကန်တော့ပွဲလုပ်မှာတဲ့ ပြန်လာချင်လိုက်တာဗျာ။ သူငယ်ချင်းတွေနဲ့လဲပြန်တွေ့ချင်နေတယ်။ သူငယ်ချင်းတွေစုံတုန်း အရင်လို သာဓုကန်သွားပြီး ဟီး ဟီး (ဘုရားဖူးမှာကိုပြောတာနော်)

သားဆိုး

thanwinnaing

ဆက်ရေးပါဗျာ
ဖတ်ဖို့ စောင့်နေပါတယ် :)[quote=လူပျိုကြီး;44034]ဒီခေါင်းစဉ်အောက် ဝင်မကြည့်မိလို့ ပြောနေတာတွေ မသိဘူးဖြစ်နေလို့ပါ ဖတ်မယ့်လူရှိတယ်ဆိုရင် ဆက်ရေးပါဦးမယ်။ ဒါပေမယ့် အရင်လိုတစ်နေ့တစ်ခုရေးနိုင်တဲ့ အခြေအနေကနေ ပို့တစ်ခုကို နည်းနည်းချင်းခွဲရေးနေရတဲ့ အဖြစ်ရောက်နေလို့ သုံးလေးရက် တစ်ခုတော့ ပြီးအောင်ကြိုးစားရေးပါဦးမယ်။

thar5oe

ကိုလူပျိုကြီးရေ
မျှော်နေတယ်ဗျာ။ မျှော်နေမှ အတော်ကြာသလိုထင်နေရတယ်။

သားဆိုး

CalmHill

[quote=thar5oe;46286]ကိုလူပျိုကြီးရေ
မျှော်နေတယ်ဗျာ။ မျှော်နေမှ အတော်ကြာသလိုထင်နေရတယ်။

သားဆိုး

အော်နေဟစ်နေပြီဟ ဟီးဟီး ရေးမယ်လို့ ပြောထားတာကို မေ့နေတာဗျ:d အခုဒီဟာမြင်မှ သတိရတာ။ ဒီကနေ့တော့ တစ်ပုဒ်ရေးနေပါတယ် ဒါပေမယ့်ပုံဆွဲစာရေးဆိုတော့ ပြီးမယ်မထင်ဘူး နေ့ပိုင်းကလည်းမရေးအားဘူး မနက်ဖြန်ညလောက်မှ ပြီးမယ်ထင်တယ်ဗျ။ မနက်ဖြန်ကို ဆက်ဆက်ပြီးအောင် ရေးပါ့မယ်ဗျာ။ ကျွန်တော်က သတိမပေးရင် သတိမရတာများတယ်:d ခိုင်းဖူးတဲ့လူတိုင်း အကြောင်းသိတယ်:d

thar5oe

ကိုလူပျိုကြီးရေ
လည်ပင်းက ပဒေါင်လည်ပင်းမဟုတ်တော့ဘူးဗျ။ သစ်ကုလားအုတ်လည်ပင်းကိုဖြစ်နေတာဗျို့:d

သားဆိုး

CalmHill

ဒီတစ်ခါလည်း လွယ်လွယ်ကူကူ မြင်သာမယ့် Pattern တစ်ခုနဲ့ ပြန်ဆက်ကြတာပေါ့။ Singleton Pattern လို့ခေါ်ပါတယ်။ Class တွေဆိုရင် Object အဖြစ် Create လုပ်လို့ရပါတယ် ဒါဆိုရင် သုံးမယ့် User တွေက Class ကိုသိတာနဲ့ Object တွေအဖြစ် သုံးချင်သလိုသုံးကြမှာ စိုးတယ်ဆိုရင် Singleton ကိုသုံးလေ့ရှိပါတယ်။ Singleton မှာဆိုရင် Object အဖြစ် Client တွေကို Object လုပ်ခွင့်မပေးပါဘူး လိုချင်တယ်ဆိုရင် Create လုပ်ပြီးသား Object ကိုသာ Return ပြန်ပေးမယ့် Function တစ်ခုပဲ ပေးထားလေ့ရှိပါတယ်။ UML ပုံကိုတော့ မဆွဲအားလို့ တော်ရာနေရာကနေ ကူးပြီးပြထားတယ်။ Example ကိုလည်း Java Class တစ်ခုပြထားပါတယ်။ Code ကိုတစ်ချက်ဖတ်ကြည့်ပါ Class Structrue အရ ဘယ်လိုမှ Object လုပ်ယူလို့မရပါဘူး လိုချင်ရင် ပေးထားတဲ့ Function ကိုခေါ်သုံးဖို့ကလွဲရင် နည်းလမ်းမရှိပါဘူး။

public class Singleton {
   private static final Singleton INSTANCE = new Singleton();
   private Singleton() {}
   public static Singleton getInstance() {
      return INSTANCE;
   }
 }

သို့မဟုတ်

public class Singleton {
   private Singleton() {}
   private static class SingletonHolder { 
     private static final Singleton INSTANCE = new Singleton();
   }
   public static Singleton getInstance() {
     return SingletonHolder.INSTANCE;
   }
 }

ဒါဆိုရင် ဒါကဘယ်နေရာတွေမှာ အသုံးကျသလဲဆိုရင် မေးစရာဖြစ်လာမယ်။ တစ်ခါတစ်ရံမှာ ကိုယ်ရေးထားတဲ့ Class တွေမှာက တစ်ခါပဲခေါ်ပြီး ဘုံသုံးလို့ရမယ့် Resource တွေပါလာတယ်ဆိုရင် User တွေက အခေါက်ခေါက် အခါခါ Object တွေ Create လုပ်နေမယ်ဆိုရင် အပိုတွေဖြစ်လာမယ် Cost တွေတက်လာမယ် ဒါမျိုးတွေဆိုရင် ကာကွယ်လို့ရပါတယ်။ ဥပမာ။ Table တစ်ခုကို Query လုပ်မယ်ဆိုရင် Database ကို Connect လုပ်ဖို့လိုပါတယ် User Name တွေ Password တွေပေးရမယ် ဟိုဘက်ကနေ ခွင့်ပြုတယ်ဆိုတဲ့ Token တစ်ခုပြန်ပေးမယ်။ အဲဒါကို Table ဘယ်နှစ်ကြိမ်ပဲ ဖတ်ချင်ဖတ်ချင် ပြန်မဖတ်မချင်း သုံးနေလို့ရတယ်။ ဒါကိုပဲ Connection ကိုဖတ်ချင်တိုင်း ဖွင့်နေပိတ်နေမယ်ဆိုရင် အရမ်းနှေးပါတယ်။ ဒါဆိုရင် ဥပမာပြထားတဲ့ Code ထဲက getInstance လိုနေရာမှာ getConnection လိုဟာမျိုးရေးပြီး Program တစ်ပုဒ်လုံးရဲ့ Global Connection လိုမျိုးထိမ်းပြီး သုံးလို့ရပါတယ်။ ဒီလိုနေရာမျိုးမှာ Singleton Pattern ဟာအလွန်အသုံးကျပါတယ်။

Performance Issue

အထက်ကဟာနဲ့တော့ မဆိုင်ပါဘူး စကားစပ်မိလို့ရေးတာပါ။ ဖြစ်နိုင်ရင် Cost များစေမယ့် Statement မှန်ရင် Loop လိုဟာထဲမှာ မရေးသင့်ဘူး နည်းရင်မသိသာပေမယ့် များလာရင်တော့ တော်တော်လေးသိသာတယ်။

for(int i=0; i<10; i++)
{
    int temp=0;
    .......
}

နည်းနည်းယှဉ်ကြည့်ပါ

int temp;
for(int i=0; i<10; i++)
{
    temp=0;
    .......
}

for(int i=0; i<a.getsize(); i++)
   cout<<i;

နည်းနည်းယှဉ်ကြည့်ပါ

int max=a.getsize();
for(int i=0; i<max; i++)
   cout<<i;

ဒါလေးတွေက ကပ်သီးကပ်သပ်လေးတွေကို ပြောထားတာ မသိသာဘူး ဒါပေမယ့် အကြိမ်ရေ သိန်းချီ သန်းချီပြီ Loop ဆိုရင်တော့ သိသာလာပါလိမ့်မယ်။

for(int i=0; i<100000; i++)
{
       con.open();
       com.execute();
       con.close()
}

ဒါမျိုးဆိုလို့ကတော့ အင်မတန်ကောင်းတဲ့ Performance မျိုးမမျှော်လင့်ပါနဲ့တော့။ ဒါကြောင့် Singleton လို Pattern တွေနဲ့ကိုယ်မလုပ်စေချင်တဲ့ Object အရေအတွက်ထက် မပိုအောင်ထိမ်းချုပ်ထားရပါတယ်။ ဒါကတော့ Singleton ကို Performance အမြင်ကနေ ပြောထားတာပါ နောက်ထပ်ဘယ်ဘက်ကလည်း မြင်လို့ရမလဲဆိုတော့ Data Secure ဖြစ်ဖို့အတွက် Object တစ်ခုတည်းကနေပဲ တာဝန်ယူကိုင်တွယ်တဲ့ နေရာမှလည်း Singleton ဟာအသုံးတာပါပဲ။ နောက်တစ်ခါကျရင်တော့ ကိုယ်တိုင်ရေးထားတဲ့ Code နဲ့ နမူနာပြောပေးပါမယ် ဒီတစ်ခါတော့ ရေးချိန်မရလို့ လွယ်တာပဲ ပြထားလိုက်ပါတယ်။

thar5oe

ကျေးဇူးပဲကိုလူပျိုကြီးရေ

ရုံးမှာ ကျွန်တော့်ကို ခဏခဏပြောတဲ့ singleton သုံး ပါဆိုတာ ဒိစာမဖတ်ခင်အချိန်ထိ သေချာကိုမသိဘူး။ ကိုယ်ထင်တာပဲစွတ်လုပ်နေတာ သူတို့ကလဲ ဘာမှဆက်ပြောတော့တာနဲ့ မှန်တယ်ထင်နေခဲ့တာ အခုတော့မှ မှားနေမှန်းသိတယ်။ :):)

ကျေးဇူးဗျာ။ တကယ်တင်တာပါ။

သားဆိုး

CalmHill

စာမရေးတာလည်းကြာပါပြီ ဒီတစ်ခါတော့ Object Pool အကြောင်းဆက်ပြောကြတာပေါ့။ ဖတ်လက်စလူတောင် အဆက်အစပ်ပြတ်ပြီး မေ့နေလောက်ပါပြီ။:D ထူးထူးဆန်းဆန်းတော့ မဟုတ်ပါဘူး အထူးသဖြင့်တော့ Database Server နဲ့ချိတ်ဆက်ပြီး သုံးတဲ့နေရာမှာ Resource တွေအကြောင်းမဲ့ ကုန်ဆုံးတတ်ပါတယ် အခုနောက်ပိုင်းပိုဆိုးပါတယ် .Net Platform စထွက်ကာစလောက်ကနေစပြီးတော့ Connection တွေကို ကိုယ်တိုင်မကိုင်တွယ် ကြတော့ပါဘူး။ Drag and Drop လုပ်ငန်းတွေနဲ့ Program ရေးစပြုလာပါပြီ တစ်ကယ်ကတော့ Visual Studio 6.0 မှာ Data Environment ဆိုတာကနေ စပြီးတော့ Drag and Drop ကိစ္စတွေစခဲ့တာပါလေ။ အဲဒါတွေကြောင့်လည်း Connection Pool လုပ်လေ့မရှိကြတော့ သိပ်မလုပ်တတ်ကြတော့ပါဘူး။ Java ကတော့ Drag and Drop နဲ့ Database Application ရေးလို့မရပါဘူး ရေးချင်ရင်လည်း ကိုယ်တိုင်ပဲရေးရပါတယ်။ Java ကလည်း အဲဒါမျိုးတွေ အဓိကရေးဖို့ ထုတ်တာမဟုတ်တော့ ဘယ်သူမှလည်း မရေးကြပါဘူးလေ။

Database Application တစ်ခုရေးထားတာကို ကြည့်မယ်ဆိုရင် ပထမဆုံး Database Server ကို Connect လုပ်ရတယ် နောက်ပြီးတော့ Record တွေကိုဖတ်ရတယ်။ ဖတ်လို့ရတဲ့ Record ကိုပြင်လိုပြင်ဖျက်လိုဖျက် ဒါကတော့နောက်ပိုင်းကိစ္စ။ ဒီတော့ Connect လုပ်တဲ့အပိုင်းကို စဉ်းစားကြည့်ရရင် Client စက်ကနေ Database Server တင်ထားတဲ့စက်ကို Network ကနေတစ်ဆင့် Initiate လုပ်ရတယ် User Name & Password ပေးရတယ် နောက်ပြီး Server ကနေ Connection Success or Fail ကိုစောင့်ရတယ် နည်းနည်းနောနော I/O Process မဟုတ်ဘူး။ နောက်ပြီးတော့ Record တွေဖတ်လိုက်တယ်ဆိုကြပါစို့ Record 1000 လောက်ဖတ်တယ်ဆိုလို့ရှိရင် အကုန်လုံးကို Network ကနေတစ်ဆင့် Client ထဲက Memory ထဲကိုဆွဲချရမယ်။

ဒီတော့ လိုချင်တိုင်း Connection ကိုခဏခဏ ဖွင့်နေလို့ကလည်းမဖြစ်ဘူး။ Data တွေလိုတိုင်းလည်း အခါခါဖတ်ခိုင်းနေလို့လည်း မသင့်လျော်ဘူး ဒါ့ကြောင့် ကိုယ်သုံးမယ့် Object တွေရဲ့ Create လုပ်ရမယ့် တန်ဖိုးကများနေတယ်ဆိုရင် အဲဒီ့ Object တွေကိုအခါခါ Create မလုပ်ပဲ လုံးဝမသုံးတဲ့အချိန်အထိ ထိမ်းထားဖို့လိုပါတယ် အဲဒါကို Object Pool လုပ်တယ်လို့ခေါ်ပါတယ်။ ဘာမှထူးထူးဆန်းဆန်းမဟုတ်ပါဘူး အမြဲပြန်သုံးလို့ရအောင် Object Scope ကို အမြင့်မှာထားလိုက်ပြီးတော့ ပြန်ပြန်ယူသုံးတာကိုခေါ်တာပါ။ ဥပမာကို UML ပုံနဲ့ဆွဲရင်တော့ အောက်မှာလိုပြလို့ရပါတယ်။ Code ကတော့ ဘာမှခက်ခက်ခဲခဲ မဟုတ်လို့ရေးမပြတော့ပါဘူး။

သုံးတာတော့ဟုတ်ပါပြီ ဒါပေမယ့် ဆိုးကျိုးတွေလည်းရှိပါတယ် Object ကို Pool လုပ်တယ်ဆိုတော့ Memory ထဲမှာထားရပါလိမ့်မယ် ဒါဟာလည်း ကြီးမားတဲ့ Cost ပါပဲ ဒါကြောင့် မလိုအပ်ပဲထိမ်းမထားဖို့လည်း အရေးကြီးပါတယ်။ နောက်ပြီးတော့ Web Application Programming တော်တော်များများမှာ Object Pool အယူအဆကို သုံးလို့မရနိုင်ပါဘူး။ ဘာလို့လည်းဆိုတော့ Web Programming ဆိုတာက ဘာနဲ့ပဲရေးတယ် ပြောပြောပါ အဓိကကတော့ CGI Program တစ်ခုက HTML ကို Dynamically Generate လုပ်ပေးတယ် အဲဒီမှာ Database Connection တွေသုံးချင်သုံးမယ် သူ့ရဲ့ Scope ကတော့ HTML Generate လုပ်ပြီးရင် ပြီးဆုံးတာဖြစ်လို့ နောက်ထပ် Page Loading အတွက် Connection Pool လုပ်ဖို့ မဖြစ်နိုင်ပါဘူး။ Object Pool လုပ်တဲ့ကိစ္စဟာ ကိုယ်ပိုင် Server တွေရေးတဲ့နေရာပဲဖြစ်ဖြစ် Client - Server Application တွေရေးတဲ့နေရာပဲဖြစ်ဖြစ် Performance အတွက်အရေးကြီးနေမှာပါ။

azure

အားပေးနေပါတယ် ကိုလူပျိုကြီး။ ဆက်လက်ရေးပေးပါဦး ခင်ဗျာ။ ကျေးဇူးတင်ပါ၏၊

azure :)

CalmHill

Blog မှာ စေတန်လာပြီး OOP လို့အော်သွားမှ ရေးလက်စကို ပြန်သတိရပါတယ် မေ့နေတာကိုကြာပါပြီ။ :D ဒီတစ်ခါတော့လွယ်လွယ်ကူကူ Pattern တစ်ခုကို ဆက်ပါဦးမယ်။ ဒီတစ်ခါတော့ Factory Class အကြောင်းနည်းနည်းဆွေးနွေးကြတာပေါ့။ Class တစ်ခုကို Instantiate လုပ်ရင် Object ဖြစ်တယ်ဆိုတာ သိကြပါတယ် ရလာတဲ့ Object ကိုသုံးကြရတာပါ။ ဒါဆိုရင် Object တစ်ခုဘယ်လို Create လုပ်ပါသလဲဆိုရင် လွယ်လွယ်ကူကူရေးရင် Class1 var1 = new Class1() လို့ရေးလေ့ရှိမှာပါ။ ဒီနေရာမှာတစ်ခု အရေးကြီးတာရှိပါတယ် ကျောင်းသင်ခန်းစာထဲက Class လေးတွေက သေးသေးလေးတွေပါ တစ်ကယ်အသုံးချတဲ့ Class တွေဟာရှုပ်ထွေးကောင်းရှုပ်ထွေးပါလိမ့်မယ် ဥပမာပြောရရင် Create မလုပ်ခင်မှာ Initialize လုပ်မယ့် Data တွေမှန်ကန်သလား အခြားသော စစ်ဆေးရမယ့်အခြေအနေတွေရှိနေသလား အဲဒါတွေကို Create မလုပ်ခင်မှာစစ်ဆေးရပါမယ်။ ဒါဆိုရင် Class ရေးတဲ့လူနဲ့ Class ကိုသုံးမယ့်လူဟာ တစ်ယောက်တည်း မဟုတ်ရင်ပြဿနာရှိပါတယ်။ နောက်ပြီးတော့ Class ပေးလိုက်လို့ Source ကိုပေးလိုက်တယ်လို့လည်း မထင်စေချင်ဘူး Compiled လုပ်ထားတဲ့ Components လည်းဖြစ်နိုင်ပါတယ် အဲဒါဆိုရင်အထဲမှာ ဘယ်လိုရေးထားမှန်းလည်း မသိနိုင်ပါဘူး။

ဒီအခက်အခဲတွေကြောင့် Object တွေကို Create လုပ်ဖို့အတွက် Client အနေနဲ့ Class အကြောင်းအသေးစိတ် သိစရာမလိုပဲ Instantiate လုပ်ပေးနိုင်တဲ့ နည်းလမ်းလိုအပ်ပါတယ်။ ဒီနေရာမှာ Client ဆိုတာ လက်ဝေခံ Programmer ကိုဆိုလိုပါတယ်။ ဒါကြောင့် Component ကိုရေးတဲ့ Programmer က ရေးထားတဲ့ Class တွေကို လွယ်လွယ်ကူကူ Instantiate လုပ်နိုင်အောင် Class တွေထပ်ရေးရပါတယ် အဲဒီ့ Class တွေက Create လုပ်မယ့် Object အတွက် Properties တွေကို Parameter တွေအဖြစ်လက်ခံပြီး Client ကိုယ်စား Instantiate လုပ်ပေးပါတယ်။ တစ်ခါတစ်ရံမှာတော့ Properties တွေပေးလိုက်တာ မဟုတ်ပဲ Create လုပ်ဖို့ Option တွေလည်းဖြစ်နိုင်ပါတယ်။ အဲဒီ့အလုပ်တွေလုပ်တဲ့ Class ကို Factory Class လို့ခေါ်ပါတယ်။ စစ်ဆေးစရာရှိတဲ့ Prerequisites များကို အဲဒီ့ Factory Class ထဲမှာပဲ စစ်ဆေးပါတယ် လိုအပ်ရင် လူနားလည်လွယ်မည့် Error တွေကို Raise လုပ်ပေးပါတယ်။ ဒါ့ကြောင့် ယူသုံးမယ့် လက်ဝေခံ Programmer အနေနဲ့လည်း အထဲကရေးထားတာကို အသေးစိတ်သိစရာမလိုတဲ့အတွက် ရေးရတာမြန်ပါတယ် Component ကိုရေးတဲ့ Programmer ကလည်း အာပေါက်အောင် ပြောစရာမလိုလို့ အလုပ်ရှုပ်သက်သာသလို Source မပေးချင်ရင်လည်း Compiled Component အဖြစ်လည်းပေးလို့ အဆင်ပြေပါတယ်။

General အနေနဲ့ကတော့ အောက်မှာပြထားတဲ့ UML အတိုင်း Factory Class ကိုမြင်နိုင်ပါတယ် ရှုပ်ထွေးတဲ့ Class Diagram တွေမဟုတ်လို့ နားလည်လွယ်နိုင်မှာပါ။

[CENTER]

[/CENTER]

နမူနာအနေနဲ့ကတော့ အောက်မှာပြထားတဲ့ UML ကိုကြည့်နိုင်ပါတယ်။ Product Class ကို Instantiate လုပ်ပေးတဲ့ Factory တစ်ခုနဲ့ Factory ကိုယူသုံးတဲ့ Client Class ကိုပြထားပါတယ်။

[CENTER]

[/CENTER]

Example Source Code အဖြစ်လည်း FactoryProduct ကိုပြထားပါတယ်။

public abstract class ProductFactory{
    public Product createProduct(String ProductID){
        if (id==ID1)
            return new OneProduct();
        if (id==ID2) return
            return new AnotherProduct();
        ... // so on for the other Ids
        
        return null; //if the id doesn't have any of the expected values
    }
    ...
}

လွယ်ကူတဲ့ Example Source Code ကိုသာပြထားတာဖြစ်ပါတယ်။ မူရင်းဆိုက်မှာတော့ သဘောကျစရာကောင်းတဲ့ Java နဲ့ ရေးထားတဲ့ Factory Code ကိုပြထားပါတယ်။ FactoryClass ထဲမှာ Class ကိုအသေရေးထားတာမဟုတ်ပဲ Runtime မှာသာ Reflect လုပ်ပြီးရေးပြထားတာပါ။ Reflection ကတော့ Java ရဲ့ Advance features တစ်ခုဖြစ်လို့ Java ကိုသာမန်သင်ဖူးလောက်ရုံနဲ့ နားမလည်နိုင်ပါဘူး။ Java ကျွမ်းကျင်သူ ဒါမှမဟုတ် Programming Language တည်ဆောက်ပုံနားလည်သူများကတော့ Factory Pattern မှာ Reflection ကိုဘယ်လိုသုံးတယ်ဆိုတာကို သိသွားမယ်ဆိုရင် ဖတ်ရကျိုးနပ်ပါတယ်။ အောက်မှာမူရင်းလိပ်စာကို ဖော်ပြထားပါတယ်။

http://www.oodesign.com/factory-pattern.html

အဆင့်မြင့်တဲ့ Factor Class တွေဆိုရင်တော့ Factory Class တွေအတွက်ပါ Generalization လုပ်ထားပါတယ်။ ဘယ်လိုနေရာတွေမှာ အသုံးတည့်နိုင်မလဲဆိုရင်တော့ ကွဲပြားတဲ့ Product တွေအတွက် Factory တစ်ခုတည်းမရေးချင်ပဲ သီးသန့်စီ Implement လုပ်လို့ရပါတယ်။ Implement လုပ်ထားတဲ့ Factory တွေကိုလည်း Generalize လုပ်ထားပြီးဖြစ်တဲ့အတွက် Polymorphic အရလွယ်ကူစွာ ထိမ်းချုပ်ပြီးသုံးလို့ရပါလိမ့်မယ်။ UML Diagram ကိုလည်းအောက်မှ ဖော်ပြထားပါတယ်။

[CENTER]

[/CENTER]

xinxin82

ဆက်ရေးပေးပါဦးဗျာ.. အားပေးနေပါတယ်.. အခုလို ပညာဒါနလုပ်တာကိုလည်း ကျေးဇူးတင်ပါတယ်ဗျာ.. အခုသင်ခန်းစာ တစ်ခုလုံး save ယူသွားပါတယ်..

wha_ngelay

လူပျိုကြီး said:
Software Architecture Changes ဆိုတာက ပြောမယ်ဆိုရင် တော်တော်ဆိုးပါတယ်။ Backward Compatible မဖြစ်တာကပိုဆိုးပါတယ်။ Maintainable ဖြစ်တဲ့ Software ဆိုတာက နောင်တစ်ချိန်မှာ အပြောင်းအလဲ ဖြစ်ခဲ့ရင် Developer တွေအတွက် ဘယ်လောက် အထောက်အကူပေးမလဲဆိုတဲ့ အတိုင်းအတာမှာ မှီခိုပါတယ်။ သူနဲ့အပြိုင်စဉ်းစားရမှာကတော့ Scalable ကိစ္စကိုပါ။ ဘယ် Software မဆို နောင်တစ်ချိန်မှာ Function အသစ်တွေထပ် ထည့်ရမှာပါပဲ ထပ်ထည့်လိုက်တဲ့ Function အသစ်တွေဟာ အရင်ရှိပြီးသားကို မထိခိုက်ဘူးဆိုရင် ဒါဟာ Scalable ဖြစ်တယ်ပြောရမှာပါ။ UML နဲ့ ဒီဇိုင်းဆွဲတယ်ဆိုတာကလည်း ဘယ်အချိန်မှာ ပြင်ဆင်ရမယ် ပြင်ရင် ဘယ်အပိုင်းတွေကို ထိခိုက်သွားမယ်ဆိုတာကို မြင်သာအောင် ဆွဲတယ်ဆိုလည်း ပြောလို့ရပါတယ်။

ကျွန်တော့် အတွေ့အကြုံအရဆိုရင် ဆွဲပြီးသား အားလုံးသဘောတူပြီးသား ဒီဇိုင်းတစ်ခုကို Implement လုပ်နေရင်းမှာ ပြင်ချင်ရင်မလွယ်တော့ပါဘူး။ ပြင်လိုက်ရင် အပိုင်းလိုက်ခွဲပြီး Implement လုပ်နေရတာ ဖြစ်လို့ တစ်နေရာပြောင်းလဲတာနဲ့ တစ်ခြားထိခိုက်မယ့် အပိုင်းတွေကိုပါ စဉ်းစားရပါတယ်။ Implement လုပ်နေရင်း Change Management လုပ်ရတာ အင်မတန်ခက်ခဲသလို ကုန်ကျစရိတ်လည်း များပါတယ်။ ဒါကြောင့် အတွေ့အကြုံရင့်တဲ့ Software Architect တွေသာလုပ်ရဲပါတယ်။ Implement ပြီးသွားရင်တော့ နောင်ကိုဆက်ပြီး တိုးချဲ့ဖို့အတွက် လက်ရှိဒီဇိုင်းကို မပြင်သင့်တော့ပါ။ ဖြစ်နိုင်ရင် ရေးပြီးသား Code တွေထဲမှာ အမှားပြင်တာကလွဲရင် နောက်ထပ် Version အတွက် ထပ်ပြီး Code တွေထပ်မထည့်သင့်ပါ။ Version အသစ်အတွက် ရည်ရွယ်မယ်ဆိုရင် ဖြစ်နိုင်သမျှ Inherit လုပ်ပြီး ထပ်ပြီးတိုးချဲ့ဖို့သာ ကြိုးစားသင့်ပါတယ်။ ဒါကြောင့် Object-Oriented Design တွေဟာ Software အကြီးတွေ ရေးမယ်ဆိုရင် မရှိမဖြစ် လိုအပ်လာပါတယ်။

အခုနောက်ပိုင်းမှာ Mission Critical မဟုတ်ရင်တော့ Open Source ကိုလူတိုင်းနီးနီး သုံးလာကြပါပြီ။ ဒီတော့ အခုခေတ် Developer တွေက အရင်ကနဲ့နည်းနည်း ကွဲပြားလာတာက အရင်ကတော့ ကိုယ်သုံးတဲ့ Development Tools တွေကို ဝယ်သုံးပါတယ်။ အခုနောက်ပိုင်းတော့ Development Tools တွေကိုက Open Source တွေများလာတော့ ကိုယ်သုံးတဲ့ Development Tools ကိုတစ်ခါတစ်လေ လိုအပ်ရင်ကိုယ်တိုင် ပြင်ဖို့လိုအပ်လာရင် ပြင်ရပါတယ်။ ပြဿနာက Open Source တွေရဲ့ Version တွေက လူတွေအများကြီး ဝိုင်းရေးကြပြောင်းကြ ဆိုတော့ အပြောင်းအလဲ အရမ်းမြန်ပါတယ်။ အဲဒီမှာဖြစ်လာတာက ကိုယ်သုံးဖို့ ပြောင်းထားတဲ့ Module တွေကသူတို့ထုတ်တဲ့ နောက်ပိုင်း Version တွေမှာ Architecture ကိုပြောင်းပြီး တစ်ခြားပို့လိုက်လို့ကတော့ ကိုယ့်ဟာကတော့ အသစ်မှာ သုံးမရတော့ပါဘူး။ Version အဟောငး်ကိုပဲ ဆက်သုံးနေလို့ကလည်း မဖြစ်ပါဘူး ကိုယ်ရေးထားတာကို သုံးဖြစ်တယ်ဆိုပေမယ့် တစ်ခြားအမှားတွေကိုတော့ ကိုယ်တိုင်လည်း မပြင်နိုင်ပါဘူး။

အရင်တစ်ပါတ်လောက်က PostgreSQL ကိုအထဲက Module တွေကို ပြင်ထားတဲ့ System တစ်ခုကို Performance စမ်းဖို့အကြောင်းပေါ်ပါတယ်။ ပြင်ထားတာတွေက ၂၀၀၈ နှစ်အစပိုင်းလောက်က ပြင်ထားတာပါ။ ပြင်တယ်ဆိုပေမယ့် သူ့ဟာကိုပြင်တာမဟုတ်ပဲ ကိုယ်လိုချင်တဲ့ Feature တစ်ခုရဖို့အတွက် အသစ်ထပ်ထည့်ထားတာပါ။ ဒါပေမယ့် သူ့ထဲကပါပြီးသားတွေကို ခေါ်သုံးရတာတွေလည်း ရှိပါတယ်။ စမ်းမယ်ဆိုတော့ Compile လုပ်တာကိုက တော်တော်ခက်ပါတယ် နောက်တော့ တော်တော်လေး ကြံဖန်ပြီး လုပ်လိုက်မှ Library တစ်ခုထွက်ပါတယ်။ ထွက်လာတဲ့ Library ကို PostgreSQL မှာထပ်တပ်တာ ဘယ်လိုမှမရပါဘူး။ သုံးလေးရက်လောက် ဆက်တိုက်လုပ်တယ် မရပါဘူး မမှားပဲနဲ့ထပ်တပ်တာ မရဘူးဆိုတာ တော်တော်ထူးဆန်းပါတယ်။

နောက်ဆုံးဘယ်လိုမှ အဖြေရှာမရတာနဲ့ အကုန်တစ်စစီပြန်စစ်တော့မှ အရင်သူတို့သုံးတာက 8.1 အခုသုံးနေရတာက 8.3 ဒါပဲခြားနားတယ် ကျန်တာကတော့ အကုန်တူတယ်။ တစ်ကယ်ကတော့ အဟောင်းက အသစ်မှာမရဘူးဆိုတာ မဖြစ်နိုင်ပါဘူး Backward Compatible တော့ဖြစ်ရပါတယ်။ ဒါပေမယ့် အသေအချာစစ်လိုက်တော့ 8.1 နဲ့ 8.2 ကြားမှာ Library Function တွေကို အထဲက Code တွေကို မပြောင်းပဲ Function နာမည်တွေကို ပြောင်းထားတယ်ဆိုတာကို တွေ့ရပါတယ်။ အကုန်လုံးအသေးစိတ် ရှာကြည့်လိုက်တော့ PostgreSQL နဲ့ပါတ်သက်တဲ့ Forum တွေမှာ ပြောင်းလိုက်လို့ ပြဿနာတက်တဲ့လူတွေ ဆွေးနွေးထားကြတာ အများကြီးဖြစ်နေပါတယ်။ နာမည်ပဲပြောင်းတယ်ဆိုတော့ အကုန်လုံးပြောင်းသမျှကို Search & Replace နဲ့အကုန် ပြန်လုပ်ရပါတယ်။ ဆက်လုပ်ပြန်တော့လည်း မရပြန်ဘူး ဒါနဲ့ အပြောင်းအလဲ ထပ်ရှိသေးသလားကြည့်တော့ 8.2 နဲ့ 8.3 ကြားမှာ Library ထပ်ရေးမယ်ဆိုရင် Format ပြောင်းတယ်ဆိုပြီး ဖြစ်နေပြန်ပါတယ်။ ကိုယ့်ဟာက အရင် အဟောင်းဖြစ်နေလို့ သူ့အသစ်နဲ့ကိုက်အောင် တစ်ခါပြန်ပြောင်းရပြန်ပါတယ်။ သူတို့ဟာသူတို့ Function နာမည်တွေ မလှလို့ပြောင်းတာက ရှိပြီးသားလူတွေ ပြဿနာအကုန်တက် ကုန်ပါတယ်။

အခု MZ မှာလည်း Project အကုန်လုံးကို စမ်းလို့ ကျေနပ်တဲ့အခြေအနေ ရောက်တာနဲ့ Open Source အဖြစ်ထုတ်ပေးနေတာကို တွေ့ပါတယ်။ အိုနာဂိုင်ရယ်, Mobile အဘိဓာန်ရယ် Linux Zawgyi Keyboard ကိုအဓိကတွေ့ပါတယ်။ ကိုယ့်ပရောဂျက်ကို Version အသစ်အဖြစ်ဆက် လုပ်နေကြတာပါပဲ ဒါကြောင့် အကြံပေးချင်တာက မူရင်း Architecture ကိုမပြင်ပဲနဲ့ Extending လုပ်တဲ့နည်းကိုပဲ သုံးရင်အဆင်ပြေမယ်ထင်ပါတယ်။ တစ်ချို့ကလည်း ကိုယ်တိုင်းစမ်းကြည့်ရင်းနဲ့ ထပ်ထည့်ကြည့်ထားတာတွေ ရှိလာမယ်ဆိုရင် ရှိပြီးသားကိုပြန်ပြင်တဲ့နည်းနဲ့ Version အသစ်ထုတ်လိုက်ရင် တစ်ခြား Developer တွေ Extend လုပ်ထားတာတွေနဲ့ ပြဿနာတက်လာနိုင်ပါတယ်။ ဒါကြောင့် ရေရှည်အတွက် Maintainable & Expendable ဖြစ်အောင်လုပ်ရင် ပိုကာင်းမယ်လို့ အကြံပေးချင်ပါတယ်။ ဘာလို့လဲဆိုတော့ Commercial Software တွေ Architecture ပြောင်းတာက သူ့အထဲက Developer တွေပဲ ပြဿနာဖြစ်တာ ဆိုပေမယ့် Open Source ပြောင်းတာကတော့ အခုနောက်ပိုင်းမှာ ထိခိုက်တဲ့လူတွေပိုများပါတယ်။

ကောင်းပါတယ်ဗျို့ ။ ဆက်ပြီးရေးပါဦး ။ Page တစ်ခုလုံးကို save ထားပါတယ်။ ခုမှ OO အကြောင်းနားလည်တယ်။ အရင် က RPD နဲ့ပဲသုံးနေတာ။ခုရောပါဘဲ

gagar

UML ကို မကျဉ်းမကျယ် ရေးထားပြီး အခြေခံကစပြီး လေ့လာလို ့ ရမဲ့ စာအုပ် ၊ လက်ချာ ၊ web site link လေးများရှိရင် ကူညီပါ ။ အရေးတကြီး လိုနေလို ့ပါ။

CalmHill

http://www.oodesign.com/

အပေါ်မှာပြထားတဲ့ ဆိုက်ကိုသွားကြည့်ပါ အခြေခံတော့မဟုတ်ဘူး Design Pattern ဆိုတော့ UML နားလည်တဲ့လူ OOP ကိုနားလည်တဲ့လူပဲ ဖတ်လို့အဆင်ပြေတယ်။ ဒါပေမယ့် သူ့မှာပြထားတဲ့ Recommended Book တွေကိုရှာဖတ်ပါ အဲဒါတွေကတော့ အခြေခံအတွက်ကောင်းပါလိမ့်မယ်။

Pookey

အခုလိုရှင်းလင်းပြောပြပေးလို.ကျေးဇူး အများကြီးတင်ပါတယ်။ ဆက်ရေးပါအုံး အကို။ စောင်.ပြီးသင်ယူနေပါတယ်. :rolleyes:
သင်ကြားပေးသောသူများကိုကျေးဇူးအထူးတင်လျက်......:77:

CalmHill

အင်း... ရေးတော့ ရေးပါဦးမယ် မအားဘူးဖြစ်နေတယ် အခုရက်ပိုင်း ဝင်မကြည့်နိုင်တာကို ၁ ပါတ်လောက်ရှိနေပြီ ကြိုးစားပြီးရေးပါဦးမယ်။ :smile:

MYSTERY ZILLION

မင်္ဂလာပါ!

အမျိုးအစားများ

In this Discussion