มีรูปแบบสำหรับวิธีการ "เพิ่มความเป็นธรรมชาติ" ในการเพิ่มรายการลงในคอลเลกชันหรือไม่? [ปิด]


13

ฉันคิดว่าวิธีทั่วไปในการเพิ่มบางอย่างลงในคอลเลกชันคือการใช้Addวิธีการบางอย่างที่คอลเลกชันมีให้:

class Item {}    
var items = new List<Item>();
items.Add(new Item());

และไม่มีอะไรผิดปกติเกี่ยวกับเรื่องนั้น

ฉันสงสัยว่าทำไมเราไม่ทำแบบนี้:

var item = new Item();
item.AddTo(items);

มันดูเป็นธรรมชาติมากกว่าวิธีแรกเลย นี้จะมี andvantange ว่าเมื่อItemชั้นมีคุณสมบัติเช่นParent:

class Item 
{
    public object Parent { get; private set; }
} 

คุณสามารถทำให้สุนัขเซทเทอร์เป็นส่วนตัวได้ ในกรณีนี้แน่นอนคุณไม่สามารถใช้วิธีการขยายได้

แต่บางทีฉันผิดและฉันไม่เคยเห็นรูปแบบนี้มาก่อนเพราะมันผิดปกติเหรอ? คุณรู้หรือไม่ว่ามีรูปแบบดังกล่าวหรือไม่

ในC#วิธีการขยายจะเป็นประโยชน์สำหรับการที่

public static T AddTo(this T item, IList<T> list)
{
    list.Add(item);
    return item;
}

แล้วภาษาอื่น ๆ ล่ะ? ฉันเดาว่าส่วนใหญ่ของพวกเขาในItemชั้นเรียนจะต้องให้มันเรียกว่าICollectionItemอินเตอร์เฟซ


ปรับปรุง-1

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

ICollectableอินเตอร์เฟซการทดสอบ:

interface ICollectable<T>
{
    // Gets a value indicating whether the item can be in multiple collections.
    bool CanBeInMultipleCollections { get; }

    // Gets a list of item's owners.
    List<ICollection<T>> Owners { get; }

    // Adds the item to a collection.
    ICollectable<T> AddTo(ICollection<T> collection);

    // Removes the item from a collection.
    ICollectable<T> RemoveFrom(ICollection<T> collection);

    // Checks if the item is in a collection.
    bool IsIn(ICollection<T> collection);
}

และการใช้งานตัวอย่าง:

class NodeList : List<NodeList>, ICollectable<NodeList>
{
    #region ICollectable implementation.

    List<ICollection<NodeList>> owners = new List<ICollection<NodeList>>();

    public bool CanBeInMultipleCollections
    {
        get { return false; }
    }

    public ICollectable<NodeList> AddTo(ICollection<NodeList> collection)
    {
        if (IsIn(collection))
        {
            throw new InvalidOperationException("Item already added.");
        }

        if (!CanBeInMultipleCollections)
        {
            bool isInAnotherCollection = owners.Count > 0;
            if (isInAnotherCollection)
            {
                throw new InvalidOperationException("Item is already in another collection.");
            }
        }
        collection.Add(this);
        owners.Add(collection);
        return this;
    }

    public ICollectable<NodeList> RemoveFrom(ICollection<NodeList> collection)
    {
        owners.Remove(collection);
        collection.Remove(this);
        return this;
    }

    public List<ICollection<NodeList>> Owners
    {
        get { return owners; }
    }

    public bool IsIn(ICollection<NodeList> collection)
    {
        return collection.Contains(this);
    }

    #endregion
}

การใช้งาน:

var rootNodeList1 = new NodeList();
var rootNodeList2 = new NodeList();

var subNodeList4 = new NodeList().AddTo(rootNodeList1);

// Let's move it to the other root node:
subNodeList4.RemoveFrom(rootNodeList1).AddTo(rootNodeList2);

// Let's try to add it to the first root node again... 
// and it will throw an exception because it can be in only one collection at the same time.
subNodeList4.AddTo(rootNodeList1);

