Gradle හි ක්‍රියාත්මක කිරීම සහ සම්පාදනය කිරීම අතර ඇති වෙනස කුමක්ද?


1075

ඇන්ඩ්රොයිඩ් ශබ්දාගාර 3.0 දක්වා යාවත්කාලීන කිරීම සහ නව ව්යාපෘතියක් නිර්මාණය කිරීමෙන් පසු, මම බව දැක build.gradleඑහි නව පරායත්තයන් එකතු කිරීමට නව ක්රමයක් වෙනුවට වේ compileපවතී implementationහා වෙනුවට testCompileඇති testImplementation.

උදාහරණයක්:

 implementation 'com.android.support:appcompat-v7:25.0.0'
 testImplementation 'junit:junit:4.12'

වෙනුවට

 compile 'com.android.support:appcompat-v7:25.0.0'
 testCompile 'junit:junit:4.12'

ඔවුන් අතර ඇති වෙනස කුමක්ද සහ මා භාවිතා කළ යුත්තේ කුමක්ද?

Answers:


1324

tl; dr

ප්රතිස්ථාපනය කරන්න:

  • compileසමඟ implementation(ඔබට සංක්‍රාන්තිභාවය අවශ්‍ය නොවේ නම්) හෝ api(ඔබට සංක්‍රමණ අවශ්‍ය නම්)
  • testCompile සමග testImplementation
  • debugCompile සමග debugImplementation
  • androidTestCompile සමග androidTestImplementation
  • compileOnlyතවමත් වලංගු වේ. එය සම්පාදනය නොකොට ප්‍රතිස්ථාපනය කිරීම සඳහා 3.0 දී එකතු කරන ලදි. ( providedග්‍රේඩ්ල් හට එම භාවිත අවස්ථාව සඳහා වින්‍යාස නාමයක් නොමැති විට හඳුන්වා දුන් අතර එය මාවන් විසින් සපයන ලද විෂය පථයට නම් කරන ලදී.)

ගූගල් IO17 හි නිවේදනය කරන ලද Gradle 3.0 සමඟ එන සුවිශේෂී වෙනස්කම් වලින් එකකි .

මෙම compileවින්යාසය ඇත අදහසට විරුද්ධ හා විස්ථාපනය කල යුතුය implementationහෝapi

සිට Gradle ප්රලේඛනය :

dependencies {
    api 'commons-httpclient:commons-httpclient:3.1'
    implementation 'org.apache.commons:commons-lang3:3.5'
}

apiවින්‍යාසයන්හි දැක්වෙන පරායත්තයන් පුස්තකාලයේ පාරිභෝගිකයින්ට අක්‍රීයව නිරාවරණය වනු ඇති අතර, එමඟින් පාරිභෝගිකයින්ගේ සම්පාදක පන්ති මාවතේ දිස්වනු ඇත.

implementationවින්‍යාසය තුළ ඇති පරායත්තයන් අනෙක් අතට පාරිභෝගිකයින්ට නිරාවරණය නොවනු ඇති අතර එම නිසා පාරිභෝගිකයින්ගේ සම්පාදක පන්ති මාර්ගයට කාන්දු නොවේ. මෙය ප්‍රතිලාභ කිහිපයක් සමඟ පැමිණේ:

  • පරායත්තයන් පාරිභෝගිකයින්ගේ සම්පාදක පන්ති මාවතට තවදුරටත් කාන්දු නොවන බැවින් ඔබ කිසි විටෙකත් අහම්බෙන් සංක්‍රාන්ති පරායත්තතාවයක් මත රඳා නොපවතී
  • වේගවත් සම්පාදනය පංති පථයේ ප්‍රමාණය අඩු කිරීමට ස්තූතියි
  • ක්‍රියාත්මක කිරීමේ පරායත්තතා වෙනස් වන විට අඩු ප්‍රතිචක්‍රීකරණයන්: පාරිභෝගිකයින් නැවත සම්පාදනය කිරීම අවශ්‍ය නොවේ
  • පිරිසිදු ප්‍රකාශනය: නව මේවන්-ප්‍රකාශන ප්ලගිනය සමඟ භාවිතා කරන විට, ජාවා පුස්තකාල විසින් POM ලිපිගොනු නිපදවන අතර එය පුස්තකාලයට එරෙහිව සම්පාදනය කිරීමට අවශ්‍ය දේ සහ ක්‍රියාත්මක වන වේලාවේදී පුස්තකාලය භාවිතා කිරීමට අවශ්‍ය දේ අතර වෙනස හඳුනා ගනී. පුස්තකාලය සම්පාදනය කිරීමට අවශ්‍ය දේ සහ පුස්තකාලයට එරෙහිව සම්පාදනය කිරීමට අවශ්‍ය දේ මිශ්‍ර කරන්න).

