Czym różnią się abstrakcja i hermetyzacja?

Enkapsulacja : ukrywanie danych za pomocą getterów i setterów itp.

Abstraction: ukrywanie implementacji przy użyciu klas abstrakcyjnych i interfejsów itp.

_{Źródło obrazu}

Abstrakcja: jest nakreślona przez lewy górny i prawy górny obraz kota. Chirurg i starsza pani zaprojektowali (lub wizualizowali) zwierzę inaczej. W ten sam sposób można umieścić różne funkcje w klasie Cat, w zależności od potrzeb aplikacji. Każdy kot ma wątrobę, pęcherz, serce i płuca, ale jeśli chcesz, aby twój kot tylko "mruczał", będziesz streszczenie kota aplikacji do projektu na górze-lewo, a nie na górze-prawo.

Enkapsulacja: jest nakreślona przez kota stojącego na stole. To jest to, co każdy poza kotem powinien widzieć kota jako. Nie muszą się martwić, czy rzeczywistą implementacją kota jest góra-lewo, góra-prawo, czy nawet kombinacja obu.

_{PS: Idź tutaj na to samo pytanie, aby usłyszeć pełną historię.}

Postaram się w prosty sposób zademonstrować enkapsulację i abstrakcję.. Zobaczmy..

• owijanie danych i funkcji w jedną jednostkę (zwaną klasa) jest znany jako enkapsulacji. Enkapsulacja zawierająca i ukrywająca informacje o obiekcie, takie jak wewnętrzne struktury danych i kod.

Enkapsulacja jest -

• Ukrywanie Złożoności,
• powiązanie danych i funkcji razem,
• tworzenie skomplikowanych metod Prywatne,
• Tworzenie prywatnej zmiennej instancji,
• ukrywanie niepotrzebnych danych i funkcji przed Użytkownikiem końcowym.

Enkapsulacja implementuje abstrakcję.

A abstrakcja to -

• Pokazanie, Co Jest Konieczne,
• Dane muszą być abstrakcyjne od Użytkownika Końcowego,

Zobaczmy przykład -

Poniższy obraz pokazuje GUI "dane Klienta do dodania do bazy danych".

Patrząc na obraz możemy powiedzieć że potrzebujemy klasy klienta.

Krok 1: czego potrzebuje Moja klasa klienta?

Tzn.

• 2 zmienne do przechowywania kodu klienta i nazwy klienta.

