Добрый день. Изучая сейчас учебник по формальной логике, начинаю приходить к пониманию (а может просто подгоняю,то что читаю, под то что уже знаю), что ООП если и не построен на логике Аристотеля с его классами и типами, то уж очень похож на это. Из хороших книжек по ОО Проектированию, из того что нашел я, есть только Буч. Но и он не о том. Он о том, как проектировать программы с применением ООП методологии, а я хочу побольше углубиться именно в те концепции, на которых ООП построен. Есть ли книги которые раскрывают эту тему? Английский или перевод, не важно. Следует так же уточнить, что читаю книгу именно по логике и ее связи с языком, то есть скажем так "традиционной логике", я еще не очень силен в терминологии. Или стоит почитать все же про символическую aka математическую логику?
ООП - суть объекты.
Больше ничего про ООП знать не нужно.
И на примере конкретного языка программирования, который вам нужен, можно изучать возможности ООП.
К слову, это не панацея и не решит всех проблем. Это просто инструмент, как и логика. И при неумелом обращении можно только всё запутать, а не сделать проще.
ООП это именно методология проектирования программ. Он был создан и развивается именно для этого - чтобы упростить разработку крупных проектов.
Формальная логика там присутствует потольку поскольку. И никакой дополнительной логики в этом искать не нужно - это будет не практично. Реализация ООП подгоняется и меняется в соответствии с практическими требованиями, а не математикой. Собственно отсюда и идут постоянные споры.
DollyPapper, ну споры о том, что имел ввиду автор, когда он изначально придумал эту концепцию, и во что это вылилось.
Споры о том, что есть ооп, что не ооп, споры насколько это ООП-шно, или не ООПшно.
В основном такие споры затевают начинающие, которые научились писать в ООП, но на этом их опыт остановился. Например человек долго работал только в одном проекте.
Saboteur, а у более опытных такие споры не возникают по причине, не доказуемости впринципе, что там имел ввиду автор, что ООП-шно, а что нет, или по иным причинам?
Ну на самом деле, автор, точнее один из авторов (Алан Кей) изначальной концепции еще жив, и он лично говорит что то ООП, которое есть сейчас это не то, о чем он имел ввиду =). Но он с этим поделать уже ничего не может =)
ООП развивается в разных языках программирования немного по-своему.
Saboteur, ну вот мы и подобрались конкретно к тому, что я имел ввиду. Эта группа лиц и Алан Кей в частности, на основании чего он строил ООП как концепцию? Под этим есть формальная теория какая-то, или это парадигма, скажем так с нуля? Ну для примера, есть регулярки, теория регулярок, это автоматы, то есть фундаментальная база есть у них. А у ООП? И если сейчас ООП развивается, развивается он опираясь на что? На производственные практики, или опять же на какую то научную базу?
Парадигма с нуля.
На самом деле они просто писали реализацию первого ООП языка программирования (вроде LISP).
ООП это не математика. ООП это просто способ инкапсулировать отдельные части программы таким образом, чтобы их можно было разрабатывать независимо друг от друга.
То есть основная задача ООП - это возможность парралельной разработки ПО несколькими программистами, минимизируя конфликты.
Берешь данные, берешь все функции которые работают непосредственно с этими данными, называешь эти функции методами и помещаешь это все в один класс. У класса есть внешние (public) методы, которые могут тебе что-то вернуть, либо ты наоборот можешь что-то отправить в класс. Эти методы и типы данных описываются (тем же UML), чтобы другие программисты могли общаться с твоим классом. И каждый программист может ваять свой класс, чтобы он мог взаимодействовать с другими классами.
Это - основная задача ООП.
Все остальные вещи - типа наследственность, полиморфизм и так далее - желание дальнейшей оптимизации, типа повторное использование кода. Они возникли уже как следствие.
КАЖДЫЙ язык реализует немного свои варианты ООП. Java считается хорошо проработанным в плане того, что программист на джава, скорее всего будет использовать ООП правильнее, чем программист в С++.
Простой
Простой
Простой