සම්පාදක වින්‍යාසය තවමත් පවතී, නමුත් එය apiසහ implementationවින්‍යාසයන් සපයන සහතික ලබා නොදෙන බැවින් එය භාවිතා නොකළ යුතුය .


සටහන: ඔබ භාවිතා කරන්නේ ඔබේ යෙදුම් මොඩියුලයේ පුස්තකාලයක් පමණි - පොදු අවස්ථාව - ඔබට කිසිදු වෙනසක් නොපෙනේ.
ඔබට වෙනස පෙනෙන්නේ ඔබ එකිනෙකා මත පදනම්ව මොඩියුල සහිත සංකීර්ණ ව්‍යාපෘතියක් තිබේ නම් හෝ ඔබ පුස්තකාලයක් නිර්මාණය කරන්නේ නම් පමණි.


139
"පාරිභෝගිකයින්" කවුද?
සුරග්

35
පාරිභෝගිකයා යනු පුස්තකාලය භාවිතා කරන මොඩියුලයයි. ඇන්ඩ්‍රොයිඩ් සම්බන්ධයෙන් ගත් කල, එය ඇන්ඩ්‍රොයිඩ් යෙදුමයි. මම හිතන්නේ මෙය පැහැදිලිය. ඔබ ඉල්ලන්නේ මෙයදැයි මට විශ්වාස නැත.
හමාස් කරන ලද්දේ

22
ඒක මටත් වගේ. නමුත් මම පුස්තකාලයක් සාදන්නේ නම්, ඇත්ත වශයෙන්ම මට අවශ්‍ය වන්නේ එහි API යෙදුමට නිරාවරණය වීමයි. එසේ නොමැතිනම්, යෙදුම් සංවර්ධකයා මගේ පුස්තකාලය භාවිතා කරන්නේ කෙසේද? implementationයැපීම සැඟවීමේ තේරුම මට නොලැබෙන්නේ එබැවිනි . මගේ ප්‍රශ්නයට තේරුමක් තිබේද?
සුරග්

240
ඔව්, ඔබගේ යෙදුම y, z මත රඳා පවතින x පුස්තකාලය මත රඳා පවතී නම් දැන් එය අර්ථවත් කරයි. ඔබ භාවිතා කරන්නේ implementationx api පමණක් නිරාවරණය වන නමුත් ඔබ apiy භාවිතා කරන්නේ නම් z ද නිරාවරණය වේ.
හමාස් කරන ලද

39
තේරුම් ගත්තා ද! එය දැන් වඩාත් අර්ථවත් කරයි. ඔබට මෙම පැහැදිලි කිරීම ඔබේ පිළිතුරට එක් කළ හැකිය. එය උපුටා ගත් ලියකියවිලි වලට වඩා පැහැදිලිය.
සුරග්

399

මේ පිළිතුර අතර වෙනස පිළිබිඹු කරන implementation, apiසහ compileව්යාපෘතියක් මත.


ග්‍රේඩ්ල් මොඩියුල තුනක් සහිත ව්‍යාපෘතියක් මා සතුව ඇතැයි කියමු:

  • යෙදුම (Android යෙදුමක්)
  • myandroidlibrary (ඇන්ඩ්‍රොයිඩ් පුස්තකාලයක්)
  • myjavalibrary (ජාවා පුස්තකාලයක්)

appඇත myandroidlibraryපරායත්තයන් ලෙස. myandroidlibraryඇත myjavalibrary පරායත්තයන් ලෙස.

යැපීම 1

myjavalibraryසතුව MySecretපන්ති

public class MySecret {

