กรณีการใช้งานที่ดีสำหรับการนำเข้าแบบคงที่คืออะไร?

เพิ่งได้รับความคิดเห็นในการตรวจสอบว่าการนำเข้าวิธีการแบบคงที่ของฉันไม่ใช่ความคิดที่ดี การนำเข้าแบบคงที่เป็นวิธีการจากคลาส DA ซึ่งส่วนใหญ่มีวิธีการคงที่ ดังนั้นในช่วงกลางของตรรกะทางธุรกิจฉันมีกิจกรรมดาที่ดูเหมือนจะเป็นของคลาสปัจจุบัน:

import static some.package.DA.*;
class BusinessObject {
  void someMethod() {
    ....
    save(this);
  }
} 

ผู้ตรวจสอบไม่กระตือรือร้นที่ฉันจะเปลี่ยนรหัสและฉันไม่ทำ แต่ฉันก็เห็นด้วยกับเขา เหตุผลหนึ่งที่ทำให้ไม่นำเข้าแบบคงที่คือมันสับสนว่าเมธอดถูกกำหนดไว้ที่ไหนมันไม่ได้อยู่ในคลาสปัจจุบันและไม่ได้อยู่ในคลาสซูเปอร์คลาสใด ๆ ดังนั้นจึงใช้เวลาในการระบุนิยามของมันมากเกินไป (ระบบการตรวจสอบบนเว็บไม่สามารถคลิกได้ ลิงก์เช่น IDE :-) ฉันไม่คิดว่าเรื่องนี้สำคัญการนำเข้าแบบคงที่ยังค่อนข้างใหม่และเร็ว ๆ นี้เราทุกคนจะคุ้นเคยกับการค้นหา

แต่อีกเหตุผลหนึ่งที่ฉันเห็นด้วยคือการเรียกเมธอดที่ไม่มีเงื่อนไขดูเหมือนจะเป็นของวัตถุปัจจุบันและไม่ควรข้ามบริบท แต่ถ้ามันเป็นของจริงมันก็สมเหตุสมผลที่จะขยายระดับซุปเปอร์นั้น

ดังนั้นเมื่อไม่ได้ทำให้รู้สึกกับวิธีการนำเข้าคงที่ ทำเสร็จเมื่อไหร่ คุณชอบวิธีการโทรที่ไม่มีเงื่อนไขหรือไม่?

แก้ไข: ความคิดเห็นที่เป็นที่นิยมดูเหมือนจะเป็นวิธีการนำเข้าแบบคงที่หากไม่มีใครจะสับสนว่าเป็นวิธีการของคลาสปัจจุบัน ตัวอย่างเช่นวิธีการจาก java.lang.Math และ java.awt.Color แต่ถ้า abs และ getAlpha ไม่คลุมเครือฉันไม่เห็นว่าทำไม readEmployee คือ ฉันคิดว่านี่เป็นความชอบส่วนบุคคลเช่นกัน

ขอบคุณสำหรับคำตอบของคุณฉันกำลังปิดคำถาม

นี่มาจากคำแนะนำของ Sun เมื่อพวกเขาเปิดตัวคุณลักษณะ (เน้นในต้นฉบับ):

คุณควรใช้การนำเข้าแบบคงที่เมื่อใด จัดจ้านมาก!ใช้เฉพาะเมื่อคุณถูกล่อลวงให้ประกาศสำเนาของค่าคงที่ในเครื่องหรือเพื่อละเมิดการสืบทอด (รูปแบบการป้องกันส่วนติดต่อคงที่) ... หากคุณใช้คุณสมบัติการนำเข้าแบบคงที่มากเกินไปอาจทำให้โปรแกรมของคุณไม่สามารถอ่านได้และไม่สามารถเข้าถึงได้ทำให้เนมสเปซของมันเป็นมลพิษกับสมาชิกสแตติกทั้งหมดที่คุณนำเข้า ผู้อ่านรหัสของคุณ (รวมถึงคุณไม่กี่เดือนหลังจากที่คุณเขียน) จะไม่ทราบว่าสมาชิกคงที่มาจากคลาสใด การนำเข้าสมาชิกแบบคงที่ทั้งหมดจากคลาสอาจเป็นอันตรายอย่างยิ่งต่อความสามารถในการอ่าน หากคุณต้องการสมาชิกเพียงหนึ่งหรือสองคนให้นำเข้าทีละคน

