ООП иль процедурка?(продолжение)
Если Бугаенко с сотоварищи пытаются функции заменить их близким подобием, то мы так не извращаемся.. У нас есть две иерархии: одна иерархия статических типов, а другая функциональных компонентов. Последняя оперирует исключительно первой. Обе находятся в глобальной видимости, поэтому система легко расширяема. Добавляй функционал и новые типы-обьекты. Хотя это и не отменяет модульное построение программы. Просто надо всегда помнить, что модуль это не обьект, ибо не имеет динамического состояния, а вот обьект-агрегат имеет, но только статическое состояние, которое определяется его свойствами. Но нам ещё нужно что-то, что определяло бы состояние обьекта в функциональном смысле в каждый момент времени. Функция-автомат как раз это и делает, ибо она также имеет своё собственное состояние, но уже динамическое, которое зависит от поведения данного обьекта. В агрегате должно быть одно поле, которое определяет это состояние. Однако между вызовами функции-автомата, она(эта функция) не имеет своего собственного состояния, поэтому легко понятна(чёрный ящик). Она может принимать любые однотипные обьекты с разными внутренними состояниями, которые переводят автомат в требуемое состояние, а при выходе из неё он переходит в начальное. Поэтому поведение агрегата полностью определяется всего одной переменной, одним единственным полем в самой структуре-агрегате. А поэтому! он(агрегат) совсем не нуждается в какой-либо конкретной функции, чтобы определить своё поведение, ибо оно уже зашито в него самого. Здесь принципиальное отличие от ООП. Если в ООП обьект вообще не имеет своего состояния, тем самым имитируя модуль, то здесь состояние имеет только агрегат, а это развязывает нам руки и упрощает понимание и кодирование. Принципиально не верно держать данные и функции в одной клетке. Это как мух заставить питаться только котлетами. Но сама их природа требует разнообразной пищи. Пухлость программ этому подтверждением. Имеем например обьект "Робот". Агрегат состоит из полей, которые определяют его свойства, например - цвет робота, материал, количество конечностей и т.п.. Но, чтобы он стал полноценным обьектом, мы в него добавляем дополнительное поле: состояние. Оно описывает поведение данного обьекта в каждый момент времени. Просто прочитав эту переменную мы можем узнать в каком состоянии находится робот в данный момент. Оно не размыто по разным "флагам", как обычно, по всему коду, а собрано в одной единственной переменной. Состояние "движение вверх", "движение вниз", "стоит на месте" и т.д.(их может быть много) Функция-автомат принимает этот агрегат-обьект и переходит в то состояние, в котором находится обьект(читает это поле). По заверершении работы она переходит в начальное сохраняя себя в виде чёрного ящика. В этой функции мы держим всю логику и вызываем соответствующие функции, которые определяют конкретное действие обьекта. В ООП поведение обьекта определяется его методами(как бы), однако это всего лишь функции, которые этот обьект выполняет, а кто направляет и контролирует его поведение совершенно не ясно. Я не могу проверить в каком состоянии находится обьект в ООП. В ООП обьект рефлекторно реагирует на внешние раздражители, а раздражают его другие обьекты. Он не самостоятелен и не может жить без других. Это поведение глупой амёбы.. А наш может. Поэтому наш более "обьектен".. В этом отличие.. Если обьект не имеет своего состояния, то он не имеет права называться обьектом.. Скажите мне оопники: у вас логика поведения каждого обьекта собрана в одном месте? Или она как обычно размыта между разными обьектами ? Я жду от вас ответа, ибо мне это действительно интересно. Я действительно хочу это знать.. У меня она собрана в одном месте. Данные в одном, логика в одном.. А у вас как с этим?. Не спешите, подумайте и дайте мне ответ, я подожду.. |
Всего комментариев 3
Комментарии
-
А как это в коде будет выглядеть?
Запись от ТабуретY размещена 12.12.2018 в 03:44 -
Запись от CoderHuligan размещена 12.12.2018 в 10:21 -
Запись от CoderHuligan размещена 14.12.2018 в 10:11