การใช้เมธอดหรือคลาสที่เลิกใช้ใน Java ผิดหรือไม่?

153

ฉันกำลังใช้ eclipse เพื่อพัฒนาเว็บแอปพลิเคชัน เพียงแค่วันนี้ฉันได้อัพเดตเวอร์ชัน struts ของฉันโดยการเปลี่ยนไฟล์ JAR ฉันได้รับคำเตือนในบางสถานที่ซึ่งวิธีการไม่ได้รับการสนับสนุน แต่รหัสทำงานได้ดี

ฉันอยากรู้บางสิ่ง

การใช้เมธอดหรือคลาสที่เลิกใช้ใน Java ผิดหรือไม่?
จะเกิดอะไรขึ้นถ้าฉันไม่เปลี่ยนวิธีการใด ๆ และเรียกใช้แอปพลิเคชันของฉันด้วยคำเตือนที่ฉันมีจะเกิดปัญหาด้านประสิทธิภาพหรือไม่

java methods deprecated

— Umesh Aawte
แหล่งที่มา

7

คุณจะ 'ขับรถต่อไป' เพื่อขับ1955 Volkswagen Beetleแม้ว่าคุณจะได้รับข้อเสนอCorvette Stingrayฟรีหรือไม่? (0:

— KMån

75

@KMan คุณกำลังเปรียบเทียบรถยุโรปกับรถอเมริกันหรือไม่?)

— ponzao

2

@Ponzao และ4คนอื่น ๆ : Gotcha! (0;

— KMån

2

ไม่ถูกต้อง? เรากำลังพูดถึงความเป็นมนุษย์หรือการทำให้เป็นเส้นตรงที่นี่หรือไม่?

— FastAl

5

@Alexander ไม่มีการลงคะแนนสำหรับความคิดเห็นของคุณดังนั้น +1 สำหรับคุณด้วย;) ไม่ว่าในกรณีใด ๆ ก็ตามรหัสใหม่นั้นดีกว่า 1000 ซึ่งก็คือรหัสเก่า การเปรียบเทียบจะดีกว่าระหว่าง1955 Volkswagen Beetleและ1956 Volkswagen Beetleกับยางใหม่ที่คุณไม่ทราบว่าจะแตกเมื่อไหร่!

— Aleks

265

1. การใช้เมธอดหรือคลาสที่เลิกใช้ใน Java ผิดหรือไม่?

จากคำจำกัดความของการคัดค้าน :

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

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

2. จะเกิดอะไรขึ้นถ้าฉันไม่เปลี่ยนวิธีการใด ๆ และเรียกใช้แอปพลิเคชันของฉันด้วยคำเตือนที่ฉันมีจะเกิดปัญหาด้านประสิทธิภาพหรือไม่

ไม่มีโอกาสมากที่สุด มันจะทำงานต่อไปเหมือนก่อนที่จะไม่เห็นด้วย สัญญาของวิธีการ API จะไม่เปลี่ยนแปลง หากบางโครงสร้างข้อมูลภายในเปลี่ยนไปด้วยวิธีการใหม่ที่ดีกว่าอาจส่งผลกระทบต่อประสิทธิภาพการทำงาน แต่ก็ไม่น่าเป็นไปได้

คัดค้านที่สนุกที่สุดใน Java API เป็น IMO FontMetrics.getMaxDecentที่ สาเหตุของการคัดค้าน: การสะกดผิด

เลิก ในฐานะของ JDK รุ่น 1.1.1 แทนที่ด้วย getMaxDescent ()

— aioobe
แหล่งที่มา

5

การเลิกใช้งานที่สนุกที่สุดใน Java API จะเป็น setMultiClickThreshhold (int threshhold) และ getMultiClickTreshhold () ใน AbstractButton (Swing) เตรียมตัวให้พร้อมสำหรับสองคนนี้! ;)

— JavaTechnical

3

เราต้องทำสิ่งนี้กับ HTTP REFERER มันน่าคลั่ง: en.wikipedia.org/wiki/HTTP_referer

— kmiklas

1

@DaveMcClelland ทำให้มันเป็น 70 จาก 69: D;)

— VdeX

28

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

— abyx
แหล่งที่มา

1

คุณจะมั่นใจได้อย่างไรว่ามันไม่มีการเปลี่ยนแปลงประสิทธิภาพ? ตัวอย่างการแยกแยะอาจเป็นเพราะการเปลี่ยนแปลงโครงสร้างข้อมูลภายในเช่นจาก HashSet เป็น TreeSet เป็นต้น

— aioobe

