Есть ли способ ограничить доступ к общедоступному методу только определенным классом в C#?

у меня есть класс A с открытым методом в C#. Я хочу разрешить доступ к этому методу только классу B. возможно ли это?

обновление:

вот что я хотел бы сделать:

public class Category
{
    public int NumberOfInactiveProducts {get;}
    public IList<Product> Products {get;set;}

    public void ProcessInactiveProduct()
    {
        // do things...

        NumberOfInactiveProducts++;
    }
}

public class Product
{
    public bool Inactive {get;}
    public Category Category {get;set;}

    public void SetInactive()
    {
        this.Inactive= true;
        Category.ProcessInactiveProduct();
    }
}

Я хотел бы, чтобы другие программисты сделали:

var prod = Repository.Get<Product>(id);
prod.SetInactive();

Я хотел бы убедиться, что они не вызывают ProcessInactiveProduct вручную:

var prod = Repository.Get<Product>(id);
prod.SetInactive();
prod.Category.ProcessInactiveProduct();

Я хочу разрешить доступ к категории.ProcessInactiveProduct только класс продукта. Другое занятие не должен быть в состоянии назвать категорию.ProcessInactiveProduct.

7
c# oop

5 ответов

поместите оба класса в отдельную сборку и сделайте метод внутренним.

18

вы можете, если вы делаете класс A частный, вложенный класс внутри класс B:

class B
{
    class A
    {
        public Int32 Foo { get; set; }
    }
}

только B сможет видеть A и это члены в этом примере.

в качестве альтернативы вы можете гнездиться B внутри A:

class A
{
    Int32 Foo { get; set; }

    public class B { }
}

в этом случае каждый может видеть оба A и B, но только B видим A.Foo.

2

вы можете ограничить доступ к методу/классу следующим образом:

[StrongNameIdentityPermissionAttribute(SecurityAction.Demand, PublicKey="…hex…", Name="App1", Version="0.0.0.0")]
public class Class1 { }

Взгляните сюда http://msdn.microsoft.com/en-us/library/c09d4x9t.aspx для получения дополнительной информации.

управляемый код предлагает несколько способов ограничения метод открыть:
...

  • ограничить доступ метода к вызывающим абонентам заданного идентификатора-по существу, любое конкретное доказательство (строгое Имя, издатель, зона и т. д) вы выбрать.
1

для вашего вопроса нет готового ответа.

Если они уже находятся в одной сборке, почему бы не сделать метод внутренним?

Если они находятся в разных сборках, вы можете использовать "друг" синтаксис, который охватывает все внутренние методы.

вероятно, ваше лучшее решение-ограничить доступ к открытым методам для конкретной сборки(сборок). Это означает, что кто-то не может просто написать новую сборку и идти вперед назовите свои публичные методы. Учитывая, что у вас, похоже, есть модель домена, похоже, вы должны разрешить этот метод вызываться из других объектов домена, но, возможно, не из бизнес-логики. Это может быть достигнуто путем присвоения уникального строгого имени DLL модели домена.

вы можете ограничить доступ к открытому методу, чтобы разрешить его вызов только методами в сборках, удовлетворяющих заданному открытому ключу. см. В статье StrongNameIdentityPermission

0

вы можете использовать тип шаблона наблюдателя, где категория регистрирует интерес к определенным событиям на продукте (возможно, событие ProductInactivated?) и затем обрабатывать логику. Этот основанный на событии шаблон очень распространен и значительно уменьшает сцепление. Категория в конечном счете отвечает за свое собственное состояние и не полагается на то, что продукт знает что-то о том, что его содержит, чтобы сохранить состояние категории нетронутым. Продукт просто рассказывает заинтересованным клиенты когда все случилось.

другой вариант-рефакторировать класс Category так, чтобы он содержал или содержался каким-либо объектом CategoryProductServices, который инкапсулирует методы, которые продукт должен будет выполнить для своей содержащей категории. В контексте, создающем категории и продукты, передайте экземпляр этого объекта CategoryProductServices продукту, а не полной категории. Этот дизайн сохраняет интерфейс открытым, но предотвращает клиент получает доступ к службам, поскольку они не могут получить экземпляр. Это также ослабляет тесную связь продуктов с классом категорий, ограничивая ее только теми услугами, о которых продукты должны знать. Это оставляет продукт на попечении государства, но, по крайней мере, ограничивает то, что ему нужно знать/делать.

0