Внутренний член в интерфейсе

Я не думаю, что вам следует использовать здесь интерфейс, возможно, вам следует использовать абстрактную базу, например:

public abstract class AM
{
    public int ID { get; set; }
    internal abstract void Save();
}

public class concreteIAM : AM
{
    internal override void Save()
    {
        //Do some save stuff
    }
}

По-прежнему позволит вам это сделать:

public class AMList : List<AM>
{
    public void SaveItems()
    {
        foreach (var item in this)
        {
            item.Save();
        }
    }
}

Если вы не хотите, чтобы внешние вызывающие абоненты могли вызывать ваш метод Save (), почему бы не сделать весь класс конкретногоIAM внутренним?

Или, если вы хотите, чтобы класс был общедоступным, но не интерфейс, сделайте весь интерфейс внутренним. Я думаю, что внутренний интерфейс можно добавить к общедоступному классу (но я не пробовал ...)

Возможно, вы хотите разделить сохранение ваших элементов в другой набор классов, которые являются внутренними для вашей сборки:

internal interface IAMSaver { void Save(IAM item); }

internal class AMSaverFactory {
  IAMSaver GetSaver(Type itemType) { ... }
}

public class MyList : List<IAM>
{
  public void Save()
  {
    foreach (IAM itemin this)
    {
      IAMSaver saver = SaverFactory.GetSaver(item.GetType());
      saver.Save(item)
    }
  }
}

Члены интерфейса должны быть общедоступными ... все остальное, и вы должны думать, если вам что-то еще нужно. В этом случае вы

• хотите, чтобы Save был членом интерфейса
• хотите, чтобы сохранение было разрешено только через другой класс MyList, который находится в той же сборке
• запретить вызов Save извне (из других классов вне родительской сборки)

Отложив в сторону мысли о дизайне, вы можете сделать это с помощью явной реализации интерфейса.

    internal interface IPersist
    {
        void Save();
    }
    public class Concrete : IPersist
    {
        void IPersist.Save()
        {
            Console.WriteLine("Yeah!");
        }
    }

// Mylist.cs in the same assembly can still call save like
public void SaveItems()
    {
        foreach (IPersist item in this)
        {
            item.Save();
        }
    }

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

new Concrete().Save();     // doesn't compile. 'Concrete' does not contain a definition for 'Save'

Обновлять Судя по вашему последнему ответу, у нас больше ограничений. Интерфейс должен быть общедоступным, он должен содержать метод Save, который не должен быть общедоступным. Я бы сказал, вернись к чертежной доске ... что-то не так. ИМХО Вы не можете этого сделать с одним интерфейсом. Как насчет разделения на 2 интерфейса, публичный и внутренний?

Я думаю, вы не понимаете, для чего нужен интерфейс. Интерфейс - договор. Он указывает, что объект ведет себя определенным образом. Если объект реализует интерфейс, это означает, что вы можете положиться на него, поскольку в нем реализованы все методы интерфейса.

Теперь подумайте, что бы произошло, если бы существовал интерфейс, о котором вы просите, - общедоступный, но с одним внутренним членом. Что бы это значило? Внешний объект может реализовывать только общедоступные методы, но не внутренний. Когда вы получите такой внешний объект, вы сможете вызывать только общедоступные методы, но не внутренний, потому что объект не может его реализовать. Другими словами - договор не будет выполняться. Не все методы будут реализованы.

Я думаю, что выход в этом случае - разделить ваш интерфейс на две части. Один интерфейс будет общедоступным, и это то, что будут реализовывать ваши внешние объекты. Другой интерфейс будет внутренним и будет содержать ваш Save() и другие внутренние методы. Возможно, этот второй интерфейс может даже унаследовать от первого. Тогда ваши собственные внутренние объекты будут реализовывать оба интерфейса. Таким образом вы даже можете различать внешние объекты (те, у которых нет внутреннего интерфейса) и внутренние объекты.

