Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.145.38.117] |
|
Страницы: (21) « Первая ... 4 5 [6] 7 8 ... 20 21 ( Перейти к последнему сообщению ) |
Сообщ.
#76
,
|
|
|
Цитата D_KEY @ Еще раз. Чтобы определить абстракции, тебе придется определить операции. Чтобы спроектировать систему, теме придется сделать все тоже, что ты описал для процедурного стиля. Нет. В процедурном стиле я сначала придумываю алгоритм, а потом подбираю нужные данные под него. Если вообще нужны. Конкретные свойства данных и т. п. тут не играют особой роли. Есть - и ладно. В ОО-стиле - наоборот. Конкретные алгоритмы продумываются после объектной декомпозиции. Соответственно, и подходы к реализации вроде бы одинаковых задач будут разные. Скажем, тебе нужно поддержать чтение разных типов конфигураций. В процедурном стиле ты воткнёшь if/else if и в каждой ветке вызовешь функцию чтения нужного формата файла и раскладывания по структурам. В объектом - у тебя скорее всего будет абстрактная фабрика, которая выплёвывает из себя интерфейс для чтения конфигурации. И уже в фабрике будет if/else if. Или реестр. Или ещё какой-либо способ диспетчеризации. Добавлено А абстрактная фабрика с интерфейсами в ОО-подходе у тебя появится для того, чтобы реализовать букву "D" из SOLID. Чтобы потом написать юнит-тесты, в которых можно подменять источники конфигурации (та самая "инверсия зависимостей"). В процедурном подходе ничего такого не понадобится. Шаг алгоритма пройден. Если успешно - идём дальше. |
Сообщ.
#77
,
|
|
|
Цитата Flex Ferrum @ В процедурном стиле я сначала придумываю алгоритм, а потом подбираю нужные данные под него. Где ты такое видел вообще? |
Сообщ.
#78
,
|
|
|
Цитата D_KEY @ Где ты такое видел вообще? А в чём, по твоему, суть процедурного подхода? Алгоритмическая декомпозиция задачи. |
Сообщ.
#79
,
|
|
|
В разбиении программы на подпрограммы в рамках императивного подхода.
|
Сообщ.
#80
,
|
|
|
Цитата D_KEY @ В разбиении программы на подпрограммы в рамках императивного подхода. Вот. Алгоритмическая декомпозиция. Про которую я и говорю. Тогда в чём вопрос? Цитата D_KEY @ Где ты такое видел вообще? Спор ради спора? |
Сообщ.
#81
,
|
|
|
Цитата Flex Ferrum @ Цитата D_KEY @ В разбиении программы на подпрограммы в рамках императивного подхода. Вот. Алгоритмическая декомпозиция. Про которую я и говорю. Тогда в чём вопрос? Отсюда не следует, что ты сначала обдумываешь алгоритм, потом подбираешь под него данные. |
Сообщ.
#82
,
|
|
|
Цитата D_KEY @ Отсюда не следует, что ты сначала обдумываешь алгоритм, потом подбираешь под него данные. Именно это отсюда и следует. Если под данными считать "абстракции". Алгоритмическая декомпозиция против объектной. Вроде азы же! |
Сообщ.
#83
,
|
|
|
Цитата Flex Ferrum @ Цитата D_KEY @ Отсюда не следует, что ты сначала обдумываешь алгоритм, потом подбираешь под него данные. Именно это отсюда и следует. Как? Цитата Алгоритмическая декомпозиция против объектной. Вроде азы же! Эти азы расплывчаты и встречаются только в ОО литературе. |
Сообщ.
#84
,
|
|
|
Цитата D_KEY @ Еще раз. Чтобы определить абстракции, тебе придется определить операции. Чтобы спроектировать систему, теме придется сделать все тоже, что ты описал для процедурного стиля. Так ты на абстракции смотришь через призму деталей, вот у тебя и не получается понять что к чему. Попробуй смотреть на абстракции не через призму деталей, а через призму абстракций. Т.е. вот у тебя есть какой то интерфейс "Живое" существо, ты описываешь в нем то, что ему пресуще. Как ты это сделаешь в процедурном стиле, чтоб избежать дублирования кода в будущем, как ты будешь изменять поведение в зависимости от интерфейсов/классов(от конкретизации живого существа)? Как ты будешь такими объектами управлять? Как ты будешь инкапсулировать детали реализации? Вот при ОО подходе тут уже вырисовываются разные интерфейсы, без всяких деталей. А при процедурном как? |
Сообщ.
#85
,
|
|
|
Wound, речь про то, что такое ООП. Это все хорошо, что ты пишешь. Но не дает определение.
|
Сообщ.
#86
,
|
|
|
Цитата D_KEY @ Wound, речь про то, что такое ООП. Это все хорошо, что ты пишешь. Но не дает определение. Определение можешь посмотреть на вики. Чем оно тебя не устраивает? |
Сообщ.
#87
,
|
|
|
Цитата Wound @ Цитата D_KEY @ Wound, речь про то, что такое ООП. Это все хорошо, что ты пишешь. Но не дает определение. Определение можешь посмотреть на вики. Чем оно тебя не устраивает? Расплывчатостью. Сможешь посмотреть на систему и сказать, ОО она или нет? А другие "эксперты" согласятся с тобой? |
Сообщ.
#88
,
|
|
|
ООП по сути не панацея, а призвана всего лишь упростить процесс разработки и сопровождения ПО.
Конечно можно все это съэмулировать в процедурном стиле и в функциональном. Но сколько времени тебе на это понадобиться и как просто потом все это будет поддерживать? А тут тебе дают инструмент призванный съэкономить время, деньги и ресурсы. Плюс ты получаешь гибкую систему, которую можно расширять без переписывания и без гемороя в любую сторону. Добавлено Цитата D_KEY @ Сможешь посмотреть на систему и сказать, ОО она или нет? А другие "эксперты" согласятся с тобой? Если она удовлетворяет основным принципам ООП, тогда можно сказать что это ООП система. Если нет - значит не судьба. |
Сообщ.
#89
,
|
|
|
Цитата Wound @ Если она удовлетворяет основным принципам ООП Разные люди разные принципы выделяют. И все эти принципы расплывчаты. Кто-то скажет, что система им удовлетворяет, а кто-то скажет, что нет. |
Сообщ.
#90
,
|
|
|
Цитата D_KEY @ А другие "эксперты" согласятся с тобой? А что есть какой то другой способ определить ОО эта система или нет? Добавлено Цитата D_KEY @ Разные люди разные принципы выделяют. И все эти принципы расплывчаты. Кто-то скажет, что система им удовлетворяет, а кто-то скажет, что нет. Приводи примеры. Я не встречал описание ОО принципов, отличных от тех, что написаны на вики. |