Java နှင့် Object Oriented သဘော​တရား​

Java Programming ကို လေ့​လာ​ရာ​တွင် လေ့​လာ​သူ​တစ်​ဦး​အနေ​နှင့် ရင်ဆိုင်​ရ​မည့် ပြဿနာ များ​ထဲ​တွင် Object Oriented သည်​လည်း အဓိက အခန်း​မှ ပါဝင်​နေ​၏။ Object Oriented နှင့်​ပတ်သက်​သော ဘာသာ​ရပ်​များ၊ စာအုပ်​များ၊ ရှင်းလင်း​ချက်​များ များ​စွာ​ရှိ​ကြ​ပါ​၏။ သို့ရာတွင် Object Oriented သည် နားလည်​ရ​ခက်​သည်​ဟု ပြော​နေ​သူ အများ​အပြား​ရှိ​နေ​ဆဲ​ပင်။ အချို့​သော​သူ​များ​သည် Object Oriented ကို နားလည်​သည်​ဟု ပြော​ကြ​၏။ ဒါ​ဆို​ရင် Polymorphism ကို​နားလည်​ပြီး Coding တွေ​မှာ အသုံးပြု​နေ​သလား​ဟု မေး​ပါ​က အဖြေ​ခက်​နေ​တတ်​၏။

သို့ရာတွင် အံ့​သြ​စရာ ကောင်း​လောက်​အောင်​ပင် Object Oriented ကို ခက်ခဲ​လှ​ပါ​သည်​ဟု ပြော​နေ​ကြ​ပေ​မယ့် Inheritance ကို သိ​လား​လို့​မေး​လျှင် မှန်ကန်စွာ နားလည်​ထား တတ်​ကြ​၏။ ဒါ​ဆို​လျှင် ဘာ​လို့ Object Oriented ကို ခက်​တယ်​လို့ ထင်​နေ​ရ​တာ​လဲ။

အဲ့​ဒီ အဖြေ​ဟာ နောက်ထပ်​မေး​မည့် မေးခွန်း​၏ နောက်​ကွယ်​တွင် တည်​ရှိ​လိမ့်​မည် ဟု​ထင်​ပါ​သည်။ Inheritance ကို အသုံးပြု​ခြင်း​၏ ကောင်းကျိုး၊ ဆိုး​ကျိုး​တွေ​ကို သိ​လား​ဟု​မေး​ပါ​မည်။ အတော်​များ⁠များ​က Inheritance မှာ ဆိုး​ကျိုး​တွေ ရှိ​လို့​လား​ဟု ပြန်​မေး​ကြ​မည်။ အဲ့​ဒီ​နေရာ​မှာ ပြဿနာ​က စ​ပါ​တော့​သည်။ Object Oriented ကို နား​မ​လည်​စေသော အခြေ​ခံ​သည် ဤ​နေရာ​မှ စတင်​ပါ​တော့​သည်။

Object Oriented ၏ သဘော​တရား​သည် လွန်စွာ​ကောင်းမွန်​သည်မှာ မှန်​၏။ သို့ရာတွင် Java Program တစ်​ခု​မှ Object Oriented ကို အသုံးပြု​ရာ​တွင် အသုံးပြု​ပုံ မှားယွင်း​ခဲ့​ပါ​က လုံး​ဝ အသုံး​မ​ဝင်​သော Code များ​ကို ရေး​မိ​သွား​နိုင်​သည် အထိ အန္တ​ရယ်​ရှိ​ပါ​သည်။

ကျွှန်တော်​တို့ OOP ဖြစ်​ရင်​ပြီး​ရော ဆို​ပြီး မှားယွင်း​သော အသုံး​ချ​မှု့​များ​မှ ကင်း​ဝေး​စေ​ရန်၊ Object Oriented ရဲ့ အဓိက​ကျ​သော Encapsulation, Inheritance, Polymorphism အစ​ရှိ​တဲ့ အခြေ​ခံ သဘော​တရား​များ​မှ စ​ပြီး ပြန်လည်​လေ့​လာ​သွား​မည် ဖြစ်​သည်။

