Форум программистов, компьютерный форум, киберфорум
Наши страницы
CoderHuligan
Войти
Регистрация
Восстановить пароль
Рейтинг: 2.33. Голосов: 3.

ООП иль процедурка?

Запись от CoderHuligan размещена 09.12.2018 в 15:18
Обновил(-а) CoderHuligan 10.12.2018 в 19:27

Так, размышления по ходу.
Нахожусь в процессе чтения книжки David West "Object Thinking". Читаю блог Егора Бугаенко и смотрю его лекции. И вот что я думаю обо всём этом деле. Что называется: навеяло. Прав я или не прав не знаю, но выскажу то, что я думаю на данный момент.
Я не спец по языку JAVA, но это не имеет отношения к самой обьектной концепции.
Да, - меня заворожило то о чём вещает апостол Бугаенко. На лицо рождение новой религии, со своей библией - "Object Thinking". Геттеры и сеттеры долой - обьект должен полностью инкапсулировать свои данные, и только тогда он станет полноценным обьектом. Классы делаются настолько маленькими насколько это возможно. Он прав что под названием ООП сейчас используется процедурное программирование с классами. Создателя джавы спросили недавно, что бы он удалил из джавы если бы создавал её/его? с нуля? Он ответил, что избавился бы от классов..
Напомню, что джава это полностью "ооп-язык"..
Видимо потому, что сейчас большинство теоретиков понимает опасность наследования.
Бугаенко вещает, что можно иметь обьекты без классов.
Получается не просто ООП, а "чистый" ООП, ООП "истинной арийской национальности". ООП в кубе..
В теории он прав, это действительно настоящий ООП. Уже существует проект нового чистого обьектного языка. Однако не самообман ли это? Не принятие ли это желаемое за действительное?
Апостол прав в одном: сейчас используется не ООП, а недо-ООП, процедурщина ухудшенная дополнительными уровнями абстракций в виде классов. А всё из-за того, что ООП не понят большинством бывших процедурщиков, которые привнесли своё понимание в эту область.
Итак постулируется что обьект должен быть самостоятельной сущностью. Он не должен показывать внешнему миру свои поля(не должен иметь паблик-полей), и по всей видимости в нем не должно быть никакого наследования(иначе обьект не самостоятельная сущность). Такой обьект по мысли авторов можно легко изьять из системы и заменить новым. Обьект должен только что-то для нас делать, но менять в нём что-то извне нельзя, ибо иначе информация расплывается по коду системы.
Всё бы хорошо, но тут вопрос реализации, да и самой философии обьектов..
А насколько я понял это обычными средствами реализуется через ужасные костыли. Нет, конечно эти костыли можно упрятать глубоко в недрах будущего языка, но от этого они не перестанут быть костылями.
Если обьект без паблик, то нужно плодить кучу маленьких обьектов, которые будет использовать этот обьект. Вопрос: в чём преимущество перед обычными функциями? Уменьшилось количеств именованных сущностей? Нет не уменьшилось, ведь у каждого такого обьекта будет своё имя, как и у функции.
Может быть преимущество в том, что данные и методы лежат вместе, в одном обьекте?
А они вообще-то должны так быть сгруппированы, если мы не имеем геттеров и сеттеров? Ведь это по сути только они напрямую имеют дело с паблик и не паблик полями не преобразовывая данных из одного типа в другой, а просто возвращая или устанавливая всего лишь одно поле.. От геттеров избавились, а с методами как?. А методы преобразуют один тип инфо в другой. А так как обьект это по сути один тип данных(для самого себя), то методы должны преобразовывать данные из одно типа в другой, то есть по сути возвращать разные обьекты-типы.. А если так, то какой смысл их держать в одном обьекте?
Конечно чтобы не дублировать функционал методов придумали различные многочисленные костыли, которые называются разными клёвыми именами: интерфейсы, дружественные классы, статические классы и т.д. А как же с размножением сущностей, которые напрямую никак не соотносятся с решением поставленной задачи? Задача уже как бы и потерялась..
Нам предложено представлять обьект в виде человека, которому можно приказывать или попросить что-либо для нас сделать, и он это должен для нас сделать, но мы не можем заменить что-либо в этом обьекте извне.. Постойте, а как же хирурги? Они меняют. Иногда..
Хорошо примем эту точку. Мы хорошо знаем, что люди делятся по психотипу на разные типы: холерики, сангвиники, совы, и т.п. Этих типов вобщем-то ограниченное количество. А вот сумма знаний и компетенции в той или иной области у всех разная. Поэтому каждый человек уникален, в этом смысле.
Типов поведений несколько, а индивидуальность внешности и суммы знаний у всех уникальные.
Поведение это функционирование этого обьекта. Мы знаем, что поступки и элементарные действия большинства людей типичны, и их можно разложить на составляющие архетипы поведений. Действие определяется внутренним? побуждением к оному.
Короче говоря есть некие общие функциональные особенности обьекта под названием человек. Общие, а не присущие только какому-то уникальному индивиду.
Теперь статические данные.
Физически обьект-человек состоит из статических элементов - клеток, атомов, молекул, кварков, бозонов Хиггса и т.п.
Это те данные, которые собравшись раз вместе и образуют человека-обьекта.
Эти данные тоже типы: клетки это один тип, молекулы другой тип. Причём типы эти статические. Хотя клетка как бы живёт, но это не влияет на её "статическую конституцию".
Итак на лицо две сущности статика и динамика. Обе построены по иерархическому принципу и не зависят друг от друга(ампутированный палец может существовать без функционирования в замороженном виде хоть тысячелетия).
Плоть это данные, а динамика - это функции.
Например в Си есть структуры, которые могут состоять из других структур и т.д, но лучше иметь массив void указателей на разнотипные данные, чтобы не плодить могоуровневые ассоциации. У такого обьекта есть имя, а значит мы имеем чистую абстракцию.
Смотрите: я назвал обьектом просто набор статических данных под одним именем, то есть агрегат из разнородных данных. Он может существовать без функций, его можно хранить, клонировать новые обьекты из уже созданного архетипа и т.д.
Такой набор данных и есть обьект. Без методов. Он просто ЕСТЬ. Но он ещё не живое существо.
Теперь вопрос: а может ли метод или функция работать только с каким-то конкретным обьектом(не архетипом естестенно)? Может, но тогда это уже будет не совсем человек-обьект, а неуправляемая сущность. Тут ещё надо вспомнить про ограниченность типов поведений. Одни и те же функции работают со множеством однотипных обьектов и их, самое главное наследовать не нужно.
Так правильно ли строить программу в терминах обьектов, как это понимается сейчас?
Есть такой язык FORT. Там нет обьектов, однако там есть СЛОВА. Слова это не просто функции. Это существительные, прилагательные и глаголы. Из этих слов можно создавать предметно ориентированные языки, уже на которых и решаются те или иные задачи. Под каждую задачу создаётся свой ЛЕКСИКОН. Это определённая философия и её адепты утверждают, что она гораздо мощнее ООП ибо лексикон создаётся над лексиконом и т.д., а это наращивание уровней абстракций наиболее естественным оразом. Это мощно, очень мощно. И без всяких обьектов. Нечто вроде подхода который предлагал великий Кнут - литературное программирование. Однако у него это несколько иначе реализовывалось насколько я вникал, хотя могу и ошибаться.
Мы же мыслим образами, а они уже приводятся к словесной форме..
Итак мы имеем:
1. форму
2. содержание(функционал системы).