@aioobe - เพื่อความเข้าใจของฉัน OP ถามว่าการโทรรหัสที่เลิกใช้มีปัญหาด้านประสิทธิภาพหรือไม่ซึ่งไม่ได้ระบุว่าจะไม่เปลี่ยนรหัสไบต์ที่ผลิต (ก่อนหน้า 1.5 เป็น javadoc ตอนนี้มีการใช้คำอธิบายประกอบ แต่ ยังไม่มีการเปลี่ยนแปลงกับประสิทธิภาพ)

— abyx

เมื่อไปจากไลบรารีหนึ่งเวอร์ชันไปยังอีกเวอร์ชันหนึ่งจะไม่มีการรับประกันว่าโค้ดไบต์ของวิธีการในเวอร์ชันใหม่จะเหมือนกับโค้ดไบต์ของวิธีการเดียวกันในเวอร์ชันก่อนหน้า

— aioobe

@aioobe - มีการรับประกันว่าเพียงแค่ทำให้เลิกใช้แล้วจะไม่เปลี่ยนรหัสไบต์ซึ่งเป็นสิ่งที่ฉันคิดว่า OP หมายถึง แน่นอนว่ารหัสนั้นมีการเปลี่ยนแปลงซึ่งเป็นสาเหตุที่เราไม่ยอมรับรหัส

— abyx

หากคุณใช้เวอร์ชันเดิมเหมือนเดิมจะไม่มีการเปลี่ยนแปลงใด ๆ แต่ถ้าคุณใช้ไลบรารีเวอร์ชันที่ใหม่กว่าและพวกเขาไม่มีการคัดค้าน API จะมีการเปลี่ยนแปลงในประสิทธิภาพหากการใช้งานพื้นฐานนั้นมีการเปลี่ยนแปลงอย่างมากและ API ใหม่ใช้ประโยชน์จากมันในขณะที่ API เก่าไม่เป็น มีประสิทธิภาพอย่างที่เคยเป็นเมื่อเทียบกับโครงสร้างที่ใหม่กว่านี้

— gregturn

21

คำศัพท์

จากอภิธานศัพท์ดวงอาทิตย์อย่างเป็นทางการ:

การคัดค้าน : อ้างถึงคลาส, อินเตอร์เฟส, ตัวสร้าง, เมธอดหรือฟิลด์ที่ไม่แนะนำให้ใช้อีกต่อไปและอาจหยุดอยู่ในเวอร์ชันอนาคต

จากวิธีการและเวลาที่จะคัดค้านคำแนะนำ:

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

@Deprecatedคำอธิบายประกอบไปขั้นตอนต่อไปและเตือนอันตราย:

องค์ประกอบของโปรแกรมมีคำอธิบายประกอบ @Deprecatedนั้นเป็นสิ่งที่โปรแกรมเมอร์ไม่แนะนำให้ใช้เพราะโดยปกติแล้วจะเป็นอันตรายหรือเพราะมีทางเลือกอื่นที่ดีกว่า

อ้างอิง

ถูกหรือผิด?

คำถามที่ว่ามันถูกหรือผิดที่จะใช้วิธีการที่เลิกใช้จะต้องมีการตรวจสอบเป็นรายบุคคล นี่คือเครื่องหมายคำพูดทั้งหมดที่คำว่า"เลิกใช้"ปรากฏในEffective Java 2nd Edition :

รายการที่ 7: หลีกเลี่ยง finalizers : วิธีการเดียวที่เรียกร้องให้การรับประกันการสรุปเป็นคู่ความชั่วร้ายของมันSystem.runFinalizersOnExit Runtime.runFinalizersOnExitวิธีการเหล่านี้มีข้อบกพร่องร้ายแรงและเลิกใช้แล้ว

รายการ 66: ซิงโครไนซ์การเข้าถึงข้อมูลที่ไม่แน่นอนที่ใช้ร่วมกัน : ไลบรารีให้Thread.stopวิธีการ แต่วิธีการนี้เลิกใช้มานานแล้วเนื่องจากไม่ปลอดภัยโดยเนื้อแท้- การใช้งานนั้นอาจทำให้ข้อมูลเสียหายได้

รายการ 70: ความปลอดภัยของเธรดเอกสาร : System.runFinalizersOnExitวิธีการนี้เป็นเธรดที่เป็นมิตรและเลิกใช้แล้ว

ไอเท็ม 73: หลีกเลี่ยงกลุ่มเธรด : อนุญาตให้คุณใช้พThreadริมิทีฟดั้งเดิมกับกลุ่มเธรดพร้อมกัน primitives เหล่านี้หลายตัวถูกเลิกใช้แล้วและส่วนที่เหลือถูกใช้ไม่บ่อยนัก [... ] กลุ่มเธรดล้าสมัย