( https://docs.oracle.com/javase/8/docs/technotes/guides/language/static-import.html )

มีสองส่วนที่ฉันต้องการกล่าวโดยเฉพาะ:

• ใช้การนำเข้าแบบคงที่เฉพาะเมื่อคุณถูกล่อลวงให้ "ละเมิดมรดก" ในกรณีนี้คุณถูกล่อลวงให้มี BusinessObject extend some.package.DAหรือไม่? ในกรณีนี้การนำเข้าแบบคงที่อาจเป็นวิธีที่สะอาดกว่าในการจัดการสิ่งนี้ หากคุณไม่เคยคิดฝันที่จะขยายการใช้some.package.DAงานนี่อาจเป็นการใช้การนำเข้าแบบคงที่ อย่าใช้เพื่อบันทึกอักขระเพียงไม่กี่ตัวเมื่อพิมพ์
• นำเข้าสมาชิกแต่ละคน พูดimport static some.package.DA.saveแทนDA.*. ซึ่งจะช่วยให้ค้นหาได้ง่ายขึ้นว่าวิธีการนำเข้านี้มาจากไหน

โดยส่วนตัวแล้วฉันใช้คุณลักษณะภาษานี้น้อยมากและเกือบตลอดเวลาเฉพาะกับค่าคงที่หรือ enums ไม่เคยใช้วิธีการ การแลกเปลี่ยนสำหรับฉันแทบจะไม่คุ้มค่าเลย

ควบคุมการใช้งานที่เหมาะสมสำหรับการนำเข้าคงอยู่กับ JUnit 4 ในรุ่นก่อนหน้านี้ของวิธีการ JUnit ชอบassertEqualsและได้รับการสืบทอดมาตั้งแต่ระดับการทดสอบขยายfailjunit.framework.TestCase

// old way
import junit.framework.TestCase;

public class MyTestClass extends TestCase {
    public void myMethodTest() {
        assertEquals("foo", "bar");
    }
}

ใน JUnit 4 คลาสทดสอบไม่จำเป็นต้องขยายอีกต่อไปTestCaseและสามารถใช้คำอธิบายประกอบแทนได้ จากนั้นคุณสามารถนำเข้าวิธีการยืนยันแบบคงที่จากorg.junit.Assert:

// new way
import static org.junit.Assert.assertEquals;

public class MyTestClass {
    @Test public void myMethodTest() {
        assertEquals("foo", "bar");
        // instead of
        Assert.assertEquals("foo", "bar");
    }
}

JUnit ใช้เอกสารในลักษณะนี้

Java ที่มีประสิทธิภาพ Second Editionในตอนท้ายของรายการ 19บันทึกว่าคุณสามารถใช้การนำเข้าแบบคงที่ได้หากคุณพบว่าตัวเองใช้ค่าคงที่จากคลาสยูทิลิตี้อย่างหนัก ฉันคิดว่าหลักการนี้ใช้กับการนำเข้าแบบคงที่ของทั้งค่าคงที่และวิธีการ

import static com.example.UtilityClassWithFrequentlyUsedMethods.myMethod;

public class MyClass {
    public void doSomething() {
        int foo= UtilityClassWithFrequentlyUsedMethods.myMethod();
        // can be written less verbosely as
        int bar = myMethod();
    }
}

สิ่งนี้มีข้อดีและข้อเสีย ทำให้โค้ดสามารถอ่านได้มากขึ้นโดยสูญเสียข้อมูลบางอย่างในทันทีเกี่ยวกับตำแหน่งที่กำหนดวิธีการ อย่างไรก็ตาม IDE ที่ดีจะช่วยให้คุณไปที่คำจำกัดความได้ดังนั้นนี่จึงไม่ใช่ปัญหามากนัก

คุณควรใช้สิ่งนี้เท่าที่จำเป็นและเฉพาะในกรณีที่คุณพบว่าตัวเองใช้สิ่งต่างๆจากไฟล์ที่นำเข้าหลาย ๆ ครั้ง

แก้ไข:อัปเดตให้เฉพาะเจาะจงมากขึ้นสำหรับวิธีการเนื่องจากนั่นคือสิ่งที่คำถามนี้อ้างถึง หลักการนี้ใช้ไม่ว่าจะนำเข้าอะไร (ค่าคงที่หรือวิธีการ)

ฉันยอมรับว่าสิ่งเหล่านี้อาจเป็นปัญหาได้จากมุมมองความสามารถในการอ่านและควรใช้เท่าที่จำเป็น แต่เมื่อใช้วิธีการคงที่ทั่วไปพวกเขาสามารถเพิ่มความสามารถในการอ่านได้จริง ตัวอย่างเช่นในคลาสทดสอบ JUnit วิธีการต่างๆassertEqualsจะชัดเจนว่ามาจากไหน java.lang.Mathในทำนองเดียวกันสำหรับวิธีการจาก

ฉันคิดว่าการนำเข้าแบบคงที่มีประโยชน์มากในการลบชื่อคลาสที่ซ้ำซ้อนเมื่อใช้คลาส utils เช่นArraysและAssertionsและ

ไม่แน่ใจว่าทำไม แต่รอสส์ข้ามออกประโยคสุดท้ายที่กล่าวถึงนี้ในเอกสารที่เขาถูกอ้างอิง

การนำเข้าแบบคงที่ใช้อย่างเหมาะสมสามารถทำให้โปรแกรมของคุณอ่านง่ายขึ้นโดยการลบต้นแบบของการซ้ำกันของชื่อคลาส

คัดลอกโดยทั่วไปจากบล็อกนี้: https://medium.com/alphadev-thoughts/static-imports-are-great-but-underused-e805ba9b279f

ตัวอย่างเช่น:

การยืนยันในการทดสอบ

นี่เป็นกรณีที่ชัดเจนที่สุดซึ่งฉันคิดว่าเราทุกคนเห็นด้วย

Assertions.assertThat(1).isEqualTo(2);

// Use static import instead
assertThat(1).isEqualTo(2);

คลาส Utils และ enums

ชื่อคลาสสามารถลบออกได้ในหลาย ๆ กรณีเมื่อใช้คลาส utils ทำให้โค้ดอ่านง่ายขึ้น

List<Integer> numbers = Arrays.asList(1, 2, 3);

// asList method name is enough information
List<Integer> numbers = asList(1, 2, 3);

แพคเกจ java.time มีบางกรณีที่ควรใช้

// Get next Friday from now, quite annoying to read
LocalDate.now().with(TemporalAdjusters.next(DayOfWeek.FRIDAY));

// More concise and easier to read
LocalDate.now().with(next(FRIDAY));

ตัวอย่างเวลาที่ไม่ควรใช้

// Ok this is an Optional
Optional.of("hello world");

// I have no idea what this is 
of("hello world");

ฉันใช้มันสำหรับสีมาก

static import java.awt.Color.*;

ไม่น่าเป็นไปได้มากที่สีจะสับสนกับอย่างอื่น

ฉันแนะนำให้ใช้การนำเข้าแบบคงที่เมื่อใช้ OpenGL กับ Java ซึ่งเป็นกรณีการใช้งานที่อยู่ในหมวดหมู่"การใช้ค่าคงที่จากคลาสยูทิลิตี้อย่างหนัก"

ลองพิจารณาดู

import static android.opengl.GLES20.*;

ช่วยให้คุณสามารถพอร์ตโค้ด C ดั้งเดิมและเขียนสิ่งที่อ่านได้เช่น:

glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, texture);
glUniform1i(samplerUniform, 0);
glBindBuffer(GL_ARRAY_BUFFER, vtxBuffer);
glVertexAttribPointer(vtxAttrib, 3, GL_FLOAT, false, 0, 0);