Форма отдельно, содержание отдельно по аналогии с мухами и котлетами. Мухи не живут в котлетах, они их пользуют для собственного удовольствия. Причём одна и та же муха может попользовать дюжину другую котлет..
Агрегат-форма имеет своё состояние!
Заметьте: модуль в Паскале не имеет своего состояния. В правильном ООП обьект имеет своё состояние.
Обычная функция не имеет своего состояния, так как не сохраняет его между вызовами(взял-отдал и точка).
Однако при желании функция может иметь его применив статические переменные. Например си-функция strtok() имеет своё состояние между вызовами.
Состояние агрегата без внутренних методов определяется совокупностью(по ошибке написал совоПУкностью))) его свойств в данный момент времени, или всего одной переменной, которая и определяет его поведение в целом..
Продолжу позже..
Размещено в Без категории
Просмотров 367 Комментарии 2
Всего комментариев 2
Комментарии
  1. Старый комментарий
    Привет!

    Законспектировал себе Веста.

    Предлагаю выбрать точку опоры для исследования = физиология обычного человека (ОЧ).

    Ограничения вычислительных способностей ОЧ вызвало появление способов программирования. Как пишут отцы: сначала прямо 0 и 1, затем придумали ассемблер, затем языки выше уровнем, затем процедурные, затем ООП.

    Это упрощённое описание развития ЯП отражает увеличение сложностей задач, которые решали люди при помощи компьютера.

    Можно и сейчас писать всё на ассемблере. И есть такие выдающиеся. А ОЧ не может, ему трудно.

    О чём и рассказывает уважаемый Егор Бугаенко - в его жизни пришло время, когда он стал браться за задачи, которые процедурным стилем решались перенапряжением его умственных способностей, что привело к потере удовольствия от программирования. А Егор (как и мы) любит и хочет программировать с удовольствием. И Егор нашёл этот способ.

    И я ему признателен за это, потому что, как ОЧ, я столкнулся с ситуациями, когда дня три с упоением программируешь процедурно, а потом бац! И собственный код становится непонятным, плохим. И начинаешь заново, огульно, программировать процедурно. И опять на день 4-5 свой код становится непонятным, плохим.

    А тут Егор: MAINTAINABLE = наше всё.

    И я начал учиться объектной декомпозиции – моделировать «тупых» надёжных исполнителей. Классы я редко использую. Своих исполнителей я «упаковываю» матрёшкой. Функции пишу простыми и короткими, чтобы, увидев их через месяц-два, у меня (да и ни у кого) не возникало желания их «упростить».

    И эти короткие методы помогли понять Егора: «Кто не пишет юнит-тесты, тот дурак».

    Как в рукопашном – быстрые и сильные идут в ММА, а обычные к Кадочникову. Так и в программировании – талантливые кодируют так, что ОЧ не понимает их код. А ОЧ используют ООП от Веста, благодаря Бугаенко.

    Вы спрашиваете: «логика поведения каждого обьекта собрана в одном месте? Или она как обычно размыта между разными обьектами?»
    Объект решает, что ему делать. Он короток, он понятен, он инкапуслирован. Вначале кажется парадоксом, но ограничения ОЧ вынуждают решать сложные задачи, используя тупых (реально тупее некуда) исполнителей. А лень кодировать даже простых исполнителей вынудит Вас использовать код повторно - а это резко увеличивает производительность (+ не надо писать юнит тесты) нашего труда и кайф от программирования.
    Набрал “тупых” и пусть они сами решают проблему. Это реально прикольно, когда программа делает, то что ты хотел, а начинаешь её пошагово отлаживать и не можешь понять: Куда? Зачем? Почему?  - о чём и писал Давид «Думать как компьютер = дурная привычка в проектах чуть сложнее простого.»

    В физическом мире Вы можете нанять исполнителя, который закупит стройматериалы и сделает ремонт, а программируя это, если Вы ОЧ и любите программировать с удовольствием, Вам придётся придумать или использовать максимально тупых и неумелых исполнителей.
    Матрёшку читать снизу вверх:

    Т.д.
    Т.п.
    Раствор_Положи
    Раствор_Мешай
    Лишнее_Отрежь
    Плитку_Посчитай
    Материал_подними
    Материал_привези
    Материал_выбери
    Продавца_найти
    Магазин_Где
    Деньги
    Замеры

    И для всех нужны юнит-тесты. Зато для следующей квартиры надёжные исполнители уже готовы. Заметили увеличение производительности Вашего труда?
    А можете всё запрограммировать в одного исполнителя, но у Вас не будет уверенности, что он мимоходом не пнёт, не весть откуда взявшуюся, собаку, которая опрокинет краску, куда не надо. И в следующую квартиру Вы не захотите его впускать, а запрограммируете нового.

    Хорошее самочувствие Ваш верный ориентир.
    Запись от tmash размещена 15.12.2018 в 09:23 tmash вне форума
  2. Старый комментарий
    Аватар для CoderHuligan
    Цитата:
    Сообщение от tmash Просмотреть комментарий
    Объект решает, что ему делать.
    Вот в этом-то и гнездится проблема.. Обьект ничего не должен решать! Вы читали статью Скотта Мэйерса "Когда приходится инкапсулировать, то иногда лучше меньше, чем больше"?
    Он утверждает следующее:
    Цитата:
    Если вы пишете функцию, которая может быть выполнена или как метод класса, или быть внешней по отношению к классу, Вы должны предпочесть ее реализацию без использования метода. Такое решение увеличивает инкапсуляцию класса. Когда Вы думаете об использовании инкапсуляции, Вы должны думать том, чтобы не использовать методы.
    http://www.softcraft.ru/coding/sm/
    Каково, а?..
    А ведь Скотт Мэйерс довольно авторитетный в С++ комьюнити человек, который написал несколько книг про ООП.
    Оказывается, что класс без методов более инкапсулирован, чем класс с методами!
    И это совершенно понятно. В Теории Автоматического Управления, обьект управления ничего не решает, а наоборот: им управляют при помощи управляющих устройств, и это научный подход, который применяется в технологических процессах.
    Такой обьект можно сохранить на диск или переслать по сети. Задайте себе вопрос: а с вашим обьектом можно проделать то же самое?

    Цитата:
    Матрёшку читать снизу вверх:
    Это матрёшка не обьекта/ов, а устройств управления с конкретными регуляторами, которые непосредственно взаимодействуют с обьектами управления.
    Запись от CoderHuligan размещена 15.12.2018 в 13:24 CoderHuligan вне форума
 
КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Рейтинг@Mail.ru