    public static String getSecret() {
        return "Money";
    }
}

myandroidlibraryඇත MyAndroidComponentවටිනාකමක් හසුරුවනු පන්තියේ MySecretපන්ති.

public class MyAndroidComponent {

    private static String component = MySecret.getSecret();

    public static String getComponent() {
        return "My component: " + component;
    }    
}

අවසාන වශයෙන්, appවටිනාකම ගැන පමණක් උනන්දු වේmyandroidlibrary

TextView tvHelloWorld = findViewById(R.id.tv_hello_world);
tvHelloWorld.setText(MyAndroidComponent.getComponent());

දැන් අපි පරායත්තතා ගැන කතා කරමු ...

appපරිභෝජනය කිරීමට අවශ්‍යයි :myandroidlibrary, එබැවින් appbuild.gradle භාවිතයේදී implementation.

( සටහන : ඔබට api / compile ද භාවිතා කළ හැකිය. නමුත් එම සිතුවිල්ල මොහොතකට තබා ගන්න.)

dependencies {
    implementation project(':myandroidlibrary')      
}

යැපීම 2

myandroidlibraryBuild.gradle පෙනුම කුමක් විය යුතු යැයි ඔබ සිතන්නේද ? අප භාවිතා කළ යුතු විෂය පථය කුමක්ද?

අපට විකල්ප තුනක් ඇත:

dependencies {
    // Option #1
    implementation project(':myjavalibrary') 
    // Option #2
    compile project(':myjavalibrary')      
    // Option #3
    api project(':myjavalibrary')           
}

යැපීම 3

ඔවුන් අතර ඇති වෙනස කුමක්ද සහ මා භාවිතා කළ යුත්තේ කුමක්ද?

