Путаница с пониманием абстракции и инкапсуляции в OOP - PullRequest
0 голосов
/ 19 апреля 2020

Я учился JS и наткнулся на термин OOP. Затем, когда я учился OOP, я обнаружил такие понятия, как абстракция и инкапсуляция. Более того, поскольку я исследовал разницу между ними, в большинстве статей говорится, что как абстракция, так и инкапсуляция связаны со скрытием данных, что меня очень смутило. Тем не менее, я сделал вывод, что инкапсуляция - это когда мы просто помещаем переменные и функции, которые над ними работают, в OBJECT, а абстракция - когда мы используем модификаторы доступа для ограничения доступа к свойствам или функциям объекта. Опять же, инкапсуляция - это когда мы используем капсулоподобный объект и помещаем в него переменные и функции для достижения организации и возможности повторного использования. Но абстракция - это когда мы ограничиваем доступ к переменным и функциям внутри объекта. ЭТО ПРАВДА?

Ответы [ 2 ]

0 голосов
/ 05 мая 2020

OOP - это догма.

Автор этого сайта написал статью об абстракции и почему она не работает: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/

В других слова сотовые телефоны и телефоны локальной сети не основаны на той же жестко закодированной абстракции телефона. Они свободны быть их собственными классами. Барбара Лисков (SOLID) будет утверждать, что каждый из них является подтипом. Я настоятельно не рекомендую связывать ваши руки, создавая такие произвольные иерархические схемы категоризации. Это не так, как настоящие машины. Обратитесь к фундаментальным принципам механического проектирования, которые определяют простоту конструкции, то есть, когда это возможно, меньше компонентов. Отдельный абстрактный класс является пустой тратой времени и распределяет сам дизайн на два модуля.

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

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

0 голосов
/ 19 апреля 2020

Инкапсуляция означает, что вы защищаете свои данные внутри вашего класса (или объекта) для внешнего мира и, как вы говорите, вы получаете доступ к закрытым или защищенным данным через методы (функции) из одного и того же объекта.

Абстракция - это что-то совершенно другое. Давайте возьмем пример. Представьте, что вы хотите использовать ограничения для полей формы. Например, у вас есть поле формы «email», которое может быть не пустым и должно содержать действительный адрес электронной почты.

Таким образом, вы хотите добавить различные виды ограничений к большому количеству полей формы во всем приложении.

Все ограничения должны иметь два метода:

1) метод, который проверяет данные поля формы, если они действительны

2) метод, который выдает сообщение об ошибке, если данные не valid

Теперь, прежде чем писать все эти различные объекты ограничений, вы можете написать один родительский класс ABSTRACT, который включает эти два метода, но без кода:

(я использую PHP)

abstract class Constraint
{
    // Force Extending classes to define this methods

    abstract protected function validate(string $data);
    abstract protected function getErrorMessage();
} 

Вышеуказанный класс является абстрактным и не может использоваться (создаваться) самим собой. Но вы можете написать разные классы ограничений, которые наследуют вышеуказанный класс:

class NotEmptyConstraint extends Constraint
{
    // Mandatory overwritten methods:
    protected function validate(string $data)
    {
        if(strlen($data) > 0 ) {
            return true;
        }

        return false;
    }

    protected function getErrorMessage();
    {
        return 'This is a mandatory field';
    }
} 

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

Надеюсь, это поможет ..

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...