13
item.AddTo(items)สมมติว่าคุณมีภาษาที่ไม่มีวิธีการขยาย: เป็นธรรมชาติหรือไม่, เพื่อรองรับ addTo ทุกประเภทจะต้องใช้วิธีนี้และให้มันสำหรับคอลเลกชันทุกประเภทที่สนับสนุนการต่อท้าย นั่นเป็นตัวอย่างที่ดีที่สุดในการแนะนำการพึ่งพาระหว่างทุกสิ่งที่ฉันเคยได้ยิน: P - ฉันคิดว่าสถานที่ที่ผิดพลาดที่นี่กำลังพยายามสร้างแบบจำลองการเขียนโปรแกรมบางอย่างที่เป็นนามธรรมเพื่อชีวิต 'จริง' มันมักจะผิดพลาด
stijn

1
@ t3chb0t ฮิฮิจุดดี ฉันสงสัยว่าภาษาพูดแรกของคุณมีอิทธิพลต่อสิ่งที่สร้างขึ้นดูเป็นธรรมชาติมากขึ้นหรือไม่ สำหรับฉันคนเดียวที่ดูเหมือนเป็นธรรมชาติadd(item, collection)แต่จะไม่ใช่สไตล์ OO ที่ดี
Kilian Foth

3
@ t3chb0t ในภาษาพูดคุณสามารถอ่านสิ่งต่าง ๆ ตามปกติหรือแบบสะท้อนกลับได้ "จอห์นโปรดเพิ่มแอปเปิ้ลนี้ลงในสิ่งที่คุณถืออยู่" vs "ควรเพิ่มแอปเปิ้ลในสิ่งที่คุณถืออยู่จอห์น" ในโลกของ OOP การสะท้อนกลับไม่สมเหตุสมผลนัก คุณไม่ได้ขอให้บางสิ่งบางอย่างได้รับผลกระทบจากวัตถุอื่นที่พูดโดยทั่วไป ที่อยู่ใกล้ใน OOP เป็นรูปแบบของผู้เข้าชม มีเหตุผลว่านี่ไม่ใช่บรรทัดฐานแม้ว่า
Neil

3
นี้มีการวางคันธนูดีรอบความคิดที่ดี
Telastyn

3
@ t3chb0t คุณอาจพบว่าคำนามในราชอาณาจักรเป็นการอ่านที่น่าสนใจ
พอล

คำตอบ:


51

ไม่item.AddTo(items)มันไม่เป็นธรรมชาติมากกว่านี้ ฉันคิดว่าคุณมิกซ์กับสิ่งต่อไปนี้:

t3chb0t.Add(item).To(items)

คุณอยู่ในที่items.Add(item)ไม่ใกล้กับภาษาอังกฤษตามธรรมชาติ แต่คุณไม่ได้ยินitem.AddTo(items)ภาษาอังกฤษตามธรรมชาติใช่มั้ย โดยปกติจะมีคนที่ควรเพิ่มรายการลงในรายการ ไม่ว่าจะเป็นเมื่อทำงานที่ซูเปอร์มาร์เก็ตหรือขณะทำอาหารและเพิ่มส่วนผสม

ในกรณีของภาษาการเขียนโปรแกรมเราจัดทำขึ้นเพื่อให้รายการทำทั้งสองอย่าง: จัดเก็บรายการและรับผิดชอบในการเพิ่มเข้าไปในตัวมันเอง

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

อย่างไรก็ตามรายการไม่มีอยู่โดยไม่มีรายการ (อย่างน้อยพวกเขาก็จะไร้ประโยชน์) ดังนั้นมันดีถ้าพวกเขารู้เกี่ยวกับรายการของพวกเขา - อย่างน้อยในรูปแบบทั่วไป


4

@ valentry ค่อนข้างถูกต้องเกี่ยวกับปัญหาการแยกข้อกังวล ชั้นเรียนไม่ควรรู้อะไรเลยเกี่ยวกับคอลเลกชันต่าง ๆ ที่อาจมี คุณไม่ต้องการเปลี่ยนคลาสไอเท็มทุกครั้งที่คุณสร้างคอลเลกชันใหม่