ดังนั้นอย่างน้อยด้วยวิธีการข้างต้นทั้งหมดมันผิดอย่างชัดเจนที่จะใช้พวกเขาอย่างน้อยตาม Josh Bloch

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

คำถามที่เกี่ยวข้อง

ความแตกต่างระหว่าง API ที่เลิกใช้แล้วหรือไม่

— polygenelubricants
แหล่งที่มา

3

"เลิกใช้แล้ว" มาจากภาษาละติน "de" + "precare" หมายถึง "สวดภาวนา" เมื่อสิ่งที่อธิบายว่าเลิกใช้แล้วมาตรฐานกำลังสวดอ้อนวอน - ขอร้อง - คุณไม่ต้องใช้ เป็นการเตือนว่าอาจถูกลบออกในเวอร์ชันอนาคตของ Standard นั้น โปรดทราบว่าจำเป็นต้องใช้คุณลักษณะที่เลิกใช้แล้วในการปรับใช้เวอร์ชันปัจจุบันของมาตรฐานนั้น แม้ว่าการเอ่ยถึงอารมณ์ขันที่ลดค่าตัวเองของคุณนั้นเป็นเพียงเล็กน้อย "การลดค่าตัวเอง" ในแง่นี้คือการคอร์รัปชั่นของ "การลดค่าตัวเอง" ซึ่งมีรากศัพท์และความหมายต่างกัน

— dajames

17

นอกเหนือจากการตอบกลับที่ยอดเยี่ยมทั้งหมดข้างต้นฉันพบว่ามีเหตุผลอีกประการที่จะลบการเรียก API ที่เลิกใช้แล้ว

ค้นคว้าว่าทำไมการโทรจึงเลิกฉันมักพบว่าตัวเองเรียนรู้สิ่งที่น่าสนใจเกี่ยวกับ Java / API / the Framework มักจะมีเหตุผลที่ดีว่าทำไมวิธีการที่ถูกเลิกใช้และการเข้าใจเหตุผลเหล่านี้นำไปสู่ข้อมูลเชิงลึก

ดังนั้นจากมุมมองการเรียนรู้ / การเติบโตมันเป็นความพยายามที่คุ้มค่า

— Peter Tillemans
แหล่งที่มา

11

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

— Michael Mrozek
แหล่งที่มา

1

เมื่อพิจารณาจากประสบการณ์ "เลิกใช้แล้ว" จริงๆแล้วหมายถึง "คุณไม่ควรใช้สิ่งนี้อีกต่อไป แต่จะใช้ได้ตลอดไป" อย่างน้อยสำหรับ Java Standard API ฉันไม่ได้ตระหนักถึงวิธีการหรือชั้นเรียนใด ๆ ที่ถูกลบจริงหลังจากเลิกใช้งานแล้ว

— Michael Borgwardt

1

@Michael ในทางปฏิบัติ APIs มักจะลบฟังก์ชั่นที่เลิกใช้แล้วเพราะพวกเขาสามารถเลิกใช้งานได้สิบปีโดยคอมไพเลอร์จะแสดงข้อความ "คำเตือน: หยุดการใช้งานคุณแบบนี้" และผู้คนก็จะยัง ฉันคิดว่าเลิกคิดว่าควรจะหมายถึง "สักวันหนึ่งเราต้องการที่จะเอาออกดังนั้นโปรดหยุดใช้" แม้ว่าในทางปฏิบัติมันไม่ค่อยเกิดขึ้นจริง

— Michael Mrozek

@Michael Mrozek: ไม่เห็นด้วยกับคำสั่งIt certainly doesn't create a performance issue; มันอัตนัยเกินไปที่จะระบุว่า

— KMån

1

@KMan ฟังก์ชั่นที่ถูกทำเครื่องหมายว่าเลิกใช้แล้วไม่ได้ทำให้ประสิทธิภาพลดลง แต่อย่างใดก่อนที่มันจะถูกทำเครื่องหมาย - มันจะทำงานเหมือนกับเมื่อก่อน

— Michael Mrozek

@Michael Borgwardt: นั่นเป็นวิธีการทำงานในภาษาที่ได้มาตรฐานมากที่สุด และแน่นอนหากมีการคัดค้านสิ่งใดที่จะถูกลบออกจากมาตรฐานการใช้งานที่นิยมจะทำให้มันเป็นส่วนขยาย

— David Thornley

8

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

— Bozhidar Batsov
แหล่งที่มา

8

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

พยายามหลีกเลี่ยง

— Jigar Joshi
แหล่งที่มา

4

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

— Esko
แหล่งที่มา

