Скрытие методов из других классов при наследовании от класса и интерфейса или абстрактного класса

Question

Чтобы улучшить дальнейшую реализацию и предложить некоторые рекомендации и сохранить все как можно более универсальным в рамках проекта, я создал интерфейс с несколькими методами, которые должны быть используемый. Однако только один метод этого класса должен быть видимым пользователю, вызывающему этот класс, поэтому я хотел бы, чтобы они были защищены. Например

public class ClassThree 
{ 
    public ClassThree() 
    { 
     var classOne = new ClassOne(); 
     class1.MethodOne(); 
    } 
} 

Это, несмотря на ClassOne, имеющий 4 метода, 3 методы используются только в пределах одного общественного класса, следовательно, частный или защищенный. Эти 3 метода необходимы, чтобы 4-й метод работал, однако (в идеальном мире другие разработчики будут следовать тому же принципу). Так что я не хочу, чтобы увидеть следующее всплывающее на IntelliSense:

class1.MethodTwo(); 
class1.MethodThree(); 
class1.MethodFour(); 

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

IInterface.MethodTwo<Type,Type>(string name) 
{ 
    //Do stuff here 
} 

Однако я хотел бы, чтобы предотвратить все отливку вызывая указанные методы в самой ClassOne, так как это просто шип в моем глазу. Мне нравится мой код в чистоте, и это не совсем для меня. Я думал об абстрактном классе, но мой класс наследуется от другого класса. С интерфейсом я мог бы просто сделать

public ClassOne : ClassTwo, IInterface<Type1,Type2> 

Когда я делаю это с абстрактным классом, однако Visual Studio говорит, что интерфейс ожидается. Любые идеи наиболее приветствуются и оцениваются, поскольку я хотел бы улучшить свой код, сделав мою жизнь и работу других разработчиков, которые должны использовать мой код, проще.

Заранее благодарен!

Редактировать: В сценарии может быть несколько классов, таких как ClassOne, которые по существу делают то же самое, но используют разные типы, поскольку объекты, которые они должны возвращать, имеют разные значения. Однако накопление этих объектов являются более или менее то же самое например:

1. собрать все данные API
2. Получить список для экспорта в API и называют # 3 или # 4 в зависимости от типа.
3. Экспорт Тип 1 в API
4. Export Type 2 к API

Идея всегда одинакова, но, естественно, разные API, потребуются различные переменные. Но для обеспечения выполнения всех шагов по-прежнему я хотел бы реализовать интерфейс или что-то еще, но шаги 1,2 и 3 должны быть частными или защищенными, и только класс 2 должен быть доступен классу, который его использовал. Однако, если я только положу метод 2 в интерфейсе, я никогда не буду уверен, что другие будут реализовывать 1,3 & 4. И вот какая цель здесь: P. Это, в то время как ClassOne также наследуется от другого класса, а не только от интерфейса.

Редактировать 2: Я знаю, что интерфейсы предоставляют только общедоступные методы, поэтому я ищу альтернативы, следовательно, этот вопрос. Я знаю, что с этим не так. Я просто не вижу, как я могу это сделать так, как хотелось бы. Спасибо за ответы!

Редактировать 3: Интерфейс в настоящее время выглядит так, я просто скорректировал имена переменных для примера.

public interface IExport<in T, in TU> 
    { 
     void GetRequiredApiData(); 

     bool MethodOne(List<Type> list); 

     bool ExportOne(T one); 

     bool ExportTwo(TU two); 

     bool ValidateExport(); 
    } 

Answer 1

Остальные три метод должен просто назвать внутри общедоступный метод, или сделать свой первый метод частным/защищенным и называют все 4 внутри один публичный метод.

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

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