ที่กล่าวว่า ...

1. ไม่ใช่ Java

Java ไม่ได้ช่วยให้คุณที่นี่ แต่บางภาษามีความยืดหยุ่นมากขึ้นและขยายไวยากรณ์

ใน Scala รายการ items เพิ่ม (รายการ)มีลักษณะดังนี้:

  item :: items

โดยที่::เป็นผู้ดำเนินการซึ่งเพิ่มรายการลงในรายการ นั่นดูเหมือนสิ่งที่คุณต้องการมาก จริงๆแล้วมันเป็นน้ำตาลซินแทคติกสำหรับ

  items.::(item)

ที่::เป็นวิธีที่รายการสกาล่าซึ่งเทียบเท่าได้อย่างมีประสิทธิภาพของ Java list.add ดังนั้นในขณะที่ดูในเวอร์ชันแรกราวกับว่าไอเท็มถูกเพิ่มเข้ากับไอเท็มแต่ไอเท็มความจริงกำลังทำการเพิ่ม ทั้งสองเวอร์ชันเป็น Scala ที่ถูกต้อง

เคล็ดลับนี้ทำได้สองขั้นตอน:

  1. ในสกาล่าผู้ประกอบการเป็นเพียงวิธีการ หากคุณนำเข้ารายการ Java ลงใน Scala ดังนั้น items.add (รายการ)ก็สามารถเขียนรายการเพิ่มรายการได้ ในกาลา1 + 2เป็นจริง1. + (2) ในรุ่นที่มีช่องว่างมากกว่าจุดและเครื่องหมายวงเล็บสกาล่าเห็นวัตถุแรกมองหาวิธีการจับคู่คำถัดไปและ (หากวิธีการใช้พารามิเตอร์) ส่งผ่านสิ่งต่อไป (หรือสิ่ง) ไปยังวิธีการนั้น
  2. ในสกาล่าผู้ประกอบการที่สิ้นสุดในลำไส้ใหญ่มีความสัมพันธ์ที่เหมาะสมมากกว่าด้านซ้าย ดังนั้นเมื่อสกาล่าเห็นวิธีการนั้นจะมองหาเจ้าของวิธีทางด้านขวาและป้อนค่าตามค่าทางด้านซ้าย

หากคุณไม่สะดวกกับโอเปอเรเตอร์จำนวนมากและต้องการaddToของคุณสกาล่ามีตัวเลือกอื่น: การแปลงโดยนัย ต้องใช้สองขั้นตอน

  1. สร้างคลาส wrapper เรียกว่า, ListItemซึ่งรับไอเท็มใน Constructor และมีเมธอดaddToซึ่งสามารถเพิ่มไอเท็มนั้นเข้ากับรายการที่กำหนด
  2. สร้างฟังก์ชั่นที่รับไอเท็มเป็นพารามิเตอร์และส่งคืนListItemที่มีไอเท็มนั้น ทำเครื่องหมายเป็นนัย

หากมีการเปิดใช้งานการแปลงโดยนัยและ Scala จะเห็น

  item addTo items

หรือ

  item.addTo(items)

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

  ListItem.(item).addTo(items)

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

ตัวดำเนินการที่ปิดท้ายด้วยเครื่องหมายจุดคู่นั้นไม่สวยงาม แต่ไม่เป็นภัยคุกคาม

วิธีการทั้งสองรักษาหลักการของการแยกความกังวล คุณสามารถทำให้มันดูราวกับว่ารายการรู้เกี่ยวกับคอลเลกชัน แต่งานจะทำจริงที่อื่น ภาษาอื่นใดที่ต้องการให้ฟีเจอร์นี้แก่คุณอย่างน้อยก็ควรระมัดระวัง

2. Java

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

3. tl; dr

Scala เช่นเดียวกับภาษาอื่น ๆ สามารถช่วยให้คุณมีไวยากรณ์ที่เป็นธรรมชาติมากขึ้น Java สามารถเสนอรูปแบบบาร็อคที่น่าเกลียดเท่านั้น


2

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

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