แทนที่จะเป็นความอัปลักษณ์ที่แพร่หลายทั่วไป:

GLES20.glActiveTexture(GLES20.GL_TEXTURE0);
GLES20.glBindTexture(GLES20.GL_TEXTURE_2D, texture);
GLES20.glUniform1i(samplerUniform, 0);
GLES20.glBindBuffer(GLES20.GL_ARRAY_BUFFER, vtxBuffer);
GLES20.glVertexAttribPointer(vtxAttrib, 3, GLES20.GL_FLOAT, false, 0, 0);

การนำเข้าแบบคงที่เป็นคุณลักษณะเฉพาะ "ใหม่" ของ Java ที่ฉันไม่เคยใช้และไม่ได้ตั้งใจจะใช้เนื่องจากปัญหาที่คุณเพิ่งกล่าวถึง

ฉันใช้ 'นำเข้า java.lang.Math. *' แบบคงที่เมื่อย้ายรหัสคณิตศาสตร์จำนวนมากจาก C / C ++ ไปยัง java วิธีการทางคณิตศาสตร์จะจับคู่ 1 ถึง 1 และทำให้การเปลี่ยนรหัสที่พอร์ตง่ายขึ้นโดยไม่ต้องมีคุณสมบัติของชื่อคลาส

ฉันพบว่าสิ่งนี้สะดวกมากเมื่อใช้คลาสยูทิลิตี้

ตัวอย่างเช่นแทนที่จะใช้: if(CollectionUtils.isNotEmpty(col))

ฉันสามารถแทน:

import static org.apache.commons.collections.CollectionUtils.isNotEmpty;
if(isNotEmpty(col))

IMO ใดเพิ่มความสามารถในการอ่านโค้ดเมื่อฉันใช้ยูทิลิตี้นี้หลายครั้งในโค้ดของฉัน

พูดคุยเกี่ยวกับการทดสอบหน่วย: คนส่วนใหญ่ใช้การนำเข้าคงที่สำหรับวิธีการแบบคงที่ต่างๆที่เยาะเย้ยกรอบให้เช่นหรือwhen()verify()

