ඔබ උපුටා ගත් බ්ලොග් සටහන එහි ප්‍රකාශය තරමක් ඉක්මවා යයි. FP සැලසුම් රටා වල අවශ්‍යතාවය තුරන් නොකරයි . එෆ්පී භාෂාවලින් එකම දේ විස්තර කිරීම සඳහා “සැලසුම් රටා” යන යෙදුම පුළුල් ලෙස භාවිතා නොවේ. නමුත් ඒවා පවතී. ක්‍රියාකාරී භාෂාවන්හි “ඔබට X ගැටලුව ඇති වූ විට, Y ලෙස පෙනෙන කේතය භාවිතා කරන්න” යන ආකෘතියේ හොඳම ප්‍රායෝගික නීති ඕනෑ තරම් තිබේ, එය මූලික වශයෙන් නිර්මාණ රටාවකි.
කෙසේ වෙතත්, බොහෝ OOP විශේෂිත මෝස්තර රටා ක්‍රියාකාරී භාෂාවලට බොහෝ දුරට අදාළ නොවන බව නිවැරදිය.
සාමාන්යයෙන් මෝස්තර රටා පවතින්නේ භාෂාවේ අඩුපාඩු මඟහරවා ගැනීම සඳහා යැයි පැවසීම විශේෂයෙන් මතභේදාත්මක විය යුතු යැයි මම නොසිතමි . වෙනත් භාෂාවකට එකම ගැටළුව සුළු වශයෙන් විසඳිය හැකි නම්, වෙනත් භාෂාවක් සඳහා ඒ සඳහා මෝස්තර රටාවක් අවශ්ය නොවේ. එම භාෂාව භාවිතා කරන්නන් ගැටලුව පවතින බව නොදැන සිටිය හැක , මන්ද, එය එම භාෂාවේ ගැටලුවක් නොවන බැවිනි.
සිව්දෙනාගේ කල්ලියට මෙම ප්‍රශ්නය ගැන කීමට ඇත්තේ මෙයයි:
ක්‍රමලේඛන භාෂාව තෝරා ගැනීම වැදගත් වන්නේ එය කෙනෙකුගේ දෘෂ්ටිකෝණයට බලපෑම් කරන බැවිනි. අපගේ රටා ස්මාල්ටෝක් / සී ++ මට්ටමේ භාෂා අංග උපකල්පනය කරයි, එම තේරීම පහසුවෙන් ක්රියාත්මක කළ හැකි හා කළ නොහැකි දේ තීරණය කරයි. අපි කාර්ය පටිපාටික භාෂාවන් උපකල්පනය කළේ නම්, අපි "උරුමය", "සංසරණය" සහ "බහුමාපකය" යනුවෙන් හැඳින්වෙන මෝස්තර රටා ඇතුළත් කර තිබිය හැකිය. ඒ හා සමානව, අපගේ සමහර රටාවන්ට අඩු පොදු වස්තු-නැඹුරු භාෂාවන් විසින් සෘජුවම සහාය දක්වයි. CLOS සතුව බහු ක්‍රම තිබේ, උදාහරණයක් ලෙස, අමුත්තෙකු වැනි රටාවක අවශ්‍යතාවය අඩු කරයි. ඇත්ත වශයෙන්ම, ස්මාල්ටෝක් සහ සී ++ අතර ප්‍රමාණවත් වෙනස්කම් ඇති අතර එයින් අදහස් කරන්නේ සමහර රටා එක් භාෂාවකට වඩා පහසුවෙන් අනෙක් භාෂාවට වඩා පහසුවෙන් ප්රකාශ කළ හැකි බවයි. (උදාහරණයක් ලෙස ඉටරේටර් බලන්න.)
(ඉහත දැක්වෙන්නේ නිර්මාණ රටා හඳුන්වාදීමේ පොත, 4 වන පිටුව, 3 වන ඡේදය)
ක්‍රියාකාරී ක්‍රමලේඛනයේ ප්‍රධාන අංග අතර පළමු පන්තියේ අගයන්, ව්‍යංජන, වෙනස් කළ නොහැකි අගයන් යනාදිය ඇතුළත් වේ. OO සැලසුම් රටා එම ඕනෑම අංගයක් ආසන්න වශයෙන් ගණනය කරන බව මට නොපෙනේ.
පළමු පන්තියේ කාර්යයන් ආසන්න වශයෙන් නොවේ නම් විධාන රටාව කුමක්ද? :) එෆ්පී භාෂාවෙන්, ඔබ හුදෙක් ශ්‍රිතයක් වෙනත් ශ්‍රිතයකට තර්කය ලෙස සම්මත කරයි. OOP භාෂාවෙන්, ඔබට ශ්‍රිතය පන්තියක ඔතා තැබිය යුතු අතර, එමඟින් ඔබට ක්ෂණිකව ක්රියාත්මක කළ හැකි අතර එම වස්තුව අනෙක් ශ්‍රිතයට යොමු කළ හැකිය. බලපෑම එක හා සමානයි, නමුත් OOP හි එය සැලසුම් රටාවක් ලෙස හැඳින්වෙන අතර එයට තවත් බොහෝ කේත අවශ්ය වේ. ව්‍යංජන නොකළහොත් වියුක්ත කර්මාන්තශාලා රටාව කුමක්ද? වරකට යම් කාර්යයකට පරාමිතීන් යොමු කරන්න, ඔබ එය අවසාන වශයෙන් අමතන විට එය කුමන ආකාරයේ අගයක් විහිදුවයිද යන්න වින්‍යාස කිරීමට.
ඔව්, වඩා බලවත් හා භාවිතයට පහසු විකල්ප පවතින බැවින් GoF සැලසුම් රටා කිහිපයක් FP භාෂාවලින් අතිරික්ත වේ.
නමුත් ඇත්ත වශයෙන්ම FP භාෂාවලින් විසඳා නැති නිර්මාණ රටා තවමත් පවතී . සිංගල්ටන් එකකට සමාන FP යනු කුමක්ද? (සිංගල්ටන් යනු සාමාන්යයෙන් භාවිතා කිරීමට භයානක රටාවක් බව මොහොතකට නොසලකා හැරීම.)
එය දෙයාකාරයෙන්ම ක්රියාත්මක වේ. මා කී පරිදි, එෆ්පී හි සැලසුම් රටා ද ඇත; මිනිසුන් සාමාන්යයෙන් ඔවුන් එසේ සිතන්නේ නැත.
නමුත් ඔබ මොනාඩ්ස් හරහා දිව යන්නට ඇත. “ගෝලීය රාජ්‍යය සමඟ ගනුදෙනු කිරීම” සඳහා සැලසුම් රටාවක් නොවේ නම් ඒවා මොනවාද? ඕඕපී භාෂාවලින් එතරම් සරල ගැටළුවක් වන අතර ඒ හා සමාන මෝස්තර රටාවක් එහි නොමැත.
එය ඔබ කුමක් පමණක් වන නිසා අපි "ස්ථිතික විචල්ය වැඩිවීමක්" සඳහා නිර්මාණය රටාව අවශ්ය නැහැ, හෝ "බව සොකට් කියවීමට", කරන්න .
මොනාඩ් යනු මෝස්තර රටාවක් යැයි පැවසීම ඔවුන්ගේ සුපුරුදු මෙහෙයුම් සමඟ පූර්ණ සංඛ්‍යා පැවසීම විකාරයකි. ශුන්‍ය මූලද්‍රව්‍යය සැලසුම් රටාවකි. නැත, මොනාඩ් යනු ගණිතමය රටාවක් මිස නිර්මාණ රටාවක් නොවේ.
(පිරිසිදු) ක්‍රියාකාරී භාෂාවල, අතුරු ප්‍රති and ල සහ විකෘති තත්වයක් ඇති කළ නොහැක, ඔබ එය වටා මොනාඩ් “සැලසුම් රටාව” හෝ එකම දේට ඉඩ දීම සඳහා වෙනත් ක්‍රම සමඟ වැඩ නොකරන්නේ නම්.
මීට අමතරව, OOP (F # සහ OCaml වැනි) සඳහා සහය දක්වන ක්‍රියාකාරී භාෂාවල, මෙම භාෂාවන් භාවිතා කරන ක්‍රමලේඛකයින් අනෙක් සෑම OOP භාෂාවකටම ලබා ගත හැකි මෝස්තර රටා භාවිතා කරන බව මට පැහැදිලිය. ඇත්ත වශයෙන්ම, දැන් මම එදිනෙදා F # සහ OCaml භාවිතා කරන අතර, මම ජාවා භාෂාවෙන් ලියන විට භාවිතා කරන රටාවන්ට එදිරිව මෙම භාෂාවල භාවිතා කරන රටාවන් අතර කැපී පෙනෙන වෙනස්කම් නොමැත.
සමහර විට ඔබ තවමත් අත්‍යවශ්‍ය ලෙස සිතන නිසාද? බොහෝ දෙනෙකුට, ඔවුන්ගේ මුළු ජීවිත කාලය පුරාම අත්‍යවශ්‍ය භාෂාවන් සමඟ කටයුතු කිරීමෙන් පසු, ක්‍රියාකාරී භාෂාවක් උත්සාහ කරන විට එම පුරුද්ද අත්හැරීමට අපහසු වේ. (මම වචනාර්ථයෙන් මෙහි F #, සමහර ලස්සන විසුළු උත්සාහයන් මම දැකලා තියෙනවා සෑම ඔබ C වැඩසටහන් රැගෙන ඇති අතර, '' ඉඩ 'සමග සියලු semicolons වෙනුවට කැමති නම් මූලික වශයෙන් ලෙස, කාර්යය' ඉඩ 'ප්රකාශ හුදෙක් වැලක් විය. :))
නමුත් තවත් හැකියාවක් විය හැක්කේ ඔබ OOP භාෂාවක නිර්මාණ රටා අවශ්ය වන සුළු කාරණා විසඳන බව ඔබ නොදැන සිටීමයි.
ඔබ ව්‍යංජන භාවිතා කරන විට හෝ ශ්‍රිතයක් වෙනත් කෙනෙකුට තර්කයක් ලෙස යොමු කරන විට, OOP භාෂාවෙන් ඔබ එය කරන්නේ කෙසේදැයි සිතා බලන්න.
ක්‍රියාකාරී ක්‍රමලේඛනය මඟින් OOP සැලසුම් රටාවන්හි අවශ්‍යතාවය ඉවත් කරයි යන ප්‍රකාශයට සත්‍යතාවයක් තිබේද?
ඔව්. :) ඔබ FP භාෂාවකින් වැඩ කරන විට, ඔබට තවදුරටත් OOP විශේෂිත මෝස්තර රටා අවශ්ය නොවේ. නමුත් ඔබට තවමත් MVC හෝ වෙනත් OOP නොවන විශේෂිත දේවල් වැනි සාමාන්‍ය මෝස්තර රටා කිහිපයක් අවශ්ය වන අතර ඒ වෙනුවට ඔබට නව FP විශේෂිත “සැලසුම් රටා” කිහිපයක් අවශ්ය වේ. සෑම භාෂාවකම ඒවායේ අඩුපාඩු ඇති අතර සැලසුම් රටා සාමාන්යයෙන් අප ඒවා වටා වැඩ කරන ආකාරයයි.
කෙසේ හෝ, ඔබ මෙන්, එය වැදගත් "පිරිසිදු" ෆෙඩරල් පක්ෂය භාෂා ඔබේ අත උත්සාහ කිරීමට විය හැක ML (අවම වශයෙන් ඉගෙන කටයුතු සඳහා මගේ පෞද්ගලික ප්රියතම), හෝ Haskell , ඔබ විට ඔබ නැවත වැටී කිරීමට OOP සලකන්න එපා නොමැති තැන මට අලුත් දෙයකට මුහුණ දී තිබේ.
අපේක්ෂා කළ පරිදි, නිර්මාණ රටාවන් "භාෂාවක අඩුපාඩුකම් හඳුනා ගැනීම" ලෙස මා අර්ථ දැක්වීමට කිහිප දෙනෙක් විරුද්ධ වූහ, එබැවින් මෙන්න මගේ සාධාරණීකරණය:
දැනටමත් පවසා ඇති පරිදි, බොහෝ සැලසුම් රටා එක් ක්‍රමලේඛන ආදර්ශයකට හෝ සමහර විට එක් විශේෂිත භාෂාවකට පවා විශේෂිත වේ. බොහෝ විට, ඔවුන් එම ආදර්ශය තුළ පමණක් පවතින ගැටළු විසඳයි (එෆ්පී සඳහා මොනාඩ්ස් හෝ ඕඕපී සඳහා වියුක්ත කර්මාන්තශාලා බලන්න).
වියුක්ත කර්මාන්තශාලා රටාව FP හි නොපවතින්නේ ඇයි? එය විසඳීමට උත්සාහ කරන ගැටලුව එහි නොපවතින බැවිනි.
එබැවින්, එෆ්පී භාෂාවල නොපවතින ඕඕපී භාෂාවල ගැටලුවක් තිබේ නම්, පැහැදිලිවම එය ඕඕපී භාෂාවල අඩුපාඩුවකි. ගැටලුව විසඳිය හැකි නමුත් ඔබේ භාෂාව එසේ නොකරයි, නමුත් එය වටා වැඩ කිරීමට බොයිලර් ප්ලේට් කේතයක් ඔබෙන් අවශ්ය වේ. ඉතා මැනවින්, අපගේ ක්‍රමලේඛන භාෂාව සියලු ගැටලු ඉන්ද්‍රජාලිකව ඉවත් කිරීමට අපි කැමතියි . තවමත් පවතින ඕනෑම ගැටළුවක් ප්‍රතිපත්තිමය වශයෙන් භාෂාවේ අඩුපාඩුවක් වේ. ;)