3

ใช่มันผิด

เมธอดหรือคลาสที่เลิกใช้แล้วจะถูกลบใน Java เวอร์ชันอนาคตและไม่ควรใช้ ในแต่ละกรณีควรมีทางเลือกอื่น ใช้มัน

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

เมื่อคุณอัพเกรดเป็น Java เวอร์ชันใหม่หรือไลบรารี่อื่น ๆ บางครั้งวิธีการหรือคลาสที่คุณใช้จะเลิกใช้แล้ว ไม่รองรับวิธีการที่เลิกใช้แล้ว แต่ไม่ควรให้ผลลัพธ์ที่ไม่คาดคิด แต่นั่นไม่ได้หมายความว่าพวกเขาจะไม่ได้ดังนั้นเปลี่ยนรหัสของคุณโดยเร็ว

กระบวนการคัดค้านอยู่ที่นั่นเพื่อให้แน่ใจว่าผู้เขียนมีเวลาพอที่จะเปลี่ยนรหัสผ่านจาก API เก่าเป็น API ใหม่ ใช้ประโยชน์จากเวลานี้ เปลี่ยนรหัสของคุณผ่าน ASAP

— Erick Robertson
แหล่งที่มา

2

มันไม่ผิด แต่วิธีการที่เลิกใช้แล้วบางส่วนจะถูกลบออกไปในซอฟต์แวร์รุ่นต่อ ๆ ไปดังนั้นคุณอาจจบลงด้วยรหัสที่ไม่ทำงาน

— Petar Minchev
แหล่งที่มา

Removed? ดูคำจำกัดความของstackoverflow.com/questions/2941900/…

— KMån

1

@KMan - ในลิงค์ที่คุณโพสต์มันเขียนไว้ - "วิธีการเก็บรักษาไว้ใน API สำหรับความเข้ากันได้แบบย้อนหลังสำหรับช่วงเวลาที่ไม่ได้ระบุและอาจถูกลบในอนาคต" ฉันได้เขียนเหมือนกัน - วิธีการคัดค้านบางอย่างอาจถูกลบออกในอนาคตอันใกล้หรือไกล

— Petar Minchev

2

ผิดหรือไม่ที่จะใช้เมธอดหรือคลาสที่เลิกใช้แล้วใน Java? "

ไม่ผิดเช่นนั้น แต่มันสามารถช่วยให้คุณเดือดร้อน นี่คือตัวอย่างที่ไม่แนะนำให้ใช้วิธีที่ไม่สนับสนุน:

http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html

ทำไม Thread.stop เลิกใช้แล้ว?

เพราะมันไม่ปลอดภัยโดยเนื้อแท้ การหยุดเธรดทำให้ต้องปลดล็อกจอภาพทั้งหมดที่ล็อคไว้ (จอภาพถูกปลดล็อกเป็นข้อยกเว้น ThreadDeath แพร่กระจายสแต็ก) หากวัตถุใด ๆ ที่ป้องกันก่อนหน้านี้โดยจอภาพเหล่านี้อยู่ในสถานะไม่สอดคล้องกันเธรดอื่น ๆ อาจดูวัตถุเหล่านี้ในสถานะไม่สอดคล้องกัน วัตถุดังกล่าวได้รับความเสียหาย เมื่อเธรดทำงานบนวัตถุที่เสียหายอาจส่งผลให้เกิดการทำงานตามอำเภอใจ พฤติกรรมนี้อาจบอบบางและตรวจจับได้ยากหรืออาจเด่นชัด ไม่เหมือนกับข้อยกเว้นอื่น ๆ ที่ไม่ได้ตรวจสอบ ThreadDeath จะฆ่าเธรดอย่างเงียบ ๆ ดังนั้นผู้ใช้จึงไม่มีคำเตือนว่าโปรแกรมของเขาอาจเสียหาย การคอร์รัปชั่นสามารถปรากฏตัวได้ตลอดเวลาหลังจากความเสียหายที่เกิดขึ้นจริงแม้กระทั่งชั่วโมงหรือวันในอนาคต

หากไม่มีการเปลี่ยนแปลงวิธีการใด ๆ และเรียกใช้แอปพลิเคชันของฉันด้วยคำเตือนที่ฉันมีจะเป็นการสร้างปัญหาด้านประสิทธิภาพหรือไม่

ไม่ควรมีปัญหาในแง่ของประสิทธิภาพ API มาตรฐานถูกออกแบบมาเพื่อเคารพความเข้ากันได้แบบย้อนหลังบางอย่างดังนั้นแอปพลิเคชันสามารถปรับให้เข้ากับ Java เวอร์ชันใหม่กว่าได้