• 1 Funkcja dodawania kodu klienta i nazwy klienta do bazy danych.

  namespace CustomerContent
    {
       public class Customer
       {
           public string CustomerCode = "";
           public string CustomerName = "";
           public void ADD()
           {
              //my DB code will go here
           }

Teraz tylko Dodaj metodę nie działa tutaj sam.

Krok -2: jak działa Walidacja, funkcja dodawania działa?

Będziemy potrzebować bazy danych Kod połączenia i Kod weryfikacyjny (dodatkowe metody).

     public bool Validate()
     {
    //Granular Customer Code and Name
    return true;
     }

     public bool CreateDBObject()
     {
    //DB Connection Code
    return true;
     }


class Program
{
   static void main(String[] args)
   {
     CustomerComponent.Customer obj = new CustomerComponent.Customer;

     obj.CustomerCode = "s001";
     obj.CustomerName = "Mac";

     obj.Validate();
     obj.CreateDBObject();

     obj.ADD();
    }
}

Teraz nie ma potrzeby pokazywania dodatkowych metod(Validate(); CreateDBObject() [skomplikowana i dodatkowa metoda]) do Użytkownika Końcowego.Użytkownik końcowy musi tylko zobaczyć i wiedzieć o kodzie klienta, nazwie klienta i przycisku Dodaj, który doda rekord.. Użytkownik końcowy nie dba o to, jak doda dane do bazy danych?.

Krok -3: prywatne dodatkowe i skomplikowane metody, które nie wymagają interakcji użytkownika końcowego.

Więc uczynienie tych skomplikowanych i dodatkowych metod prywatnych zamiast publicznych (tzn. ukrywanie tych metod) i usunięcie obj.Validate(); obj.CreateDBObject(); z głównego programu klasowego osiągamy enkapsulację.

Innymi słowy uproszczenie interfejsu dla użytkownika końcowego to enkapsulacja.

Więc teraz cały kod wygląda jak poniżej -

 namespace CustomerContent
 {
     public class Customer
     {
        public string CustomerCode = "";
        public string CustomerName = "";

        public void ADD()
        {
           //my DB code will go here
        }

        private bool Validate()
        {
           //Granular Customer Code and Name
           return true;
        }

        private bool CreateDBObject()
        {
           //DB Connection Code
           return true;
        }


  class Program
  {
     static void main(String[] args)
     {
        CustomerComponent.Customer obj = new CustomerComponent.Customer;

        obj.CustomerCode = "s001";

        obj.CustomerName = "Mac";

        obj.ADD();
   }
}

Podsumowanie:

Krok -1 : czego potrzebuje Moja klasa klienta? jest abstrakcją .

Krok -3: Krok -3: Prywatny dodatkowe i skomplikowane metody, które nie wymagają interakcji użytkownika końcowego, to enkapsulacja .

P. S.-powyższy kod jest twardy i szybki.

UPDATE: Pod tym linkiem znajduje się film wyjaśniający próbkę: Jaka jest różnica między abstrakcją a enkapsulacją

Poniżej znajduje się kurs semestralny w kilku akapitach.

Analiza i projektowanie obiektowe (OOAD) opiera się nie tylko na dwóch, ale i czterech zasadach. Są:

• Abstrakcja: oznacza, że włączasz tylko te cechy podmiotu, które są wymagane w Twojej aplikacji. Jeśli więc każde konto bankowe ma datę otwarcia, ale aplikacja nie musi znać daty otwarcia konta, po prostu nie dodajesz pole OpeningDate w Twoim obiektowym projekcie (klasy BankAccount). ^†abstrakcja W OOAD nie ma nic wspólnego z klasami abstrakcyjnymi w OOP.

  Zgodnie z zasadą abstrakcji, Twoje byty są abstrakcją tego, czym są w świecie rzeczywistym. W ten sposób zaprojektujesz abstrakcję rachunku bankowego tylko do tego poziomu szczegółowości, który jest potrzebny Twojej aplikacji.

• Dziedziczenie: jest bardziej kodowanie-sztuczka niż rzeczywista zasada. To oszczędza od ponownego pisania tych funkcjonalności, które zostały napisane gdzie indziej. Jednak myślenie jest takie, że musi istnieć związek między nowym kodem, który piszesz, a starym kodem, który chcesz ponownie wykorzystać. W przeciwnym razie nikt nie zabrania ci pisać klasy zwierząt , która jest dziedziczona z BankAccount , nawet jeśli jest całkowicie bezsensowna.

  Tak jak możesz odziedziczyć majątek swoich rodziców, możesz odziedziczyć pola i metody z klasy rodzica. Więc, biorąc wszystko, co ma Klasa rodzica, a następnie dodając coś więcej, jeśli zajdzie taka potrzeba, jest dziedziczeniem. Nie szukaj dziedziczenia w projekcie zorientowanym obiektowo. Dziedziczenie naturalnie się pojawi.

• Polimorfizm: jest konsekwencją dziedziczenia. Dziedziczenie metody od rodzica jest użyteczne, ale możliwość modyfikacji metody, jeśli sytuacja tego wymaga, jest polimorfizmem. Możesz zaimplementować metodę w podklasa z dokładnie tym samym podpisem jak w klasie rodzica, tak że po wywołaniu wywołana jest metoda z klasy potomnej. Jest to zasada polimorfizmu.

• Enkapsulacja: oznacza łączenie powiązanych funkcji razem i zapewnienie dostępu do tylko potrzeb. Enkapsulacja jest podstawą projektowania klas w projektowaniu obiektowym, przez:

  • łączenie powiązanych danych i metod; oraz,
  • ujawnianie tylko fragmentów danych i metod istotnych dla funkcjonowania z podmiotami zewnętrznymi.

Kolejną uproszczoną odpowiedzią jest tutaj .

^{† ludzie, którzy twierdzą, że "abstrakcja OOAD skutkuje abstrakcyjnym słowem kluczowym OOP"...To jest niepoprawne.}

^{przykład: projektując uczelnię w aplikacji z wykorzystaniem zasad zorientowanych obiektowo, wystarczy Zaprojektuj "abstrakcję" Uniwersytetu. Nawet jeśli w prawie każdej uczelni jest zwykle jeden Bankomat do wydawania gotówki, możesz nie uwzględnić tego faktu, jeśli nie jest on potrzebny do aplikacji. I chociaż zaprojektowałeś tylko abstrakcję Uniwersytetu, nie musisz umieszczać abstraktu w deklaracji klasowej. Twój abstrakcyjny projekt Uniwersytetu będzie normalną klasą w Twojej aplikacji.}

Myślę, że są to nieco różne pojęcia, ale często są stosowane razem. Enkapsulacja jest techniką ukrywania szczegółów implementacji przed rozmówcą, podczas gdy abstrakcja jest bardziej filozofią projektowania obejmującą tworzenie obiektów, które są analogiczne do znanych obiektów/procesów, aby pomóc zrozumieć. Enkapsulacja jest tylko jedną z wielu technik, które można wykorzystać do stworzenia abstrakcji.

Na przykład, weźmy "windows". Nie są to tak naprawdę okna w tradycyjnym znaczeniu, są to tylko graficzne kwadraty na ekranie. Ale warto myśleć o nich jak o oknach. To abstrakcja.

Jeśli "windows API" ukrywa szczegóły dotyczące fizycznego renderowania tekstu lub grafiki w granicach okna, jest to enkapsulacja.

My 2C

Celem enkapsulacji jest ukrycie szczegółów implementacji przed użytkownikiem twojej klasy, np. jeśli wewnętrznie zachowasz std:: list of items w swojej klasie, a następnie zdecydujesz, że std:: vector będzie bardziej efektywny, możesz to zmienić bez opieki użytkownika. To powiedziawszy, sposób interakcji z kontenerem stl polega na abstrakcji, zarówno lista, jak i Wektor mogą być na przykład przemierzane w ten sam sposób przy użyciu podobnych metod (iteratorów).

Jeden przykład zawsze był przywoływany mi w kontekście abstrakcji; automatyczna vs. ręczna skrzynia biegów w samochodach. Ręczna skrzynia biegów ukrywa niektóre czynności zmiany biegów, ale nadal trzeba sprzęgła i zmiany jako kierowca. Automatyczna skrzynia biegów zawiera wszystkie szczegóły zmiany biegów, tzn. ukrywa ją przed tobą, a zatem jest to wyższa abstrakcja procesu zmiany biegów.

Enkapsulacja: ukrywanie szczegółów implementacji (Uwaga: Dane i / lub metody) w taki sposób, że tylko to, co jest sensownie czytelne/zapisywalne/użyteczne przez zewnętrzne, jest dla nich dostępne, Wszystko inne jest bezpośrednio "nietykalne".

Abstrakcja: czasami odnosi się to konkretnie do typu, którego nie można utworzyć instancji i który zapewnia szablon dla innych typów, które mogą być, zwykle poprzez podklasowanie. Ogólniej "abstrakcja" odnosi się do tworzenia/posiadania czegoś mniej szczegółowego, mniej szczegółowego, mniej ziarniste.

Istnieje pewne podobieństwo, nakładanie się pojęć, ale najlepszym sposobem na zapamiętanie tego jest tak: enkapsulacja polega bardziej na ukrywaniu szczegółów, podczas gdy abstrakcja jest bardziej o uogólnianiu szczegółów.

Abstrakcja i hermetyzacja są pojęciami mylącymi i zależnymi od siebie. Weźmy to na przykład:

public class Person
    {
        private int Id { get; set; }
        private string Name { get; set; }
        private string CustomName()
        {
            return "Name:- " + Name + " and Id is:- " + Id;
        }
    }

Kiedy tworzyłeś klasę Person, enkapsulowałeś, zapisując właściwości i funkcje razem(Id, Name, CustomName). Wykonujesz abstrakcję, gdy wystawiasz tę klasę Klientowi jako

Person p = new Person();
p.CustomName();

Twój Klient nie wie nic o identyfikatorze i nazwie w tej funkcji. Teraz, jeśli twój klient chce znać nazwisko, a także bez zakłócania funkcji sprawdzam. Robisz enkapsulację dodając jeszcze jedną właściwość do klasy Person, takiej jak ta.

public class Person
        {
            private int Id { get; set; }
            private string Name { get; set; }
            private string LastName {get; set;}
            public string CustomName()
            {
                return "Name:- " + Name + " and Id is:- " + Id + "last name:- " + LastName;
            }
        }

Jak wiem, enkapsulacja polega na ukrywaniu danych klas w sobie i udostępnianiu ich tylko poprzez settery / gettery, jeśli muszą być dostępne ze świata zewnętrznego.

Abstrakcja jest projektem klasy dla siebie.

Oznacza, jak tworzysz drzewo klas, które metody są ogólne, które są dziedziczone, które mogą być nadpisywane, które atrybuty są tylko na poziomie prywatnym lub chronionym, jak budujesz drzewo dziedziczenia klas, czy używasz klas końcowych, klasy abtract, interfejs-implementacja.

Abstrakcja jest bardziej umieszczona w fazie projektowania oo, podczas gdy enkapsulacja zapisuje się również do fazy developmnent.

Myślę o tym w ten sposób, enkapsulacja ukrywa sposób, w jaki coś się robi. Może to być jedno lub wiele działań.

Abstrakcja jest związana z "Dlaczego" ja ją zamykam na pierwszym miejscu.

W zasadzie mówię Klientowi " nie musisz dużo wiedzieć o tym, jak przetwarzam płatność i obliczam wysyłkę itp. Chcę tylko, żebyś mi powiedział, że chcesz "Checkout", a ja zajmę się szczegółami za Ciebie."

W ten sposób zamknąłem szczegóły przez uogólnienie (abstrakcja) do żądania kasy.

Naprawdę myślę, że abstrakcja I enkapsulacja idą w parze.

Abstrakcja

W Javie abstrakcja oznacza ukrywanie informacji przed światem rzeczywistym. Ustanawia umowę między stroną, aby powiedzieć o "co powinniśmy zrobić, aby skorzystać z usługi".

Przykład, w rozwoju API, tylko abstrakcyjne informacje o usłudze zostały ujawnione światu, a nie rzeczywistą implementację. Interfejs w Javie może bardzo pomóc w realizacji tej koncepcji.

Interfejs zapewnia umowę między stronami, przykład, producent i konsument. Producent produkuje towary bez informowania konsumenta, w jaki sposób produkt jest wytwarzany. Ale za pośrednictwem interfejsu producent informuje wszystkich konsumentów, jaki produkt można kupić. Za pomocą abstrakcji producent może sprzedawać produkt swoim konsumentom.

Enkapsulacja:

Enkapsulacja jest o jeden poziom niżej od abstrakcji. Ta sama firma produktowa stara się chronić informacje od siebie nawzajem. Na przykład, jeśli firma produkuje wino i czekoladę, hermetyzacja pomaga ekranowanie informacji o tym, jak każdy produkt jest wytwarzany od siebie.

1. Jeśli mam indywidualny pakiet jeden na wino, a drugi na czekolady, a jeśli wszystkie klasy są zadeklarowane w pakiecie jako domyślny modyfikator dostępu, podajemy enkapsulację na poziomie pakietu dla wszystkich klas.
2. w pakiecie, jeśli zadeklarujemy każdą klasę złożoną (pole member) jako prywatne i posiadające publiczną metodę dostępu do tych pól, w ten sposób nadając klasie poziom enkapsulacji tym pola