Algorytmy opisują, co powinien zrobić komputer. Struktura opisuje sposób rozmieszczenia algorytmu [w kodzie źródłowym]. OOP to styl programowania, który wykorzystuje pewne struktury „obiektowe”.
Książki o algorytmach często unikają OOP, ponieważ koncentrują się na algorytmie, a nie na strukturze. Fragmenty kodu, które w dużym stopniu opierają się na strukturze, są raczej złymi przykładami do umieszczenia w książce algorytmów. Podobnie książki OOP często unikają algorytmów, ponieważ zaśmiecają historię. Zaletą OOP jest jego płynność, a powiązanie go z algorytmem sprawia, że wydaje się on sztywniejszy. Chodzi bardziej o temat książki niż o cokolwiek innego.
W prawdziwym kodzie będziesz używać obu stron obok siebie. Z definicji nie można rozwiązać problemów z komputerem bez algorytmów i trudno będzie napisać dobre algorytmy bez struktury (OOP lub w inny sposób).
Jako przykład tego, gdzie się rozmazują, weź Programowanie dynamiczne. W książce algorytmów opisałbyś, jak wziąć jednorodny zestaw danych do tablicy i użyć programowania dynamicznego, aby znaleźć rozwiązanie. W książce OOP możesz natknąć się na strukturę taką jak Visitor, która jest sposobem na wykonywanie dowolnych algorytmów na zbiorze heterogenicznych obiektów. Przykład książki DP można uznać za bardzo prostego gościa działającego na obiektach w ogólnie oddolnej kolejności. Wzorzec gościa można uznać za szkielet problemu DP, ale brakuje mu mięsa i ziemniaków. W rzeczywistości często okazuje się, że często potrzebujesz obu razem: używasz wzorca gościa, aby radzić sobie z heterogenicznością w zestawie danych (DP jest w tym zły), i używasz DP w strukturze gościa, aby zorganizować algorytm w celu zminimalizowania czasu działania (odwiedzający nie robi
Widzimy także algorytmy działające ponad wzorami projektowymi. Przykłady trudniejsze do sformułowania na małej przestrzeni, ale kiedy już masz strukturę, zaczynasz chcieć manipulować tą strukturą i używasz do tego algorytmów.
Czy są jakieś problemy, które OOP może przedstawić i rozwiązać?
To trudniejsze pytanie, niż ci się wydaje. W pierwszym rzędzie nie ma żadnego obliczeniowego powodu, dla którego potrzebujesz OOP do rozwiązania jakiegokolwiek problemu. Prostym dowodem jest to, że każdy program OOP jest kompilowany do asemblera, który jest zdecydowanie językiem innym niż OOP.
Jednak w szerszym schemacie rzeczy odpowiedź zaczyna być nieśmiała w kierunku „tak”. Rzadko jesteś ograniczony po prostu metodami obliczeniowymi. Przez większość czasu na takie równanie wpływają potrzeby biznesowe i umiejętności programistyczne. Wiele aplikacji dzisiaj nie mogłoby być napisanych bez OOP, nie dlatego, że OOP jest w jakiś sposób fundamentalny dla zadania, ale dlatego, że struktura dostarczona przez OOP była niezbędna do utrzymania projektu na właściwym poziomie i budżetu.
Nie oznacza to, że nigdy nie porzucimy OOP w przyszłości z powodu jakiejś śmiesznej nowej struktury. Mówi jedynie, że jest to jedno z najskuteczniejszych narzędzi w naszym zestawie narzędzi dla zaskakująco dużej części zadań programistycznych. Przyszłe problemy mogą skłonić nas do podejścia do rozwoju przy użyciu różnych struktur. Po pierwsze, oczekuję, że sieci neuronowe będą wymagały zupełnie innego podejścia programistycznego, które może, ale nie musi, być „obiektowe”.
Nie widzę, aby OOP znikało w najbliższej przyszłości ze względu na sposób myślenia projektantów algorytmów. Do tej pory zwykłym wzorem jest to, że ktoś projektuje algorytm, który nie wykorzystuje OOP. Społeczność OOP zdaje sobie sprawę, że algorytm tak naprawdę nie pasuje do struktury OOP i naprawdę nie musi tego robić, więc zawijają cały algorytm w strukturę OOP i zaczynają go używać. Zastanów się boost::shared_ptr. Algorytmy zliczania referencji, które znajdują shared_ptrsię w środku, nie są zbyt przyjazne dla OOP. Jednak wzorzec ten nie stał się popularny, dopóki nie shared_ptrutworzono wokół niego opakowania OOP, które ujawniło możliwości algorytmów w formacie strukturalnym OOP. Teraz jest tak popularny, że stał się najnowszą specyfikacją dla C ++, C ++ 11.
Dlaczego to tak udane? Algorytmy świetnie sprawdzają się w rozwiązywaniu problemów, ale często wymagają znacznych inwestycji początkowych w badania, aby zrozumieć, jak z nich korzystać. Rozwój zorientowany obiektowo jest bardzo skuteczny w pakowaniu takich algorytmów i zapewnianiu interfejsu, który wymaga mniejszej inwestycji początkowej.