LINUX.ORG.RU

Несколько вопросов по ООП


0

0

Читаю книгу:

-------------- В ООП определены следующие свойства объектов:

Поведение (behavior) объекта - что с ним можно делать и какие методы к нему можно применять.

Состояние (state) объекта - как этот объект реагирует на применение методов.

Сущность (identity) объекта - чем данный объект отлисается от других, характеризующихся таким же поведением и состоянием. --------------

Так, если я правильно понял,

behavior -- множество всех открытых методов;

state -- множество значений полей объекта;

А identity тогда что? И почему state и behavior не полностью карактеризуют конкретный объект?

И второй вопрос:

Зависимость и агрегирование, если я правильно понял:

Зависимость - данный класс использует другой класс;

Агрегирование - данный класс содержит внутри себя класс, т.е. обычный внутренний класс. Так?


>Агрегирование - данный класс содержит внутри себя класс, т.е. обычный внутренний класс. Так?

Да еще есть композиция (когда один объект неотъемлемая часть другого).

>Зависимость - данный класс использует другой класс;

Когда поведение/состояние одного объекта зависит от другого.

>behavior -- множество всех открытых методов;

Открытые методы - это интерфейс.

Вообще тут описана концепция. Имхо ООП подход к моделированию, язык дело десятое.

Dudraug ★★★★★
()

>А identity тогда что? И почему state и behavior не полностью карактеризуют конкретный объект?

Я думаю это адрес объекта (внутри него - указатель this или self). Тут надо курить про понятия "равенства" и "эквивалентности". В Жабе эквивалентность можно обеспечить с помощью перегрузки equals, равенство - нельзя обеспечить никак если инстансы объектов разные.

>Агрегирование - данный класс содержит внутри себя класс, т.е. обычный внутренний класс. Так?

Не всегда. Обычно под аггрегированием понимается то что клиенту доступны все или часть интерфейсов вложенного объекта.

Absurd ★★★
()
Ответ на: комментарий от Absurd

> Я думаю это адрес объекта

Хм, ну если так, тогда понятно, но я думал что адрес объекта относиться к деталям реализации.

> Не всегда. Обычно под аггрегированием понимается то что клиенту доступны все или часть интерфейсов вложенного объекта.

Тогда зависимость что такое? Объекту также доступны все интерфейсные методы класса, от которого он зависит.

zxcvb
() автор топика
Ответ на: комментарий от zxcvb

>> Я думаю это адрес объекта

>Хм, ну если так, тогда понятно, но я думал что адрес объекта относиться к деталям реализации.

Это важно когда например ты засовываешь объект в хэш. Если метод equals не перегружен то в хэше будет столько одинаковых объектов, сколько ты туда засунул. Если же язык будет перегружать equals автоматически, то возможны тормоза в неожиданных местах где случайно понадобилось проверить равенство двух очень больших объектов с десятками или сотнями полей, многие из которых - коллекции.

>> Не всегда. Обычно под аггрегированием понимается то что клиенту доступны все или часть интерфейсов вложенного объекта.

>Тогда зависимость что такое? Объекту также доступны все интерфейсные методы класса, от которого он зависит.

Речь идет не о доступности тому кто аггрегировал, а о доступности извне. В COM например когда ты аггрегируешь объект ты становишься подклассом этого объекта, при этом даже не зная всех интерфейсов которые он реализует. Внешний (клиентский) код, в свою очередь, в любой момент может запросить любой интерфейс аггрегированного объекта минуя твой код и даже не зная что он имеет дело с аггрегированным объектом.

Absurd ★★★
()
Ответ на: комментарий от Absurd

> Если же язык будет перегружать equals автоматически, то возможны тормоза в неожиданных местах где случайно понадобилось проверить равенство двух очень больших объектов с десятками или сотнями полей, многие из которых - коллекции.

Ну в яве, например, equals проверяет адреса объектов.

> Речь идет не о доступности тому кто аггрегировал, а о доступности извне. В COM например когда ты аггрегируешь объект ты становишься подклассом этого объекта, при этом даже не зная всех интерфейсов которые он реализует. Внешний (клиентский) код, в свою очередь, в любой момент может запросить любой интерфейс аггрегированного объекта минуя твой код и даже не зная что он имеет дело с аггрегированным объектом.

Не затруднит ли вас написать простенький пример агрегации и зависимости?

zxcvb
() автор топика
Ответ на: комментарий от zxcvb

>Хм, ну если так, тогда понятно, но я думал что адрес объекта относиться к деталям реализации

ну замени адрес на "множесто всех имён, по которым доступно обращение к объекту"

>Тогда зависимость что такое?

разница в контроле времени жизни объекта. если по уничтожению ведущего уничтожается и ведомый (т.е. он является подобъектом по значению) - это одно; если не уничтожается - другое

jtootf ★★★★★
()
Ответ на: комментарий от zxcvb

>> Если же язык будет перегружать equals автоматически, то возможны тормоза в неожиданных местах где случайно понадобилось проверить равенство двух очень больших объектов с десятками или сотнями полей, многие из которых - коллекции.

>Ну в яве, например, equals проверяет адреса объектов.

О чем я и говорю. Адрес - это identity.

>Не затруднит ли вас написать простенький пример агрегации и зависимости?

Канонiческий пример из Джошуа Блоха - как расширить функционал класса ArrayList, добавив туда статистику использования (к примеру). Вариант с наследованием от ArrayList (1) не годится, так как реализации методов класса ArrayList вызывают другие методы этого же класса, ломая перегрузку. Решение - реализовать главный интерфейс класса ArrayList (этот интерфейс называется просто List) и делегировать методы этого интерфейса аггрегированному ArrayList'у, обложив расширенным функционалом (2).

(1) interface List --implements--> class ArrayList --extends--> class ExtendedArrayList /* Не работает так как ожидалось */

(2) interface List --implements--> class ExtendedArrayList --aggregates--> class ArrayList

Absurd ★★★
()
Ответ на: комментарий от jtootf

>>Вариант с наследованием...

>какое отношение наследование имеет к обсуждаемому вопросу?

Аггрегирование обычно является альтернативой наследованию реализации. В ++ и жабе по крайней мере это так.

Absurd ★★★
()
Ответ на: комментарий от Absurd

>Аггрегирование обычно является альтернативой наследованию реализации. В ++ и жабе по крайней мере это так

отношение "является" внезапно стало альтернативой отношению "содержит"?

http://ootips.org/uml-hasa.html

jtootf ★★★★★
()
Ответ на: комментарий от Absurd

>наследованию реализации

реализации. тогда да, пожалуй. но всё равно по ссылке сходить рекомендую, прежде всего - топикстартеру

jtootf ★★★★★
()

Наверняка есть книга, где можно узнать все эти тонкости, посоветуйте что-нибудь?

zxcvb
() автор топика
Ответ на: комментарий от www_linux_org_ru

>хорошее место, заодно там есть интересные наезды на статику

очень спорные там наезды на статику

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

>>хорошее место, заодно там есть интересные наезды на статику

>очень спорные там наезды на статику

Да все по делу. Имеем постоянно ломающиеся интерфейсы и усложнение языка в несколько раз ради околонулевого профита.

Absurd ★★★
()
Ответ на: комментарий от Absurd

>Да все по делу. Имеем постоянно ломающиеся интерфейсы и усложнение языка в несколько раз ради околонулевого профита.

4.2, 4.3

jtootf ★★★★★
()
Ответ на: комментарий от tailgunner

> Ага, и за пример берется Ява. Бугага.

Да, и еще кажется ява без дженериков. И да, спорные. Но все равно -- я оттуда почерпнул идею прокси, который на плюсах так сходу и не написать :-)

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от jtootf

>>Да все по делу. Имеем постоянно ломающиеся интерфейсы и усложнение языка в несколько раз ради околонулевого профита.

>4.2, 4.3

То есть либо шаблоны С++ и хаскель не сложны и интерфейсы в них не ломаются, либо профит намного больше нуля?

Absurd ★★★
()
Ответ на: комментарий от Absurd

>профит намного больше нуля?

ну вот ты сам всё и сказал

>То есть либо шаблоны С++...

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

>интерфейсы в них не ломаются

если в проекте ломается интерфейс, т ов нём в любом случае что-то не так - и использовать напильник придётся и в случае статики, и в случае динамики; причём в первом случае это будет проще, так как часть работы возьмёт на себя компилятор

но вообще это всё оголтелое 4.1 и 4.3. хочешь пофлеймить на эту тему - создавай отдельный топик

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

>если в проекте ломается интерфейс, т ов нём в любом случае что-то не так - и использовать напильник придётся и в случае статики, и в случае динамики; причём в первом случае это будет проще, так как часть работы возьмёт на себя компилятор
Никогда не поверю, что разгребать бесполезное говно, которое высирают компиляторы C++ при ошибках в шаблонах - проще и продуктивнее, чем отлаживать программу в дебаггере современной реализации CL.

guest-3484-2009
()
Ответ на: комментарий от guest-3484-2009

>Никогда не поверю, что разгребать бесполезное говно, которое высирают компиляторы C++ при ошибках в шаблонах - проще и продуктивнее, чем отлаживать программу в дебаггере современной реализации CL.

слышал когда-нибудь про CL головного мозга?

jtootf ★★★★★
()
Ответ на: комментарий от jtootf

> слышал когда-нибудь про CL головного мозга?

/me .oO( рано или поздно кто-то должен был это сказать )

tailgunner ★★★★★
()
Ответ на: комментарий от guest-3484-2009

>Необычайно остроумно!

зато по существу. на твои сообщения пора ставить фильтр - если упоминается CL, то ничего интересного в них не будет

jtootf ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.