Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.145.172.213] |
|
Страницы: (21) 1 2 [3] 4 5 ... 20 21 ( Перейти к последнему сообщению ) |
Сообщ.
#31
,
|
|
|
Смоллтоковская парадигма же. Общая шина, сообщения, которыми обмениваются объекты. Ну! Цитата Object-oriented software construction is the building of software systems as structured collections of possibly partial abstract data type implementations. Спасибо старине Мейеру за определение. |
Сообщ.
#32
,
|
|
|
Это понятно. Но я б ответ без троллинга оценил Добавлено Цитата Flex Ferrum @ Смоллтоковская парадигма же. Общая шина, сообщения, которыми обмениваются объекты. Ну! В смолтоке, как недавно выяснилось, не настоящие сообщения, а всего-то вызовы методов |
Сообщ.
#33
,
|
|
|
Цитата Flex Ferrum @ Цитата Object-oriented software construction is the building of software systems as structured collections of possibly partial abstract data type implementations. А можно пример не ОО-системы? |
Сообщ.
#34
,
|
|
|
Цитата Астарот @ Это понятно. Но я б ответ без троллинга оценил Ну, без если троллинга - то ООП не будет являться то, что не соответствует этому определению: Цитата Object-oriented software construction is the building of software systems as structured collections of possibly partial abstract data type implementations. Цитата D_KEY @ А можно пример не ОО-системы? Нет. Потому что мне нужно вспоминать системы, построенные в соответствии с модульной, процедурной или функциональной парадигмой. А я таких сходу не назову. Да и не с ходу тоже. |
Сообщ.
#35
,
|
|
|
Цитата Flex Ferrum @ Ну, без если троллинга - то ООП не будет являться то, что не соответствует этому определению: Так я и хочу услышать, что ему не соответствует - на практике. Мне в голову как-то ничего не приходит, но тогдла получается, что все есть ООП, а это явно обесценивает сам термин. Или я не втуда думаю. Добавлено Цитата Flex Ferrum @ А я таких сходу не назову. Да и не с ходу тоже. А, ок, спасибо. Цитата Flex Ferrum @ построенные в соответствии с модульной, процедурной или функциональной парадигмой Жопа в том, что та же функциональщина замечательно дружит с акторами, на которые понятие ООП замечательно ложится |
Сообщ.
#36
,
|
|
|
Цитата Астарот @ Жопа в том, что та же функциональщина замечательно дружит с акторами, на которые понятие ООП замечательно ложится Ты познаёшь дзен. Продолжай. |
Сообщ.
#37
,
|
|
|
Цитата Астарот @ Жопа в том, что та же функциональщина замечательно дружит с акторами, на которые понятие ООП замечательно ложится А процедурная обычно вполне себе structured collections of possibly partial abstract data type implementations. Собственно, примерно так и возникла та ветка ООП, что от simula67, а не от smalltalk. |
Сообщ.
#38
,
|
|
|
Цитата Астарот @ Так я и хочу услышать, что ему не соответствует - на практике. На практике, скажем, какая-нибудь система управления гидронасосом не будет ОО ни разу. Потому что её дизайн - строго процедурный, и легко расписывается в виде алгоритма (а иначе - ой). Когда ты ставишь во главу угла алгоритм и делаешь процедурную декомпозицию - это тоже не ООП. Аналогично с чистой функциональщиной - ты дизайнишь "от фукнции" (желательно - кристально чистой ). Лично для меня ООП начинается тогда, когда дизайн системы - это граф взаимодействия абстрактных объектов посредством интерфейсов. Причём, замечу, характер взаимодействия и способ реализации этих объектов для меня на втором месте. Добавлено Цитата D_KEY @ А процедурная обычно вполне себе Нет. Потому что ты идёшь от алгоритма (каким бы сложным он ни был). Начинаешь с main и спускаешься к деталям реализации конкретных процедур. Тут у тебя данные важны, но они не правят бал. |
Сообщ.
#39
,
|
|
|
Цитата Flex Ferrum @ Аналогично с чистой функциональщиной - ты дизайнишь "от фукнции" (желательно - кристально чистой ). А если эта функция завернута в актор? Цитата Flex Ferrum @ Лично для меня ООП начинается тогда, когда дизайн системы - это граф взаимодействия абстрактных объектов посредством интерфейсов Акторы кидающиеся друг в друга записочками попадают под это всецело, при этом внутри актора может быть как функциональщина, так и императивщина с классами, объектами и прочими падучими. И чо делать? |
Сообщ.
#40
,
|
|
|
Цитата Астарот @ И чо делать? Ты продолжаешь постигать дзен. Продолжай. Ведь не так важно, как реализован конкретный компонент (или фрагмент) системы внутри. |
Сообщ.
#41
,
|
|
|
Цитата Flex Ferrum @ Потому что ты идёшь от алгоритма (каким бы сложным он ни был). Начинаешь с main и спускаешься к деталям реализации конкретных процедур. В теории возможно. Но алгоритм-то работает с данными. |
Сообщ.
#42
,
|
|
|
Цитата D_KEY @ Но алгоритм-то работает с данными. И чо? Не каждая работа с данными попадает под концепцию ОО-парадигмы. Процессор тоже работает с данными в регистрах и памяти. Мы же не будем натягивать на него ОО-принципы? |
Сообщ.
#43
,
|
|
|
Цитата Flex Ferrum @ Не каждая работа с данными попадает под концепцию ОО-парадигмы. Так какая попадает, а какая нет? |
Сообщ.
#44
,
|
|
|
Цитата D_KEY @ Так какая попадает, а какая нет? Попадает та, где у тебя дизайн отталкивается от (чаще всего) абстрактных данных и логики их взаимодействия. Та, где у тебя есть компоненты и абстрактные интерфейсы для взаимодействия с ними. |
Сообщ.
#45
,
|
|
|
Это ОО код или процедурный?
int fd = /* socket, open, etc. */ ... rc = write(fd, ...); ... |