Если опосредованный доступ считать за accecc, то тогда смысла в определении нет, так как поля без опосредованного доступа бессмысленны.
Сеттер и геттер != поле, они не позволяют достучаться до поля а только опосредованно сообщить ему значение. Unauthorized users не юзают поле, а юзают сеттер и геттер, последние, в свою очередь, юзают поле. Если бы parties юзали поле, они бы ломались от подмены реализации.
>>>ок. Я некорректно выразился. Прямо или косвенно — это не играет роли
Если речь идет не о инкапсуляции, то не играет, иначе играет.
>>>Сложно сказать. Это очень гипотетический случай. На практике не бывает, чтобы значения могли быть любыми. Вероятнее всего(но не обязательно) в этом случае поле по смыслу к классу просто не относится, тогда это тоже нарушение инкапсуляции.
На практике редко контролируют 100%.
Например name — это любая строка вполне может быть.
Программа — это модель, а в модели не всегда учитывают все условия.
Плохо то, что туда можно подсунуть что-нибудь, что именем не является, а Person будет думать, что это имя.
А как написать такую реализацию, чтобы она получала имена и ничего, кроме них?
Если этот код уйдет в продакшн — то уже будет поздно.
Всегда можно сделать хотфикс, к тому же сейчас очень популярна сервисная модель. Например стартапу может не хватить времени честно написать все сеттеры с проверкой по справочнику имен и он может в бета версии этого не делать, а потом легко изменить реализацию.
In general, encapsulation is one of the 4 fundamentals of OOP (object-oriented programming). Encapsulation is to hide the variables or something inside a class, preventing unauthorized parties to use. So the public methods like getter and setter access it and the other classes call these methods for accessing.
А если поле — какая-то совсем отдельная сущность, которая никак внутри ничего не может испортить, значит эта сущность по смыслу не относится к классу, то есть это опять же нарушение инкапсуляции.
То есть если все значения поля допустимы, то это обязательно отдельная сущность?
Почему порча является определяющим признаком принадлежности к классу?
Ага. То есть если я прокеширую name в Person инкапсуляция вдруг пропадет, а если перестану кешировать, то появится?
Мне кажется, вы делаете логическую ошибку.
Name getName()
{
return name;
}
здесь есть скрытие реализации — так как пользователь не знает возвращение это просто поля или еще что-то.
здесь есть bundle — объединение данных и кода.
процитируйте, пожалуйста определение послностью — а то вы говорите, про связанность а цитируете про сокрытие.
>>>Если атрибут не связан с внутренней реализацией, значит класс объединяет в себе левую сущность, то есть нарушена инкапсуляция опять же по определению
Как это нарушает инкапсуляцию?
Name getName()
{
nameHistory.GetByDate(CurrentDate());
}
>>>Тут вопрос скорее идеологический: новый метод логически не принадлежит классу, соответсвенно по правилам ООП (да и вообще хорошей декомпозиции) метод не следует включать в этот класс.
С одной стороны принадлежит (это то, что можно сделать со строкой — превратить в строку), с другой стороны не принадлежит (описывает только некоторый аспект). Вот смолточники выбирают добавить в строку.
>>>Смотря какой. Обычно 12-20 байт. Вам кажется это мало? Почитайте выше, я там описывал явление высокой детской смертности.
Никто не мешает создавать поменьше реквестов. К тому же посмотрите на любой современный язык — там сборка мусора, а в хаскеле к тому же ленивость. С другой стороны, к ващшим услугам C++ и object pascal без GC.
>>>Стек — это тоже память.
>>>Ок, куча. Стек автоматически зачищает память. Это не стоит нисколько. А вот объекты в памяти уже нужно как-то убирать.
Стек не автоматически убирает мусор. Он только убирает то, что в области видимости и только с того момента как эта видимость пропадает. То есть, например.
BigSTructure structure;
very_long_function(structure)
void very_long_function(BigSTructure &s)
{
send_structure(s);
// начиная отсюда s - мусор потому, точ не используется
long_running_code();
}
structure будет висеть пока не закончится very_long_function();
Сеттер и геттер != поле, они не позволяют достучаться до поля а только опосредованно сообщить ему значение. Unauthorized users не юзают поле, а юзают сеттер и геттер, последние, в свою очередь, юзают поле. Если бы parties юзали поле, они бы ломались от подмены реализации.
А зачем это надо?
Это ваше определение, определение из википедии я приводил.
Это определение скорее относится к defensive программированию.
Так и есть. И инкапсуляция не всегда соблюдается по этой же причине.
Однако простой сеттер или простой геттер не является нарушением инкапсуляции.
2. Констрактом setName может быть что в случае ввода не имени результат неопределен.
Если речь идет не о инкапсуляции, то не играет, иначе играет.
>>>Сложно сказать. Это очень гипотетический случай. На практике не бывает, чтобы значения могли быть любыми. Вероятнее всего(но не обязательно) в этом случае поле по смыслу к классу просто не относится, тогда это тоже нарушение инкапсуляции.
На практике редко контролируют 100%.
Например name — это любая строка вполне может быть.
Программа — это модель, а в модели не всегда учитывают все условия.
А как написать такую реализацию, чтобы она получала имена и ничего, кроме них?
Если этот код уйдет в продакшн — то уже будет поздно.
Всегда можно сделать хотфикс, к тому же сейчас очень популярна сервисная модель. Например стартапу может не хватить времени честно написать все сеттеры с проверкой по справочнику имен и он может в бета версии этого не делать, а потом легко изменить реализацию.
In general, encapsulation is one of the 4 fundamentals of OOP (object-oriented programming). Encapsulation is to hide the variables or something inside a class, preventing unauthorized parties to use. So the public methods like getter and setter access it and the other classes call these methods for accessing.
Через сеттер, это не напрямую.
При этом, для того, чтобы что-то испортить внутри класса, пользователю совершенно не обязательно знать, как реализован этот сеттер
То есть если допустимы любые значения поля, то нарушения инкапсуляции нет?
То есть если все значения поля допустимы, то это обязательно отдельная сущность?
Почему порча является определяющим признаком принадлежности к классу?
Мне кажется, вы делаете логическую ошибку.
здесь есть скрытие реализации — так как пользователь не знает возвращение это просто поля или еще что-то.
здесь есть bundle — объединение данных и кода.
Какой букве определения это противоречит?
А если подразумевает удаление поля, но не подразумевает удаление свойства?
>>>Если атрибут не связан с внутренней реализацией, значит класс объединяет в себе левую сущность, то есть нарушена инкапсуляция опять же по определению
Как это нарушает инкапсуляцию?
Ваше решение проблемы?
С одной стороны принадлежит (это то, что можно сделать со строкой — превратить в строку), с другой стороны не принадлежит (описывает только некоторый аспект). Вот смолточники выбирают добавить в строку.
>>> Боюсь неправильно понять. Можно пример?
msdn.microsoft.com/en-us/library/bb397696.aspx
только в C# нельзя
>>>Смотря какой. Обычно 12-20 байт. Вам кажется это мало? Почитайте выше, я там описывал явление высокой детской смертности.
Никто не мешает создавать поменьше реквестов. К тому же посмотрите на любой современный язык — там сборка мусора, а в хаскеле к тому же ленивость. С другой стороны, к ващшим услугам C++ и object pascal без GC.
>>>Стек — это тоже память.
>>>Ок, куча. Стек автоматически зачищает память. Это не стоит нисколько. А вот объекты в памяти уже нужно как-то убирать.
Стек не автоматически убирает мусор. Он только убирает то, что в области видимости и только с того момента как эта видимость пропадает. То есть, например.
structure будет висеть пока не закончится very_long_function();
2. хотелось бы посмотреть на реализацию функции show