Почему бы не использовать публичные функции-члены

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

Например, если мой класс Math с публичной функцией sum(int, int b), то клиенту будет доступна только часть интерфейса/декларации, а не реализация.

public class Math
{
      public int sum(int, int b)
      {
               //Implementation
      }
}


public class Client
{
         Math objMath = new Math();
         objMath.Sum(4,10);//It will not display implementation inside sum than why to avoid
}

class c# public
person funsukvangdu    schedule 19.09.2011    source источник
comment
Плохой пример. Math может/должно быть static   -  person Henk Holterman    schedule 19.09.2011
comment
В дополнение к отличным ответам здесь, поищите слабую связь в Википедии и в других местах. Это одно из основных преимуществ ОО.   -  person Miserable Variable    schedule 19.09.2011
comment
@Henk, тогда как я могу расширить его, чтобы обеспечить более быструю реализацию добавления 4 и 10? :)   -  person Miserable Variable    schedule 19.09.2011

Ответы (3)


arrow_upward
8
arrow_downward

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

Чтобы привести конкретный пример, я работаю над проектом с открытым исходным кодом под названием Noda Time. По общему признанию, у нас еще не было нашего первого общедоступного релиза, но недавно я внес множество изменений в различные внутренние типы, включая довольно значительное изменение иерархии типов и даже удаление методов. Если бы это были общедоступные типы или общедоступные методы (и если бы мы уже перешли к версии 1.0), то мы могли бы сломать код, зависящий от этой конкретной реализации.

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

Очевидно, что некоторые вещи должны быть раскрыты — по крайней мере, в библиотеках классов, — но вы должны быть осторожны с тем, насколько вы раскрываете, если только вы не хотите позже сломать все вызывающие объекты (или жить с каждым решением, которое вы принимаете). делать, навсегда).

person Jon Skeet    schedule 19.09.2011

arrow_upward
2
arrow_downward

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

person Puppy    schedule 19.09.2011

arrow_upward
2
arrow_downward

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

person Andrey    schedule 19.09.2011