Question

我认为，我有一个关于如何处理代码中对象之间关系的基本OOP问题。我正在编写一个存储一些分层信息的工具，我看到了两个如何实现它的选项。我将提供一些（简化的）示例来支持我的思考过程。

在第一个想法中，我将实例化子元素，其中包含有关其父元素的信息（也就是说它们的托管容器）。然后子元素本身将负责对父对象的更改做出反应。但是，我想我稍后可能会遇到一些序列化问题，例如尝试通过JSON API公开结构时。

public class Garage : INotifyPropertyChanged
{
    public List<Car> ParkedCars { get; set; }
    public List<ParkingLot> ParkingLots { get; set; }
}

public class ParkingLot
{
    public string LotNumber { get; set; }
}

public class Car
{
    public Car(Garage ParentGarage, int LotIndex)
    {
        Garage = ParentGarage;
        AllocatedLot = Garage.ParkingLots[LotIndex];
        Garage.PropertyChanged += Garage_PropertyChanged;
    }
    void Garage_PropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e)
    {
        MoveToNewLot();
    }
    public ParkingLot AllocatedLot { get; set; }
    private Garage Garage {get;set;}
}

在第二种方法中，我不会告诉单个对象关于它的父对象，因此对象本身无法处理它的所有责任，例如对父元素的更改做出反应。父元素必须知道它的孩子，并负责通知他们有关变化。

public class Garage
{
    public Garage()
    {
        ParkingLots.CollectionChanged += Lot_CollectionChanged;
    }
    public List<Car> ParkedCars { get; set; }
    public ObservableCollection<ParkingLot> ParkingLots { get; set; }
    private void Lot_CollectionChanged(object sender, System.ComponentModel.CollectionChangeEventArgs e)
    {
        foreach (Car ParkedCar in ParkedCars)
        {
            ParkedCar.MoveToNewLot(ParkingLot NewLot);
        }
    }
}
public class ParkingLot
{
    public string LotNumber { get; set; }
}
public class Car
{
    public ParkingLot AllocatedLot { get; set; }

    private Garage Garage { get; set; }
}

实际代码类似于某些目录，例如对象层次结构，例如，重命名类别将触发在该类别中的子对象中引发PropertyChanged事件。

我赞成第一种方法，因为对我而言，让每个对象本身对其自身的状态负全部责任而不是依赖于＆＃34;外部＆＃34;确保有效状态的对象。

我的问题是，由于缺乏经验，哪个问题会更严重，更复杂的序列化还是必须跟踪对象依赖性和违反OOP原则？

是否还有其他解决方案我不知道应该如何处理这样的结构？

OOP体系结构不安全性：分层对象引用

0 个答案: