Вопрос знатокам ООП. - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Существо.
Флора/Фауна
Подвид
Вид
Семейсвто
и т.д.
Так хотите?
Ну это простое наследование от базового объекта "Существо"
Но можно пойти и глубже - есть одноклеточные/многоклеточные, и это всё к живым. Но есть ещё и неживые. Всё зависит от задач, под которые вам необходимо найти свойства базового объекта, и уже от них наследоваться.
Если уж совсем головой стукнуться, то можно и до атомов дойти и начать и их делить на составляющие в поисках фундаментального объекта-родителя (осторожно - реакция деления может стать цепной, и вы уничтожите полмира :))
Верно. На первый взгляд, концепция ООП идеально подходит для построения иерархии. Но, как работать с построенной через ООП иерархией? Это же море синтаксиса и сложности с переходами между звеньями из за прав доступа к классам и их содержимому. Тут начинается оверхед, как следствие разделения на классы. ООП с одной стороны дает возможность строить иерархию, с другой чрезвычайно затрудняет работу с ней.
Ну вот нет. Как раз ООП даёт очень простой доступ к любому члену иерархии в любом её расположении.
Для начала найдите свой базовый объект с минимально-необходимыми свойствами.
Остальные объекты наследуете от него. Чтобы не изобретать велосипед, ваш базовый объект должен быть наследником класса CObject стандартной библиотеки. Это позволит вам не отвлекаясь на изобретение списков создавать свою иерархию ваших объектов
CObject --> CBaseObject --> нужная вам иерархия.
В CBaseObject у вас должен быть виртуальный метод, возвращающий этот объект. Тогда у каждого из наследников соответственно будет иметься этот метод, и он будет возвращать именно объект-наследник. В базовом классе CObject уже есть такой метод - Type(). Соответственно, если будет такой же виртуальный метод и у вашего CBaseObject, и он будет возвращать тип объекта, то вы по этому типу сможете знать к какому объекту обратились.
Это как бы базовая основа всех ваших объектов. И они должны все храниться в своих списках - каждый список будет содержать в себе объекты только одного типа - рыбы, животные, люди, боги, и т.д.
Т.е., вам потребуется для каждого подтипа иметь свой список. И должен быть один список, в который будут размещаться списки, следующие в иерархии. В каждом их этих списков тоже должны быть списки - опять-таки - следующие в иерархии. И т.д.
Т.е., вам нужен ещё объект базового списка, в который будете размещать требуемые списки. И в этом базовом списке должен быть метод Type(), и должен быть метод, позволяющий вернуть любой объект, хранящийся в нём по его индексу. Тогда, если так будет сделано, то у вас в любом из списков будет автоматически иметься метод, возвращающий требуемый объект.
В общем - сначала продумываете свой объект-фундамент, затем объект-список. Объекты-списки тоже выдумывать не нужно - они уже есть.
А далее - дело техники. И нужно будет знать всего-лишь тип нужного вам искомого объекта. В его иерархии будет множество типов, и каждый из них вам известен, и вы его можете запросить и получить.
Как мне показалось - в даном случае ООП не при чем.
У Петера - идет перебор всех объектов в массиве в поисках нужного по какому-то ключу. И разницы нет, что используешь ты классы, что используешь массивы, что вобще используешь кучу объявленных объектов.
ООП позволяет иметь список объектов, у каждого из которых, скажем, есть метод GetColor() - и пользователь точно так же перебирает все объекты в поисках нужного цвета. Но, если без ООП - мы имеем массив одинаковых структур, про которые надо знать пользователю, чтобы достать цвет оттуда, откуда надо, то с ООП - пользователю совершенно не требуется знать, как именно и где хранится цвет - метод GetColor() объекта сам знает, откуда брать цвет.
То есть, для ООП - пользователю не надо знать, как и где хранится цвет объекта. Таким образом, если вдруг нам потребуется добавить "объект для слепых", в котором цвет закодирован по-Брайлю, точками - то мы без всяких трудностей добавим этот объект в наш список, и изменим только его метод GetColor(), который будет из точек "по-Брайлю" получать код цвета, и возвращать его в обычном виде. Для пользователя нашего списка - ничего не изменится.
Если же у нас просто массив - то мы не сможем туда поместить "точки по-брайлю". У нас в нем нет такого поля.
Польза от ООП, действительно, хорошо видна, когда мы наследуемся от CObject, потом создаем массив объектов CArrayObj, а потом, написав лишь функцию сравнения - сразу получаем возможность быстрой сортировки и бинарного поиска.
Грубо говоря, для моего примера выше, с цветом - для ООП - мы пишем функцию сравнения, получая цвет через GetColor(), и можем сортировать наши объекты по цвету, даже не зная, что у нас половина объектов имеет реальный цвет, а половина - "точки по-брайлю". И если мы захотим добавить объект с новым кодированием цвета - опять же, нам достаточно будет только написать функцию GetColor(), которая бы приводила свое представление цвета к стандартному - и после этого уже написанные алгоритмы сортировки и поиска без проблем воспримут этот новый объект.
То есть, по сути, ООП нам позволила иметь алгоритм сортировки и поиска еще ненаписанных объектов, еще до того, как мы определились, как именно будет в них представлен цвет, и как он будет храниться.
Польза от ООП, действительно, хорошо видна, когда мы наследуемся от CObject, потом создаем массив объектов CArrayObj, а потом, написав лишь функцию сравнения - сразу получаем возможность быстрой сортировки и бинарного поиска.
Это же море синтаксиса и сложности с переходами между звеньями из за прав доступа к классам и их содержимому. Тут начинается оверхед, как следствие разделения на классы. ООП с одной стороны дает возможность строить иерархию, с другой, чрезвычайно затрудняет работу с ней.
модификаторы прав доступа позволяют на этапе компиляции выявить ошибки
в общем, все это не затрудняет работу с классами, не нужно не пользуйтесь, пишите все в public: , потом разберетесь будет проще
ЗЫ: Много красивых фраз про ООП, то вот инкапсуляция, то вот наследование... это все хорошо, но самое главное преимущество ООП перед другими стилями программирования - это хранение всех данных (поля класса) и функций работы с этими данными (методы класса) в одном месте (класс) - по книжному это инкапсуляция. Дальше использование ООП зависит от задач, если задача позволяет масштабировать классы, то будет нужна иерархия и будут базовые классы и их наследники - пользоваться ли этим, зависит от Вас
Должен признать, что в концепции ООП, "Объект" представлен в более широком контексте, чем в моем "Ядре". Но, это и не удивительно, так как я до сих пор занимался только графикой, а ООП используется для решения широкого спектра задач. Мое "меню" объектов достаточно скудно и кроме "метка", "элемент","окно", пожалуй мало что еще есть... Но, для граф.интерфейсов - ничего более и не надо.
Однако, сейчас встал вопрос о расширении понятия "Объект" и построении иерархии. Простое двумерное ядро не может принять все разнообразие объектов базы знаний, и следовательно, либо нужно создавать разные ядра для разных объектов, либо идти по пути концепции ООП.
В сущности, это чисто технический вопрос. Что эффективней, что быстрее, что читабельней и т.д...
Действительно, все объекты можно просто держать в массиве в виде списка свойств, среди которых будут указатели на другие массивы, с другими объектами и так далее. Либо явно использовать ООП. Объектная ориентированность неизменно присутствует в обоих подходах, только методы реализации разные. Та же память, те же указатели, те же объекты, та же классификация. Только форма кода разная...
Хотел об этом Петру рассказать когда он поймёт предложенную ему концепцию хранения данных.
Я попытаюсь разобраться в этой концепции хранения и работы с данными.
Хорошо. Можно в личке пообщаться предметно. Или в скайпе - как вам удобнее. Просто частности - не по теме данного топика - здесь как я понимаю - лишь общие вопросы.