Пойдите с двумя интерфейсами:

public interface IAM
{
        int ID { get; set; }
}


internal interface IAMSavable
{
        void Save();
}

public class concreteIAM : IAM, IAMSavable
{
         public int ID{get;set;}
         public void IAMSavable.Save(){
         //save the object
         }

        //other staff for this particular class
}

public class MyList : List<IAM>
{
        public void Save()
        {
                foreach (IAM iam in this)
                {
                        ((IAMSavable)iam).Save();
                }
        }

        //other staff for this particular class
}

Реализация Save () должна быть явной, чтобы клиенты не вызывали ее.

Почему вы не используете внутренние классы для контроля доступности ваших методов?

Пример:

Ваша основная сборка

public abstract class Item
{
    public int ID { get; set; }
    protected abstract void Save();

    public class ItemCollection : List<Item>
    {
        public void Save()
        {
            foreach (Item item in this) item.Save();
        }
    }
}

Ваша вторичная сборка

public sealed class NiceItem : Item
{
    protected override void Save()
    {
        // do something
    }
}

Этот шаблон по-прежнему позволит вам реализовать метод Save() в других сборках, но только ItemCollection, который является внутренним классом Item, может вызывать его. Гениально, не правда ли?

Сделайте другой интерфейс, который является внутренним, и используйте явную реализацию для метода.

internal interface InternalIAM
{
    void Save();
}

public class concreteIAM : InternalIAM
{
    void InternalIAM.Save()
    {
    }
}

Я думаю, что лучше всего было бы разделить внутренние и общедоступные члены на два отдельных интерфейса. Если вы наследуете интерфейсы, вы все равно можете объявлять члены публично, но видимость внутренних членов будет определяться видимостью самого интерфейса.

using System;

public interface IPublic
{
    void Public();
}

internal interface IInternal : IPublic
{
    void Internal();
}

public class Concrete : IInternal
{
    public void Internal() { }

    public void Public() { }
}

Мне было интересно здесь по той же проблеме, и наткнулась на этот вопрос ...

Когда я подумал об этом, я понял, что мне вообще не нужен метод внутренний в интерфейсе.

Я могу получить к нему доступ через свой конкретный класс, и оставьте Контракт на Внешний код.

В вашем примере:

    public interface IAM
    {
            int ID { get; set; }
    }

    public class concreteIAM : IAM
    {
             public int ID{get;set;}
             internal void Save(){
             //save the object
             }

            //other staff for this particular class
    }

    public class MyList : List<IAM>
    {
            public void Save()
            {
                    foreach (concreteIAM iam in this)
                    {
                            iam.Save();
                    }
            }
            //other staff for this particular class
    }

Об этом я и говорю в своей статье Друзья и участники внутреннего интерфейса бесплатно с кодированием интерфейсов.

Суть из статьи

public class Internal
{
    internal Internal() { }
}

public interface IAM
{
    int ID { get; set; }
    void Save(Internal access);
}

С этого момента только ваша сборка может вызывать метод Save(), поскольку экземпляр класса Internal может быть создан только вашей сборкой.

У меня была похожая ситуация, и я подумал, что это может помочь. (не уверен, не нужен ли это сейчас или нет)

Для меня это законный случай: предположим, что есть интерфейс, который имеет некоторый API, который является внутренним по отношению к DLL, и к некоторому API можно получить доступ извне DLL. Поскольку интерфейс является абстрактным классом, вместо определения интерфейса вы можете определить его как абстрактный класс.

using System.Collections.Generic;

public abstract class IAM
{
    int ID { get; set; }
    internal abstract void Save();
}

public class concreteIAM : IAM
{
    public int ID { get; set; }
    internal override void Save()
    {
        //save the object
    }

    //other staff for this particular class
}

public class MyList : List<IAM>
{
     internal void Save()
    {
        foreach (IAM iam in this)
        {
            iam.Save();
        }
    }

    //other staff for this particular class
}