Encapsulation ကို အသုံးပြု​ပါ

Encapsulation သည် OOP ရဲ့ အခြေ​ခံ​ကျ​တဲ့ အတွေး​အခေါ်​တစ်​ခု​ဖြစ်​၏။ Encapsulation က ဘာ​လို့​လို​အပ်​တာ​လဲ ဆို​တာ​ကို မ​စဉ်းစား​ခင် OOPရဲ့ သမိုင်း​ကို ပြန်​ကြည့်⁠ကြည့်​ကြ​ရအောင်။ Software Engineering လောက​မှာ OOP က စတင်​နေရာ ရ​လာ​ခဲ့​တာ​ကတော့ လွန်​ခဲ့​တဲ့ နှစ်​၂​၀​ခန့်​က​ဖြစ်​၏။ ကမ္ဘာ​တ​ဝှမ်း​၌ IT နည်း​ပညာ​ကို စီးပွား​ရေး​အခြေ​ခံ တွေ​မှာ၊ လူ​နေ​မှု့​စနစ်​ရဲ့ အခြေ​ခံ​တွေ​မှာ ရင်းနှီး​မြှုပ်​နှံ​မှု့​တွေ​ကို အပြိုင်​အဆိုင် ပြုလုပ်​နေ​တဲ့ ကာလ​ဖြစ်​ခဲ့​၏။ ထို​ခေတ်​သည် System လို​အပ်​မှု့​များ​နှင့် စာ​လျှင် IT Engineerရဲ့ အရေအတွက်​ဟာ အလွန်​နည်းပါး ခဲ့​သော ကာလ​လည်း​ဖြစ်​၏။

အသစ်အသစ်တွေကို ပြန်​ရေး နေ​သည်​နှင့်​စာ​လျှင် ရေးထား​ပြီး​သား System တွေ​ကို ဘယ်​လို​ပြန် အသုံး​ချ​နိုင်​အောင် လုပ်​မ​လဲဆို​တာ IT သမား​တွေ အတွက် မ​ရှိ​မ​ဖြစ်​လို​အပ်ခဲ့​တဲ့ လို​အပ်​ချက်​တစ်​ခု ဖြစ်​ခဲ့​၏။ Software ရဲ့ အစိတ်​အပိုင်း​တွေ​ကို ရုပ်​ပစ္စည်း အဖြစ်​ကြည့်​မြင်​ပြီး၊ အစိတ်​အပိုင်း​တွေ​ကို စုပေါင်း​အသုံး​ချ​ခြင်း အား​ဖြင့် System တစ်​ခု​ကို တည်ဆောက်​သော OOP ရဲ့ တွေးခေါ်​မှု့​တွေ​ဟာ ရေး​ပြီး​သား Software တွေ​ကို ပြန်လည်​အသုံး​ချ​လို​တဲ့ အဲ့​ဒီ​ခေတ်​ရဲ့ လို​အပ်​ချက်​နှင့် ကိုက်​ညီ​နေ​ခဲ့​၏။
ထို့​ကြောင့် OOP ကို အခြေ​ခံ​တဲ့ Programming ဘာသာ​ရပ်​တွေ အများ​အပြား ထွက်ပေါ်​လာ​ရ​ခြင်း ဖြစ်​သည်။ ကျွှန်တော်​တို့ OOP ကို ဘာ​လို့​အသုံးပြု​ခဲ့​ကြ​တယ် ဆို​တာ​ကို​သဘောပေါက်​ပြီး​ရင် Encapsulation ဘက်​ကို ပြန်​စဉ်းစား​ကြည့်​ကြ​ရအောင်။