หากกรอบการทำงานคือการรับรู้การอ้างอิงวัตถุประเภทต่าง ๆ (เช่นการแยกความแตกต่างระหว่างการห่อหุ้มความเป็นเจ้าของและผู้ที่ไม่ได้) มันอาจทำให้รู้สึกว่ามีวิธีการที่การอ้างอิงที่ห่อหุ้มความเป็นเจ้าของสามารถสละกรรมสิทธิ์ในการสะสม ความสามารถในการรับมัน หากแต่ละสิ่ง จำกัด อยู่ที่การมีเจ้าของคนเดียวการโอนความเป็นเจ้าของผ่านทางthing.giveTo(collection)[และต้องcollectionใช้อินเทอร์เฟซ "acceptOwnership"] จะสมเหตุสมผลมากกว่าการcollectionมีวิธีการที่ยึดความเป็นเจ้าของ แน่นอน ...
supercat

... สิ่งต่าง ๆ ใน Java ไม่มีแนวคิดเรื่องความเป็นเจ้าของและการอ้างอิงวัตถุอาจถูกเก็บไว้ในกลุ่มโดยไม่เกี่ยวข้องกับวัตถุที่ระบุ
supercat

1

ฉันคิดว่าคุณกำลังหมกมุ่นอยู่กับคำว่า "เพิ่ม" ลองค้นหาคำอื่นแทนเช่น "collect" ซึ่งจะให้ไวยากรณ์ที่เป็นมิตรกับภาษาอังกฤษมากขึ้นโดยไม่มีการเปลี่ยนแปลงรูปแบบ:

items.collect(item);

วิธีการข้างต้นเป็นแบบเดียวกันitems.add(item);กับที่มีความแตกต่างเพียงการเลือกคำที่แตกต่างกันและไหลอย่างมากและ "เป็นธรรมชาติ" ในภาษาอังกฤษ

บางครั้งเพียงแค่ตั้งชื่อตัวแปรวิธีการคลาส ฯลฯ จะป้องกันการจัดเก็บภาษีการออกแบบลวดลายใหม่


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

@toniedzwiedz, เพื่อพิจารณาหรือpush enqueueจุดไม่ใช่ชื่อตัวอย่างที่เฉพาะเจาะจง แต่ความจริงที่ว่าชื่ออื่นอาจใกล้เคียงกับความปรารถนาของ OP สำหรับไวยากรณ์ภาษาอังกฤษ
Brian S

1

แม้ว่าจะไม่มีรูปแบบดังกล่าวสำหรับกรณีทั่วไป (ตามที่อธิบายโดยคนอื่น) แต่บริบทที่รูปแบบที่คล้ายคลึงกันมีข้อดีอยู่ที่การเชื่อมโยงแบบหนึ่งต่อหลายทิศทางแบบสองทิศทางใน ORM

ในบริบทนี้คุณจะมีสองหน่วยงานสมมติว่าและParent Childผู้ปกครองสามารถมีลูกหลายคน แต่เด็กแต่ละคนเป็นของผู้ปกครองคนหนึ่ง หากแอปพลิเคชันต้องการให้การเชื่อมโยงสามารถนำทางได้จากปลายทั้งสองด้าน (แบบสองทิศทาง) คุณจะต้องมีList<Child> childrenคลาสผู้ปกครองและParent parentชั้นเรียนย่อย

แน่นอนว่าสมาคมควรมีการแลกเปลี่ยนซึ่งกันและกัน โดยทั่วไปโซลูชัน ORM จะบังคับใช้สิ่งนี้กับเอนทิตีที่โหลด แต่เมื่อแอปพลิเคชั่นกำลังจัดการเอนทิตี (ไม่ว่าจะอยู่หรือใหม่) ก็จะต้องบังคับใช้กฎเดียวกัน จากประสบการณ์ของฉันคุณมักจะพบParent.addChild(child)วิธีที่จะเรียกใช้Child.setParent(parent)ซึ่งไม่ได้มีไว้เพื่อสาธารณะ ในระยะหลังคุณมักจะพบเช็คเดียวกันกับที่คุณติดตั้งในตัวอย่างของคุณ อย่างไรก็ตามเส้นทางอื่นสามารถนำไปใช้ได้เช่นกัน: การChild.addTo(parent)โทรParent.addChild(child)ใด เส้นทางไหนดีที่สุดแตกต่างจากสถานการณ์ต่อสถานการณ์