සම්පාදනය හෝ Api (විකල්පය # 2 හෝ # 3) යැපීම 4

ඔබ භාවිතා කරන්නේ නම් compileහෝ api. අපගේ ඇන්ඩ්‍රොයිඩ් යෙදුමට දැන් myandroidcomponentපරායත්තතාවයට ප්‍රවේශ විය හැකිය , එය MySecretපන්තියකි.

TextView textView = findViewById(R.id.text_view);
textView.setText(MyAndroidComponent.getComponent());
// You can access MySecret
textView.setText(MySecret.getSecret());

ක්‍රියාත්මක කිරීම (විකල්පය # 1)

යැපීම 5

ඔබ implementationවින්‍යාසය භාවිතා කරන්නේ නම් , MySecretනිරාවරණය නොවේ.

TextView textView = findViewById(R.id.text_view);
textView.setText(MyAndroidComponent.getComponent());
// You can NOT access MySecret
textView.setText(MySecret.getSecret()); // Won't even compile

ඉතින්, ඔබ තෝරාගත යුත්තේ කුමන වින්‍යාසයද? එය සැබවින්ම ඔබගේ අවශ්‍යතාවය මත රඳා පවතී.

ඔබ නම් පරායත්තයන් හෙළිදරව් කිරීමට අවශ්ය භාවිතය apiහෝ compile.

පරායත්තතා හෙළි කිරීමට ඔබට අවශ්‍ය නැතිනම් (ඔබේ අභ්‍යන්තර මොඩියුලය සැඟවීම) භාවිතා කරන්න implementation.

සටහන:

මෙය ශ්‍රේණියේ වින්‍යාසයන්ගේ සාරාංශයක් පමණි, වගුව 49.1 බලන්න. ජාවා පුස්තකාල ප්ලගිනය - වඩාත් සවිස්තරාත්මක පැහැදිලි කිරීම සඳහා පරායත්තතා ප්‍රකාශ කිරීමට භාවිතා කරන වින්‍යාසයන් .

මෙම පිළිතුර සඳහා නියැදි ව්‍යාපෘතිය https://github.com/aldoKelvianto/ImplementationVsCompile වෙතින් ලබා ගත හැකිය


1
ක්‍රියාත්මක කිරීම භාවිතා කරමින් මට එක් භාජන ගොනුවකට යැපීම එකතු කර ඇත, එය වෙත ප්‍රවේශය හෙළි නොකරන්නේ නම් මට තවමත් ලබා ගත හැකි වන්නේ ඇයි සහ මගේ කේතය හොඳින් ක්‍රියාත්මක වන්නේ ඇයි?
smkrn110

@ smkrn110 ක්‍රියාත්මක කිරීම මඟින් ඔබේ භාජන පුස්තකාලය නිරාවරණය වනු ඇත, නමුත් ඔබේ භාජන පරායත්ත පුස්තකාල නොවේ.
aldok

2
Ij විජයශර්මා පිළිගත් පිළිතුරෙහි සඳහන් compileවන්නේ සහතික කරන දේම සහතික නොකරන බවයි api.
උප 6 සම්පත්

12
මම හිතන්නේ මෙය පිළිගත් පිළිතුර විය යුතුයි. හොඳින් පැහැදිලි කර ඇත!
ශෂාන්ක් කැප්සයිම්

9
@ ස්ටීවන් ඩබ්ලිව් ක්ලැසන් යනු මා මෙතෙක් අසා ඇති වඩාත්ම නුසුදුසු පහත් අගයයි. තොරතුරු අනුපිළිවෙල ප්‍රශස්ත නොවේ යැයි ඔබ සිතන්නේ නම්, ඒ ගැන පැමිණිලි කරනවා වෙනුවට සංස්කරණයක් යෝජනා කරන්න
ටිම්

67

Compileවින්යාස නොසලකා හරිනු ලැබූ අතර විස්ථාපනය කල යුතුය implementationහෝ api.

ඔබට https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_separation වෙතින් ලිපි කියවිය හැකිය .

කෙටි කොටස නම්-

සම්මත ජාවා ප්ලගිනය සහ ජාවා පුස්තකාල ප්ලගිනය අතර ඇති ප්‍රධාන වෙනස වන්නේ දෙවැන්න පාරිභෝගිකයින්ට නිරාවරණය වන API සංකල්පයක් හඳුන්වා දීමයි. පුස්තකාලයක් යනු ජාවා සංරචකයක් වන අතර එය වෙනත් සංරචක විසින් පරිභෝජනය කළ යුතුය. එය බහු-ව්‍යාපෘති ගොඩනැඟිලිවල බහුලව භාවිතා වන අවස්ථාවකි, නමුත් ඔබට බාහිර පරායත්තතා ඇති විගසම.

ප්ලගිනය මඟින් පරායත්තතා ප්‍රකාශ කිරීම සඳහා භාවිතා කළ හැකි වින්‍යාසයන් දෙකක් නිරාවරණය කරයි: api සහ ක්‍රියාත්මක කිරීම. පුස්තකාල API මඟින් අපනයනය කරන පරායත්තතා ප්‍රකාශ කිරීම සඳහා api වින්‍යාසය භාවිතා කළ යුතු අතර, ක්‍රියාත්මක කිරීමේ වින්‍යාසය සංරචකයට අභ්‍යන්තර වන පරායත්තතා ප්‍රකාශ කිරීමට භාවිතා කළ යුතුය.

වැඩි විස්තර සඳහා මෙම රූපය වෙත යොමු වන්න. කෙටි පැහැදිලි කිරීම


46

කෙටි විසඳුම:

වඩා හොඳ ප්‍රවේශය නම් සියලු compileපරායත්තතාවයන් පරායත්තතාවයන් සමඟ ප්‍රතිස්ථාපනය implementationකිරීමයි. ඔබ මොඩියුලයේ අතුරුමුහුණත කාන්දු වන තැන පමණක් භාවිතා කළ යුතුය api. එය නැවත අඩු කිරීමකට හේතු විය යුතුය.

 dependencies {
         implementation fileTree(dir: 'libs', include: ['*.jar'])
 
         implementation 'com.android.support:appcompat-v7:25.4.0'
         implementation 'com.android.support.constraint:constraint-layout:1.0.2'
         // …
 
         testImplementation 'junit:junit:4.12'
         androidTestImplementation('com.android.support.test.espresso:espresso-core:2.2.2', {
             exclude group: 'com.android.support', module: 'support-annotations'
         })
 }

තවත් පැහැදිලි කරන්න:

ඇන්ඩ්‍රොයිඩ් ග්‍රෙඩ්ල් ප්ලගිනය 3.0 ට පෙර : අපට විශාල ගැටළුවක් ඇති වූ අතර එය එක් කේත වෙනස් කිරීමක් නිසා සියලුම මොඩියුල නැවත සකස් කිරීමට හේතු වේ. මෙයට මූලික හේතුව වන්නේ ඔබ මොඩියුලයක අතුරු මුහුණත වෙනත් එකක් හරහා කාන්දු කරනවාද නැද්ද යන්න ග්‍රේඩ්ල් නොදැන සිටීමයි.

ඇන්ඩ්‍රොයිඩ් ග්‍රේඩ්ල් ප්ලගිනය 3.0 පසු : නවතම ඇන්ඩ්‍රොයිඩ් ග්‍රැඩ්ල් ප්ලගිනය දැන් ඔබට මොඩියුලයේ අතුරු මුහුණතක් කාන්දු වන්නේද යන්න පැහැදිලිව නිර්වචනය කිරීමට අවශ්‍ය වේ. ඒ මත පදනම්ව එය නැවත සකස් කළ යුතු දේ පිළිබඳව නිවැරදි තේරීමක් කළ හැකිය.

එනිසා compileපරායත්තතාවය අතහැර දමා නව ඒවා දෙකක් ආදේශ කර ඇත:

  • api: ඔබ මෙම මොඩියුලයේ අතුරු මුහුණත ඔබේම අතුරුමුහුණත හරහා කාන්දු කරයි, එහි අර්ථය හරියටම පැරණි compileපරායත්තතාවයට සමාන වේ

  • implementation: ඔබ මෙම මොඩියුලය අභ්‍යන්තරව පමණක් භාවිතා කරන අතර එය ඔබගේ අතුරු මුහුණත හරහා කාන්දු නොවේ

පාවිච්චි කරන ලද මොඩියුලයක අතුරුමුහුණත වෙනස් වුවහොත් හෝ නොවන්නේ නම් මොඩියුලයක් නැවත සකස් කරන ලෙස දැන් ඔබට පැහැදිලිවම ග්‍රේඩ්ල්ට පැවසිය හැකිය.

ජෙරොයින් මෝල්ස් බ්ලොග් අනුග්‍රහයෙනි


2
පිරිසිදු හා සංක්ෂිප්ත පැහැදිලි කිරීම. ස්තූතියි!
ලියොන් - හැන් ලී

24
+--------------------+----------------------+-------------+--------------+-----------------------------------------+
| Name               | Role                 | Consumable? | Resolveable? | Description                             |
+--------------------+----------------------+-------------+--------------+-----------------------------------------+
| api                | Declaring            |      no     |      no      | This is where you should declare        |
|                    | API                  |             |              | dependencies which are transitively     |
|                    | dependencies         |             |              | exported to consumers, for compile.     |
+--------------------+----------------------+-------------+--------------+-----------------------------------------+
| implementation     | Declaring            |      no     |      no      | This is where you should                |
|                    | implementation       |             |              | declare dependencies which are          |
|                    | dependencies         |             |              | purely internal and not                 |
|                    |                      |             |              | meant to be exposed to consumers.       |
+--------------------+----------------------+-------------+--------------+-----------------------------------------+
| compileOnly        | Declaring compile    |     yes     |      yes     | This is where you should                |
|                    | only                 |             |              | declare dependencies                    |
|                    | dependencies         |             |              | which are only required                 |
|                    |                      |             |              | at compile time, but should             |
|                    |                      |             |              | not leak into the runtime.              |
|                    |                      |             |              | This typically includes dependencies    |
|                    |                      |             |              | which are shaded when found at runtime. |
+--------------------+----------------------+-------------+--------------+-----------------------------------------+
| runtimeOnly        | Declaring            |      no     |      no      | This is where you should                |
|                    | runtime              |             |              | declare dependencies which              |
|                    | dependencies         |             |              | are only required at runtime,           |
|                    |                      |             |              | and not at compile time.                |
+--------------------+----------------------+-------------+--------------+-----------------------------------------+
| testImplementation | Test dependencies    |      no     |      no      | This is where you                       |
|                    |                      |             |              | should declare dependencies             |
|                    |                      |             |              | which are used to compile tests.        |
+--------------------+----------------------+-------------+--------------+-----------------------------------------+
| testCompileOnly    | Declaring test       |     yes     |      yes     | This is where you should                |
|                    | compile only         |             |              | declare dependencies                    |
|                    | dependencies         |             |              | which are only required                 |
|                    |                      |             |              | at test compile time,                   |
|                    |                      |             |              | but should not leak into the runtime.   |
|                    |                      |             |              | This typically includes dependencies    |
|                    |                      |             |              | which are shaded when found at runtime. |
+--------------------+----------------------+-------------+--------------+-----------------------------------------+
| testRuntimeOnly    | Declaring test       |      no     |      no      | This is where you should                |
|                    | runtime dependencies |             |              | declare dependencies which              |
|                    |                      |             |              | are only required at test               |
|                    |                      |             |              | runtime, and not at test compile time.  |
+--------------------+----------------------+-------------+--------------+-----------------------------------------+

ප්‍රශ්නයට කෙලින්ම පිළිතුරු නොදේ
නොදේ skryvets

1
සංවර්ධනයක් ද ඇත
හොහෙන්හයිම්සන්බර්ග්

ධාවන කාලය සහ සම්පාදනය කිරීමේ කාලය යන දෙකම අවශ්‍ය නම් මා භාවිතා කළ යුත්තේ කුමක්ද? දැනට, මම implementationඅනුගමනය කර ඇත්තේ a runtime.
මාරූන්

11

Gradle 3.0 ඊළඟ වෙනස්කම් හඳුන්වා දෙන ලදි:

  • compile -> api

    api යතුරුපදය අවලංගු කළ ආකාරයටම වේ compile

  • compile -> implementation

    වන වඩාත් සමහර වාසි ඇති බැවින් මාර්ගය. ගොඩනැගීමේ වේලාවේදී එක් මට්ටමකටimplementation පමණක් යැපීම නිරාවරණය කරන්න (යැපීම ක්‍රියාත්මක වන වේලාවේදී ලබා ගත හැකිය). එහි ප්‍රති As ලයක් ලෙස ඔබට වේගවත් ගොඩනැගීමක් ඇත (ඉහළ මට්ටමේ පාරිභෝගිකයින් නැවත මට්ටම් කිරීමට අවශ්‍ය නැත.

  • provided -> compileOnly

    මෙම යැපීම ලබා ගත හැක්කේ තුළ පමණි සම්පාදනය කරන වේලාවේදී (යැපීම ක්‍රියාත්මක වන වේලාවේදී ලබා ගත නොහැක). මෙම පරායත්තතාව සංක්‍රාන්තික විය නොහැකි අතර විය හැකිය .aar. එය සම්පාදක කාල විවරණ සකසනය සමඟ භාවිතා කළ හැකි අතර අවසාන ප්‍රතිදාන ගොනුවක් අඩු කිරීමට ඔබට ඉඩ සලසයි

  • compile -> annotationProcessor

    බොහෝ සෙයින් සමාන ය compileOnlyසංක්‍රාන්ති පරායත්තතාවය පාරිභෝගිකයාට නොපෙනෙන බවට නමුත් සහතික කරයි

  • apk -> runtimeOnly

    යැපීම සම්පාදනය කරන වේලාවේදී ලබා ගත නොහැකි නමුත් ධාවන වේලාවේදී ලබා ගත හැකිය.


2
ඒ නිසා වෙනත් වචන වලින් කිවහොත්, දී api = public, implementation = internalහා compileOnly = private- මම ඔවුන් සුපිරි වැට්ටවීමට ඇත ලෙස මෙම කාර්යයන් සඳහා එම යොමුවීම් නිර්මාණය කිරීමට අවශ්ය වේ.
t3chb0t

9

ගිහියන්ගේ යෙදුමේ කෙටි වෙනස:

  • ප්‍රකාශිත පරායත්තතාවයේ සාමාජිකයන් නිරාවරණය කිරීමෙන් වෙනත් මොඩියුලයන්ට සහාය ලබා දෙන අතුරු මුහුණතක් හෝ මොඩියුලයක් මත ඔබ වැඩ කරන්නේ නම් ඔබ භාවිතා කළ යුත්තේ 'api' ය.
  • ඔබ ප්‍රකාශිත යැපීම අභ්‍යන්තරව ක්‍රියාත්මක කිරීමට හෝ භාවිතා කිරීමට යන යෙදුමක් හෝ මොඩියුලයක් කරන්නේ නම්, 'ක්‍රියාත්මක කිරීම' භාවිතා කරන්න.
  • 'සම්පාදනය' 'api' හා සමාන වේ, කෙසේ වෙතත්, ඔබ කිසියම් පුස්තකාලයක් ක්‍රියාත්මක කරන්නේ නම් හෝ භාවිතා කරන්නේ නම්, 'ක්‍රියාත්මක කිරීම' වඩා හොඳින් ක්‍රියාත්මක වන අතර ඔබේ සම්පත් ඉතිරි වේ.

සවිස්තරාත්මක උදාහරණයක් සඳහා @aldok විසින් පිළිතුර කියවන්න.


නමුත් කාරණය නම්, මෙම ප්‍රශ්නවලට පිළිතුරක් සොයමින් පුද්ගලයෙකු හිතාමතාම මෙහි පැමිණියේ නම්, ඔහු ගිහියෙකු නොවේ.
රිෂව්

7

5.6.3 අනුවාදයේ සිට, පැරණි පරායත්තතාවයක් (හෝ නව එකක්) හෝ යැපීමක් සමඟ ප්‍රතිස්ථාපනය කළ යුතුද යන්න හඳුනා ගැනීම සඳහා සරල ප්‍රලේඛන නීති රීති සපයයි :compileimplementationapi

  • හැකි සෑම විටම implementationවින්‍යාසය මනාප කරන්නapi

මෙය පාරිභෝගිකයාගේ සම්පාදන පන්තියේ මාවතේ පරායත්තතාවයන් වළක්වයි. මීට අමතරව, කිසියම් ක්‍රියාත්මක කිරීමේ වර්ගයක් අහම්බෙන් පොදු API වෙත කාන්දු වුවහොත් පාරිභෝගිකයා වහාම සම්පාදනය කිරීමට අසමත් වනු ඇත.

ඉතින් ඔබ apiවින්‍යාසය භාවිතා කළ යුත්තේ කවදාද? API යැපීම යනු පුස්තකාල ද්විමය අතුරුමුහුණතෙහි නිරාවරණය වන අවම වශයෙන් එක් වර්ගයක්වත් අඩංගු වන අතර එය බොහෝ විට එහි ABI (යෙදුම් ද්විමය අතුරුමුහුණත) ලෙස හැඳින්වේ. මෙයට ඇතුළත් නමුත් ඒවාට පමණක් සීමා නොවේ:

  • සුපිරි පන්ති හෝ අතුරුමුහුණත් වල භාවිතා වන වර්ග
  • සාමාන්‍ය පරාමිති වර්ග ඇතුළුව පොදු ක්‍රම පරාමිතීන්හි භාවිතා වන වර්ග (පොදු යනු සම්පාදකයින්ට දැකිය හැකි දෙයකි. එනම්, ජාවා ලෝකයේ පොදු, ආරක්ෂිත සහ පැකේජ පෞද්ගලික සාමාජිකයන්)
  • පොදු ක්ෂේත්‍රවල භාවිතා වන වර්ග
  • පොදු විවරණ වර්ග

ඊට වෙනස්ව, පහත ලැයිස්තුවේ භාවිතා කරන ඕනෑම වර්ගයක් ABI ට අදාල නොවේ, එබැවින් implementationයැපීමක් ලෙස ප්‍රකාශ කළ යුතුය :

  • ක්‍රම වස්තූන් සඳහා පමණක් භාවිතා කරන වර්ග
  • පුද්ගලික සාමාජිකයන් සඳහා පමණක් භාවිතා කරන වර්ග
  • අභ්‍යන්තර පංතිවල පමණක් දක්නට ලැබෙන වර්ග (ග්‍රැඩ්ල් හි අනාගත අනුවාදයන් පොදු API වලට අයත් පැකේජ මොනවාදැයි ප්‍රකාශ කිරීමට ඔබට ඉඩ සලසයි)
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.