Encapsulation ဆို​သည်မှာ လုံခြုံ​အောင် ထုတ်​သိမ်းထား​ခြင်း​ဟု အဓိပ္ပါယ် ရ​ပါ​သည်။ ဘာ​ကြောင့် Encapsulation လုပ်​ဖို့​လို​တာ​လဲ​ဟု စဉ်းစား​လျှင် OOP ရဲ့ လို​အပ်​ချက်​တွင် အဖြေ​ရှိ​ပါ​သည်။ ရေးသား​ထား​သော Object တစ်​ခု​ကို ရေးသား​သူ တစ်​ယောက်​တည်း​က အသုံးပြု​မည် မဟုတ်။ ထို့​အပြင် ရေးသား​ပြီး အချိန် အတန်​ကြာ​မှ ပြန်လည်​အသုံး​ချ​သည့်​အခါ​လည်း ရှိ​ပါ​လိမ့်​မည်။ Object ၏ အချက်အလက်​တွေ​နဲ့ လုပ်ဆောင်​ချက်​တွေ​ကို အခြား​သော နေရာ​များ​မှ နှစ်သက်​သ​လို အသုံးပြု​ကြ​မည် ဆို​လျှင် ခက်​ပေ​မည်။ အဲ့​ဒီ​အတွက် Object တစ်​ခု​က ပိုင်ဆိုင်​တဲ့ အချက်အလက်​နဲ့ လုပ်ဆောင်​ချက်​တွေ​ကို ပြင်​ပ​မှ မ​မြင်​နိုင်​ရန် ဖုံးကွယ်​ထား​ဖို့ လို​အပ်​ပေ​သည်။ ဤ​ကဲ့သို့ ဖုံးကွယ်​ခြင်း​ကို Encapsulation ဟုခေါ်​၏။

ကျွှန်တော်​တို့ Java မှာ Encapsulation ကို ဘယ်​လို​လုပ်​လဲ ဆို​တာ​ကို လက်တွေ့ Code တွေ​ရေး​ကြည့်​ကြ​ရအောင်။ အောက်​ပါ User.java ကို ကြည့်​ပါ။ Encapsulation ကို အသုံး​မ​ပြု​ပဲ ရေးသား​ထား​ခြင်း ဖြစ်​သည်။

public class User {

        public String name;
        public int age;

        public User(String name, int age) {
                this.name = name;
                this.age = age;
        }
} 

အထက်​ပါ User Class ၏ အချက်အလက်​များ ဖြစ်​ကြ​သော name, age နှင့် Constructor ဖြစ်​သော User(String name, int age) သည် public များ​ဖြစ်​ကြ​၍ OOP ၏​အမြင်​မှ​ဆို​လျှင် လုံခြုံ​မှု့​မ​ရှိ​ဟု သတ်​မှတ်​နိုင်​သည်။ ဟုတ်​ပြီ၊ လုံခြုံ​မှု့​ရှိ​အောင် Encapsulation လုပ်​ကြ​စို့။ အောက်​ပါ Src Code များ​သည် public ကို private အဖြစ်​ပြောင်း​လည်း​ပြီး Encapsulation လုပ်​ထား​သော Code များ​ဖြစ်​၏။

public class User {

        private String name;
        private int age;

        private User(String name, int age) {
                this.name = name;
                this.age = age;
        }
} 