1

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

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

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


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

@gnat: ดีกว่าเหรอ?
SuperCat

1
@gnat: ขออภัย - อาการสะอึกของเครือข่ายทำให้ฉันพยายามโพสต์การแก้ไขล้มเหลว คุณชอบตอนนี้หรือไม่
supercat

-2

item.AddTo(items)ไม่ได้ใช้เพราะเป็นแบบพาสซีฟ Cf "ไอเท็มถูกเพิ่มในรายการ" และ "ห้องถูกทาสีโดยมัณฑนากร"

สิ่งปลูกสร้างแบบพาสซีฟนั้นใช้ได้ดี แต่อย่างน้อยก็ในภาษาอังกฤษเรามักจะชอบสิ่งปลูกสร้างที่ใช้งานอยู่

ในการเขียนโปรแกรม OO, pardigm ให้ความสำคัญกับนักแสดงผู้ไม่ดำเนินการใด ๆ items.Add(item)เพื่อให้เรามี รายการคือสิ่งที่ทำอะไรบางอย่าง มันเป็นนักแสดงดังนั้นนี่เป็นวิธีที่เป็นธรรมชาติมากขึ้น


มันขึ้นอยู่กับว่าคุณยืนอยู่ตรงไหน ;-) - ทฤษฎีสัมพัทธภาพ - คุณสามารถพูดแบบเดียวกันเกี่ยวกับlist.Add(item) รายการที่ถูกเพิ่มลงในรายการหรือรายการเพิ่มรายการหรือเกี่ยวกับitem.AddTo(list) รายการเพิ่มตัวเองลงในรายการหรือฉันเพิ่มรายการ ในรายการหรือชอบที่คุณพูดว่ารายการนั้นถูกเพิ่มลงในรายการ - ทั้งหมดถูกต้อง ดังนั้นคำถามคือใครเป็นนักแสดงและทำไม? ไอเท็มยังเป็นนักแสดงและต้องการเข้าร่วมกลุ่ม (รายการ) ไม่ใช่กลุ่มที่ต้องการมีไอเท็มนี้ ;-) ไอเท็มทำหน้าที่อย่างแข็งขันในกลุ่ม
t3chb0t

นักแสดงเป็นสิ่งที่ทำสิ่งที่ใช้งานอยู่ "ต้องการ" เป็นสิ่งที่ไม่โต้ตอบ ในการเขียนโปรแกรมเป็นรายการที่เปลี่ยนแปลงเมื่อมีการเพิ่มรายการลงไปรายการนั้นไม่ควรเปลี่ยนแปลงเลย
Matt Ellen

... แม้ว่ามันมักจะไม่ชอบเมื่อมีParentทรัพย์สิน ภาษาอังกฤษเป็นที่ยอมรับไม่ใช่ภาษาพื้นเมือง แต่เท่าที่ฉันรู้ว่าสิ่งที่ต้องการนั้นไม่ได้เกิดขึ้นหากฉันไม่ต้องการหรือเขาต้องการให้ฉันทำอะไรสักอย่าง ; -]
t3chb0t

คุณทำอะไรเมื่อคุณต้องการอะไร นั่นคือประเด็นของฉัน มันไม่จำเป็นต้องแฝงด้วยไวยากรณ์แต่จำเป็นต้องมีความหมาย แอตทริบิวต์หลักของ WRT แน่ใจว่าเป็นข้อยกเว้น แต่ฮิวริสติกทั้งหมดมีไว้
Matt Ellen

แต่List<T>(อย่างน้อยที่พบในSystem.Collections.Generic) ไม่อัปเดตParentคุณสมบัติใด ๆเลย มันจะเป็นไปได้อย่างไรถ้ามันควรจะเป็นแบบทั่วไป มันเป็นความรับผิดชอบของภาชนะที่จะเพิ่มเนื้อหาของมัน
Arturo Torres Sánchez
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.