— เจมส์พี
แหล่งที่มา

2

การใช้เมธอดหรือคลาสที่เลิกใช้ใน Java ผิดหรือไม่? มันไม่ได้ "ผิด" แต่ก็ยังใช้งานได้ แต่ให้หลีกเลี่ยงมากที่สุด

สมมติว่ามีช่องโหว่ความปลอดภัยที่เกี่ยวข้องกับวิธีการและนักพัฒนาระบุว่าเป็นข้อบกพร่องในการออกแบบ ดังนั้นพวกเขาอาจตัดสินใจเลิกใช้วิธีการและแนะนำวิธีการใหม่

ดังนั้นหากคุณยังคงใช้วิธีเดิมคุณมีภัยคุกคาม ดังนั้นควรตระหนักถึงเหตุผลในการคัดค้านและตรวจสอบว่ามีผลกระทบกับคุณหรือไม่

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

หากการคัดค้านเกิดจากปัญหาด้านประสิทธิภาพคุณจะประสบปัญหาด้านประสิทธิภาพไม่เช่นนั้นไม่มีเหตุผลที่จะมีปัญหาดังกล่าว อีกครั้งต้องการที่จะชี้ให้เห็นถึงเหตุผลในการคัดค้าน

— Chathuranga Chandrasekara
แหล่งที่มา

2

ใน Java เป็น @Deprecated ใน C # เป็น [ล้าสมัย]

ฉันคิดว่าฉันชอบคำศัพท์ของ C # มันหมายถึงมันล้าสมัย คุณยังสามารถใช้งานได้หากคุณต้องการ แต่อาจมีวิธีที่ดีกว่า

มันเหมือนกับการใช้ Windows 3.1 แทน Windows 7 หากคุณเชื่อว่า Windows 3.1 นั้นล้าสมัย คุณยังคงสามารถใช้งานได้ แต่อาจมีคุณสมบัติที่ดีกว่าในรุ่นอนาคตรวมถึงรุ่นในอนาคตที่อาจได้รับการสนับสนุน - รุ่นที่ล้าสมัยจะไม่เป็นเช่นนั้น

เช่นเดียวกันกับ @Deprecated ของ Java - คุณยังคงสามารถใช้วิธีนี้ได้ แต่ในความเสี่ยงของคุณเอง - ในอนาคตอาจมีทางเลือกที่ดีกว่าและอาจไม่ได้รับการสนับสนุน

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

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

— jamiebarrow
แหล่งที่มา

1

"หากคุณกำลังใช้รหัสที่เลิกใช้แล้วก็ใช้ได้ตราบใดที่คุณไม่จำเป็นต้องอัปเกรดเป็น API ที่ใหม่กว่า" - ไม่มากนัก ดูสาเหตุที่ Thread.stop () เลิกใช้แล้วและคุณจะเห็นว่าไม่เหมาะใน JRE เวอร์ชั่นใด ๆ

— ไมเคิล

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

— jamiebarrow

1

ไม่แน่นอน - เนื่องจาก Java ทั้งหมดได้รับ @Deprecated :-) คุณสามารถใช้มันได้นานตราบเท่าที่ Java ยังคงอยู่ จะไม่สังเกตเห็นความแตกต่างใด ๆ อยู่ดีเว้นเสียแต่ว่าจะเป็นอะไรที่หัก ความหมาย - ต้องอ่านเกี่ยวกับเรื่องนี้แล้วตัดสินใจ

อย่างไรก็ตามใน. Net เมื่อมีการประกาศ [เลิกใช้] ให้ไปอ่านทันทีแม้ว่าคุณจะไม่เคยใช้มาก่อน - คุณมีโอกาสประมาณ 50% ที่จะมีประสิทธิภาพมากขึ้นและ / หรือใช้งานง่ายกว่าการแทนที่ :-))

โดยทั่วไปแล้วมันจะมีประโยชน์มากถ้าเป็นสมัยที่อนุรักษ์นิยมด้านเทคโนโลยี แต่คุณต้องทำงานที่ต้องอ่านก่อน

— ZXX
แหล่งที่มา

1

ฉันรู้สึกว่าวิธีการเลิกใช้หมายความว่า; มีวิธีสำรอง = ive ใช้ได้ซึ่งดีกว่าในทุกด้านกว่าวิธีที่มีอยู่ ดีกว่าที่จะใช้วิธีการที่ดีกว่าวิธีเก่าที่มีอยู่ สำหรับความเข้ากันได้แบบย้อนหลังวิธีเก่าจะถูกทิ้งไว้ตามที่ไม่สนับสนุน

— DPM
แหล่งที่มา