အထက်​ပါ​အတိုင်း Encapsulation သည် လွယ်ကူ​လှ​ပေ​သည်။ သို့ရာတွင် ဤ​အတိုင်း​ဆို​ပါ​က အသုံးဝင်​မည် မဟုတ်​ပေ။ Constructor က private ဖြစ်​နေ​ပါ​သ​ဖြင့် instance ကို လုပ်​ယူ​နိုင်​မည်​မဟုတ်။ ဤ​နေရာ​သည် ရွေးချယ်​ရန် အနည်းငယ် ခက်ခဲ ပေ​သည်။ package အတူတူ အတွင်း​မှာ​သုံး​မှာ​လား၊ ဒါ​ဆို​ရင် private ကို ဖြုတ်​လိုက်​ရုံ​ပင်။ ဒါ​မှ​မဟုတ် package အပြင်​က အထိ အသုံးပြု​စေ​လို​တာ​လား။ ဆုံးဖြတ်​ရန် အနည်းငယ် ခက်ခဲ​လှ​၏။ဦးစွာ ဤ​နေရာ​တွင် Constructor ကို public အဖြစ် ပြောင်း​လည်း​ပါ​မည်။ ဤသို့​ပြောင်း​လည်း​ခြင်း အား​ဖြင့် package ထဲ​မှာ​ရော အပြင်​မှာ​ပါ instance ကို လုပ်​ယူ​နိုင်​မည် ဖြစ်​၏။

သို့ရာတွင် အခြား​သော ပြဿနာ​လည်း ရှိ​ပါ​သေး​သည်။ ပိုင်ဆိုင်​သော အချက်အလက်​များ​ကို ပြောင်း​လည်း​၍ မ​ရ​နိုင်​ပေ။ age အချက်အလက်​သည် နှစ်​တိုင်း ပြောင်း​လည်း​နိုင်​ပါ​သ​ဖြင့် ပြင်​ပ​မှ ပြောင်း​လည်း​မ​ရ​နိုင်​ခြင်း​သည် သိပ်​မ​ကောင်း​လှ​ပေ။ public အဖြစ်​ပြောင်း​လည်း လိုက်​ပြန်​ရင်​လည်း မ​ဖြစ်​နိုင်​တဲ့ အသက်​တွေ (အနှုတ်​တန်ဖိုး) သတ်​မှတ်​သွား​နိုင်​သည်။ ဤ​နေရာ​တွင် Encapsulation ကို စောင့်​စည်း​ရင်း ပြင်​ပ​ကို​လည်း ပြုပြင်​နိုင်​အောင် မ​လုပ်​နိုင်​ဘူး​လား​ဟု စဉ်းစား​စရာ ဖြစ်လာ​သည်။ ဤ​ကဲ့သို့ အခြေအနေ​မျိုး​တွင် Access Method များ​သည် အသုံးဝင်​လှ​ပေ​သည်။

public void setAge(int age) {
        if(age > this.age) {
                this.age = age;
        }
} 

အထက်ပါ setAge(int age) လုပ်ဆောင်​ချက်​ကို အသုံးပြု​မည် ဆို​ပါ​က

• User ၏ age အချက်အလက်​သည် private အတိုင်း​ပင်​ဖြစ်​၏။
• setAgeလုပ်ဆောင်​ချက်​ကို အသုံးပြု​မည် ဆို​ပါ​က ပြင်​ပ​မှ​လည်း အချက်အလက်​များ​ကို ပြုပြင်​ပြောင်း​လည်း​နိုင်​မည် ဖြစ်​သည်။
• setAge လုပ်ဆောင်​ချက် အတွင်း​တွင်​လည်း age သည် Object မှ​ပိုင်ဆိုင်​သော age ထက်​ကြီး​မှ​သာ ပြောင်း​လည်း​မည်​ဟု စစ်ဆေး​နိုင်​ပါ​သ​ဖြင့် အချက်အလက်​များ​ကို လုံခြုံ​မှု့​ရှိ​စေ​ပါ​သည်။

အမြန်မှတ်ရန်

Encapsulation ပြုလုပ်မည်ဆိုပါက private မှ​စ​ပါ။ အသုံးလို​သ​လို စဉ်းစား​သွား​မည် ဆို​ပါ​က ပြင်​ပ​ကို ဖော်​ပြ​ရန်လို​တဲ့ အချက်အလက်​နဲ့ လုပ်ဆောင်​ချက်​တွေ​ကို အလိုလို မြင်​လာ​မည် ဖြစ်​သည်။