import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;

และแน่นอนว่าเมื่อใช้เพียงอันเดียวและยืนยันว่าคุณควรใช้assertThat()มันมีประโยชน์ในการนำเข้าตัวจับคู่แฮมเครสต์ที่ต้องการแบบคงที่ดังใน:

import static org.hamcrest.Matchers.*;

มีประโยชน์ในการลดการใช้คำฟุ่มเฟือยโดยเฉพาะอย่างยิ่งในกรณีที่มีการเรียกใช้วิธีการนำเข้าจำนวนมากและความแตกต่างระหว่างวิธีการในท้องถิ่นและวิธีการนำเข้านั้นชัดเจน

ตัวอย่างหนึ่ง: รหัสที่เกี่ยวข้องกับการอ้างอิงหลายรายการไปยัง java.lang.Math

อื่น: คลาสตัวสร้าง XMLที่การเตรียมชื่อคลาสไว้ล่วงหน้าสำหรับการอ้างอิงทุกครั้งจะซ่อนโครงสร้างที่กำลังสร้าง

ฉันคิดว่าการนำเข้าแบบคงที่นั้นเรียบร้อยสำหรับ NLS ในรูปแบบ gettext

import static mypackage.TranslatorUtil._;

//...
System.out.println(_("Hello world."));

ทั้งสองอย่างนี้ทำเครื่องหมายสตริงว่าเป็นสตริงที่ต้องแตกออกและเป็นวิธีที่ง่ายและสะอาดในการแทนที่สตริงด้วยการแปล

การนำเข้าแบบคงที่ IMO เป็นคุณสมบัติที่ดีทีเดียว เป็นความจริงอย่างยิ่งที่การพึ่งพาการนำเข้าแบบคงที่อย่างมากทำให้โค้ดไม่สามารถอ่านได้และยากที่จะเข้าใจว่าคลาสใดเป็นของเมธอดแบบคงที่หรือแอตทริบิวต์ อย่างไรก็ตามจากประสบการณ์ของฉันมันกลายเป็นคุณสมบัติที่ใช้งานได้โดยเฉพาะอย่างยิ่งเมื่อออกแบบUtilคลาสที่มีวิธีการและคุณสมบัติแบบคงที่ ความคลุมเครือที่เกิดขึ้นเมื่อใดก็ตามที่ให้การนำเข้าแบบคงที่สามารถหลีกเลี่ยงได้โดยการสร้างมาตรฐานรหัส จากประสบการณ์ของฉันภายใน บริษัท แนวทางนี้เป็นที่ยอมรับและทำให้โค้ดสะอาดขึ้นและเข้าใจง่าย โดยเฉพาะอย่างยิ่งฉันแทรก_อักขระในวิธีการแบบคงที่ด้านหน้าและแอตทริบิวต์แบบคงที่(นำมาจาก C). เห็นได้ชัดว่าวิธีนี้ละเมิดมาตรฐานการตั้งชื่อของ Java แต่ให้ความชัดเจนกับโค้ด ตัวอย่างเช่นถ้าเรามีคลาส AngleUtils:

public class AngleUtils {

    public static final float _ZERO = 0.0f;
    public static final float _PI   = 3.14f;

    public static float _angleDiff(float angle1, float angle2){

    }

    public static float _addAngle(float target, float dest){

    }
}

ในกรณีนี้การนำเข้าแบบคงที่จะให้ความชัดเจนและโครงสร้างโค้ดดูหรูหราสำหรับฉันมากขึ้น:

import static AngleUtils.*;

public class TestClass{

    public void testAngles(){

        float initialAngle = _ZERO;
        float angle1, angle2;
        _addAngle(angle1, angle2);
    }
}

มีคนบอกได้ทันทีว่าเมธอดหรือแอตทริบิวต์ใดมาจากการนำเข้าแบบคงที่และซ่อนข้อมูลของคลาสที่เป็นสมาชิก ฉันไม่แนะนำให้ใช้การนำเข้าแบบคงที่สำหรับคลาสที่เป็นส่วนหนึ่งของโมดูลและจัดเตรียมวิธีการแบบคงที่และไม่คงที่ในกรณีนี้สิ่งสำคัญคือต้องทราบว่าคลาสใดมีฟังก์ชันการทำงานแบบคงที่

คุณต้องใช้เมื่อ:

• คุณต้องการใช้switchคำสั่งที่มีค่า enum
• คุณต้องการทำให้รหัสของคุณเข้าใจยาก

ฉันใช้มันทุกครั้งที่ทำได้ ฉันมีการตั้งค่า IntelliJ เพื่อเตือนฉันหากฉันลืม ฉันคิดว่ามันดูสะอาดกว่าชื่อแพ็กเกจที่มีคุณสมบัติครบถ้วน