作为装饰器的集合:伪代码实现建议 [英] Collections as decorators: pseudo-code implementation proposal

问题描述

在等待 问题的答案的同时，我想讨论一下可能的实施计划/细节，甚至一般来说甚至回答实施以下内容的难度以及为此需要哪些工具/技术:

Meanwhile waiting for the answer on the question I would like to discuss the possible implementation plan/details or in general even answer how hard would be to implement the following and which tools/techniques are necessary for that:

(摘自所提到的问题):

(excerpt from the referred question):

假设你需要实现很多(子)类型的集合.其中一个方面与存储相关:list，array 等，而另一个是行为相关:有序，删除only, observable(触发每次更改时的事件)等

Suppose you need to implement many (sub)types of collections. One of the aspects is storage-related: list, array etc, while the other is behavior-related: ordered, remove only, observable (the one that fires an event upon every change) etc.

显然(再次)，要求直接映射到众所周知的装饰器设计模式，其中存储相关aspect (list, array) 将被多个装饰行为(有序、可观察等).

Obviously (again), the requirement maps directly to the well-known Decorator design pattern, where the storage-related aspect (list, array) will be decorated by multiple behavioral (ordered, observable etc).

到目前为止，我想在(类 Java)伪代码中提出一些相当短的实现，同时询问是否可以在 Java 或 C# 中实现以下内容，如果不能，则使用任何其他现代编程语言:

So far, I would like to propose some reasonably short implementation in (Java-like) pseudo-code, while asking if it's possible to implement the following in Java or C# or, if not, then in any other modern programming language:

每个集合必须支持的基本接口:

Basic interface every collection must support:

interface Collection {
    [mutator]
    public void add(object o);

    [mutator]
    public void remove(object o);

    [accessor]
    public object get(int i);
}

存储方面:

列表实现:

class List : Collection {
    [mutator]
    public void add(object o) { ... }

    [mutator]
    public void remove(object o) { ... }

    [accessor]
    public object get(int i) { ... }
}

数组实现:

class Array : Collection {
    [mutator]
    public void add(object o) { ... }

    [mutator]
    public void remove(object o) { ... }

    [accessor]
    public object get(int i) { ... }
}

行为方面:

线程安全装饰器:

typename<T> : where T is Collection
class ThreadSafe : Collection {
    private T m_source;
    private object m_lock = new object();

    [mutator]
    public void add(object o) { 
        using (m_lock) {
            m_source.add();
        }
    }

    [mutator]
    public void remove(object o) { ... }

    [accessor]
    public object get(int i) { ... }
}

Observable 装饰器:

class ChangeEvent {
    public Collection Source { get; private set; }
    public Method UpdateType { get; private set; }
}

interface Observer {
    public notifyChange(ChangeEvent e);
}

typename<T> : where T is Collection
class Observable : Collection {
    public Observer Observer { get; set; } // additional property
    private T m_source;

    [mutator]
    public void add(object o) {
        if (Observer != null) {
            var event = new ChangeEvent() { Source = this, UpdateType = GetCurrentMethod() };
            Observer.notifyChange(event);
        }
        m_source.add(o);
    }

    [mutator]
    public void remove(object o) { ... }

    [accessor]
    public object get(int i) { ... }
}

有序装饰器:

typename<T> : where T is Collection
class Ordered : Collection {
    private T m_source;

    [mutator]
    public void add(object o) {
        int idx = findProperPosition(); // assumed possible using the base Collection interface
        ...
        m_source.add(o);
    }

    [mutator]
    public void remove(object o) { ... }

    [accessor]
    public object get(int i) { ... }
}

只读装饰器:

typename<T> : where T is Collection
class ReadOnly : Collection {
    private T m_source;

    [mutator]       
    public void add(object o) { throw IllegalOperationException(...); }

    [mutator]
    public void remove(object o) { throw IllegalOperationException(...); }

    [accessor]
    public object get(int i) { return m_source.get(i); }
}

到目前为止，以上只是伪代码，但目标是使客户端代码能够构造多种集合，以便每种集合可以组合任意数量的存储方面>行为相关的方面.能够在编译时构建这些复合类型会非常好，并且即使在运行时生成它们也非常方便.

So far, the above is pseudocode only, but the goal is to enable the client code to construct many kinds of collections, so that each kind can combine exactly one storage aspect any number of behavior-related aspects. Would be pretty nice to be able to construct those composite types in compile-time and super-handy to generate those even at run-time.

问题是如何(任何现代编程语言都算数)?

The question is how (any modern programming language counts)?

推荐答案

我不明白你不理解的方面.Java 集合已经有了这个并且源是公开的.具有线程安全和不可修改的装饰器.此外，许多类型都有 fascade 方法，例如asList()".

I don't understand what aspect of how that you don't understand. The Java collections has this already and the source is public. The have decorators for thread-safe and unmodifyable. Also, many types have fascade methods such as "asList()".

既然如此，你的问题还剩下什么?

Given that, what is left of your question?

如何制作未订购的东西?比如，如何创建一个将 HashMap 变成 LinkedHaskMap 的装饰器?这样的装饰器可以使用内部数据结构来构建以维护秩序.

How to make something that is not ordered ordered? Like, how to create a decorator that turns a HashMap into a LinkedHaskMap? Such a decorator could be built with an internal data structure to maintain order.

这篇关于作为装饰器的集合:伪代码实现建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！