Какой смысл в ООП?

Насколько я могу судить, несмотря на бесчисленные миллионы или миллиарды, потраченные на обучение, языки и инструменты ООП, ООП не повысила производительность труда разработчиков или надежность программного обеспечения, а также не снизила затраты на разработку. Мало кто использует ООП в каком-либо строгом смысле (мало кто придерживается или понимает такие принципы, как LSP); похоже, что подходы, применяемые к моделированию проблемных областей, мало единообразны или непротиворечивы. Слишком часто класс используется просто для его синтаксического сахара; он помещает функции для типа записи в их собственное маленькое пространство имен.

Я написал большое количество кода для самых разных приложений. Хотя были места, где истинно замещаемый подтип играл важную роль в приложении, они были довольно исключительными. В общем, хотя много говорят на словах о «повторном использовании», реальность такова, что если кусок кода не выполняет именно то , что вы хотите, то очень мало рентабельного «повторного использования». Очень трудно спроектировать классы, чтобы их можно было правильно расширять , поэтому стоимость расширения обычно настолько велика, что «повторное использование» просто не стоит.

Во многих отношениях это меня не удивляет. Реальный мир - это не «ОО», и идея ОО, подразумеваемая в ОО - что мы можем моделировать вещи с помощью некоторой классовой таксономии - кажется мне очень фундаментальной ошибкой (я могу сидеть на столе, пне, капоте автомобиля кто-то на коленях - но не один из тех - стул). Даже если мы перейдем к более абстрактным областям, ОО-моделирование часто бывает сложным, нелогичным и, в конечном счете, бесполезным (рассмотрим классические примеры кругов / эллипсов или квадратов / прямоугольников).

Так чего мне здесь не хватает? Где ценность ООП, и почему все время и деньги не смогли сделать программное обеспечение лучше?

23.08.2008 14:40:28
Ваша аналогия является слишком высокой абстракцией для предполагаемого «варианта использования»; Стол, пень, капот, чей-то круг - это составы молекул, атомов, протонов, нейтронов, электронов, образующих достаточно большую площадь поверхности, на которую приклад может опираться силой тяжести.
icelava 31.12.2008 02:47:43
Независимо от того, сколько раз запускается один и тот же поток, он всегда вызывает большой интерес (несмотря на то, что дубликаты здесь обычно не допускаются). И, конечно же, выбранный ответ всегда совпадает с первоначальным мнением спрашивающего.
TM. 31.12.2008 03:04:26
Проблема с ООП заключается в том, что она не вписывается в контекст. Это отлично подходит для некоторых целей, а не для всех целей. Это отличный инструмент. Это паршивое Евангелие.
Mike Dunlavey 31.12.2008 15:19:17
Извините, но я не могу избавиться от ощущения, что вы никогда не программировали, используя какой-либо язык. И вот почему: ООП - это основа работы для библиотек базовых компонентов во всех современных средах (Java, .NET, Python, Ruby - просто чтобы назвать несколько основных потоков). Все эти базовые библиотеки используются повторно ежедневно, поэтому, если это не считается, я не знаю, что делает. Так что не поймите меня неправильно, но используйте повторно код, если факт - и чрезвычайно распространенный! Я не хочу, чтобы это звучало как-то оскорбительно, просто хочу подчеркнуть.
Matthias Hryniszak 8.08.2009 19:08:51
@ Джордж Джемпти: это был Джоэл Спольски из фильма «Как Microsoft проиграла войну API» ( joelonsoftware.com/articles/APIWar.html ), заголовок отрывка «Автоматические трансляции выигрывают день».
GodsBoss 19.02.2010 16:42:31
30 ОТВЕТОВ
РЕШЕНИЕ

Нет эмпирических данных, свидетельствующих о том, что объектная ориентация является более естественным способом для людей думать о мире. Есть некоторые работы в области психологии программирования, которые показывают, что ОО не является более подходящим, чем другие подходы.

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

Недостаточно просто принять методы ОО и требовать от разработчиков использования таких методов, потому что это может оказать негативное влияние на производительность разработчика, а также на качество разрабатываемых систем.

Который из "О юзабилити OO представлений" из Communications of ACM Oct. 2000. В статьях в основном сравнивается OO с процессно-ориентированным подходом. Существует множество исследований того, как «думают» люди, работающие с методом ОО (Int. J. of Human-Computer Studies 2001, выпуск 54, или Human-Computer Interaction 1995, том 10, имеет целую тему об исследованиях ОО), и из того, что я прочитал, ничто не указывает на некоторую естественность ОО-подхода, который делает его более подходящим, чем более традиционный процедурный подход.

24
8.07.2016 17:11:10
Работает нормально. Чего он не может сделать, так это заставить плохих кодеров писать хороший код. По этой причине есть периодический оттенок.
chaos 31.12.2008 04:43:35
@melaos: резюме находится посередине. ООП является одним из инструментов в наборе инструментов, а не единственным, и ничто не заменит обучения, опыта и суждений.
Mike Dunlavey 31.12.2008 14:37:17
Я нахожу довольно забавным, когда кто-то публикует «Вопрос», чтобы обсудить точку зрения, а затем принимает первый ответ, который подтверждает его точку зрения, даже если есть вопросы с более высоким рейтингом, поддерживающие противоположное. Человеческая природа это круто.
Bill K 1.07.2009 00:50:48
@melaos, краткое изложение (по крайней мере, из этих статей) состоит в том, что ничто не говорит о том, что ОО является естественным способом мышления людей и, следовательно, не превосходит по своей сути любой другой способ создания программ.
Svend 20.10.2009 15:58:14
@ Билл К: Это был один из немногих ответов, которые приводили цитаты, а не махали руками и требовали, чтобы ОО «должен» быть лучше. Если упомянутая литература поддерживает идею о том, что ОО не является каким-либо конкретным улучшением или какой-либо конкретной выгодой, и, следовательно, поддерживает мою первоначальную позицию, я не уверен, почему я должен игнорировать ее. Можете ли вы предоставить аналогичные ссылки, которые противостоят моему ОП?
DrPizza 30.11.2009 06:46:53

На грани религиозного, но я бы сказал, что вы рисуете слишком мрачную картину состояния современного ООП. Я бы сказал, что на самом деле это снизило затраты, сделало крупные программные проекты управляемыми и так далее. Это не означает, что это решило фундаментальную проблему программного беспорядка, и это не означает, что средний разработчик - эксперт ООП. Но модульность функций в объектные компоненты, безусловно, уменьшила количество спагетти-кода в мире.

Я могу вспомнить десятки библиотек, которые прекрасно подходят для повторного использования и которые сэкономили время и деньги, которые никогда не могут быть рассчитаны.

Но в той степени, в которой ООП было пустой тратой времени, я бы сказал, что это связано с отсутствием подготовки программистов, что усугубляется крутой кривой обучения изучению отображения ООП для конкретного языка. Некоторые люди "получают" ООП, а другие никогда не будут.

28
23.08.2008 14:45:23
Я только что дал вам голос, который бросил вам более 2000 баллов - надеюсь, он будет держаться. : P
Jason Bunting 8.09.2008 23:52:38
Редко можно увидеть, как ООП обучают эффективно.
Jon W 3.09.2009 12:32:18
Ваш ответ звучит очень похоже на тот, который дают тренеры Agile / Scrum, когда его спрашивают, имеет ли он смысл - «это очень полезно, если вы делаете это правильно; если вы терпите неудачу, значит, вы делаете это неправильно». Легко разбрасывать такие слова, как «многократно используемые» и «обслуживаемые», но не так просто количественно оценить эти качества в реальном коде, и нет рецепта, который скажет вам, как написать хороший ООП (несмотря на тысячи книг, пытающихся это сделать) , Мы также получаем вредную привычку якобы игнорировать аппаратное обеспечение, что приводит к ужасной производительности на алтаре и позволяет избежать преждевременной оптимизации.
Tom 28.01.2016 15:13:59

Реальный мир - это не «ОО», и идея ОО, заключающаяся в том, что мы можем моделировать вещи с помощью некоторой классовой таксономии, кажется мне очень фундаментальной ошибкой.

В то время как это верно и было замечено другими людьми (возьмите Степанова, изобретателя STL), остальное - ерунда. ООП может быть ошибочным, и это, конечно, не серебряная пуля, но это делает крупномасштабные приложения намного проще, потому что это отличный способ уменьшить зависимости. Конечно, это верно только для «хорошего» дизайна ООП. Небрежный дизайн не даст никакого преимущества. Но хороший, развязанный дизайн может быть очень хорошо смоделирован с использованием ООП и не очень хорошо с использованием других методов.

Существуют гораздо лучшие, более универсальные модели ( на ум приходит модель типа Haskell ), но они также часто являются более сложными и / или трудными для эффективного внедрения. ООП - хороший компромисс между крайностями.

119
23.05.2017 11:46:39
Мне кажется интересным, что это имеет больше голосов, чем вопрос, и утвержденный ответ, вместе взятые.
Brad Gilbert 15.09.2008 16:14:43
Я считаю систему типов Хаскелла гораздо более интуитивной, чем ОО.
axblount 23.10.2008 16:03:39
@Konrad: «но это делает большие приложения намного проще» - хм, я не уверен, что это правда. Это делает их более ремонтопригодными в том смысле, что изменение одной вещи не должно сломать другую, а проще? Это град, чтобы проглотить ...
Mitch Wheat 31.12.2008 01:14:34
@BradGilbert: конечно, спрашивающий выбрал ответ, который идеально совпадает с мнением в его первоначальном вопросе. Что поднимает вопрос, зачем задавать вопрос, если вы уже определились с ответом?
TM. 31.12.2008 04:55:58
@ Митч: Я бы даже сказал, что вы не можете (на сегодняшний день) писать крупномасштабные приложения без какой-либо объектной ориентации. Масштабный здесь> 1М LOC.
Konrad Rudolph 31.12.2008 13:30:43

Я писал код ОО последние 9 лет или около того. Кроме использования сообщений, мне трудно представить другой подход. Основное преимущество, которое я вижу, полностью соответствует тому, что сказал CodingTheWheel: модульность. Естественно, OO побуждает меня создавать свои приложения из модульных компонентов, которые имеют чистые интерфейсы и четкие обязанности (то есть слабосвязанный, очень сплоченный код с четким разделением задач).

Я думаю, что OO ломается, когда люди создают глубоко вложенные классовые иерархии. Это может привести к сложности. Однако выделение общей финктальности в базовый класс, а затем повторное использование этого в других классах-потомках - очень элегантная вещь, ИМХО!

7
23.08.2008 15:02:58

@CodingTheWheel

Но в той степени, в которой ООП было пустой тратой времени, я бы сказал, что это связано с отсутствием подготовки программистов, что усугубляется крутой кривой обучения изучению отображения ООП для конкретного языка. Некоторые люди "получают" ООП, а другие никогда не будут.

Я не знаю, если это действительно удивительно, хотя. Я думаю, что технически обоснованные подходы (LSP - очевидная вещь) затрудняют использование , но если мы не используем такие подходы, это делает код хрупким и нерасширяемым в любом случае (потому что мы больше не можем рассуждать об этом). И я думаю, что противоречивые результаты, к которым нас приводит ООП, делают неудивительным, что люди не поднимают это.

Что еще более важно, поскольку нормальным людям программное обеспечение уже в принципе слишком сложно для надежного и точного написания, должны ли мы действительно превозносить технику, которая последовательно преподается плохо и кажется трудной для изучения? Если выгоды были четкими, то это может быть стоит настойчивая, несмотря на трудности, но это, кажется, не так.

5
23.08.2008 15:06:40
«Правильная подготовка» должна быть очень длинной, абстрактной и сложной в наши дни. Я знаю: я преподаю программирование. Несколько десятилетий назад многие люди могли научиться программированию. Я думаю, что это больше не правда.
user4624979 2.07.2015 18:07:41

@Sean

Однако выделение общей финктальности в базовый класс, а затем повторное использование этого в других классах-потомках - очень элегантная вещь, ИМХО!

Но «процедурные» разработчики делали это десятилетиями. Синтаксис и терминология могут отличаться, но эффект идентичен. ООП - это больше, чем «повторное использование общей функциональности в базовом классе», и я мог бы даже пойти так далеко, чтобы сказать, что это вообще трудно описать как ООП; вызов одной и той же функции из разных битов кода - такая же старая техника, как и сама подпроцедура.

6
23.08.2008 15:08:58

@Konrad

ООП может быть ошибочным, и это, конечно, не серебряная пуля, но это делает крупномасштабные приложения намного проще, потому что это отличный способ уменьшить зависимости

Это догма. Я не вижу, что делает ООП значительно лучше в этом отношении, чем процедурное программирование старого. Всякий раз, когда я делаю вызов процедуры, я изолирую себя от особенностей реализации.

6
23.08.2008 15:11:06

«Даже если нет фактической [информационной архитектуры], это не значит, что мы не испытываем и не воспринимаем ее как таковую. Дзен-буддисты говорят, что нет фактического« я », но они по-прежнему называют своих детей», - Эндрю Хинтон.

1
23.08.2008 15:11:50

Это парадигма программирования. Созданная для того, чтобы нам, простым смертным, было проще разбить проблему на более мелкие, работоспособные части ...

Если вы не находите это полезным. Не используйте его, не платите за обучение и будьте счастливы.

Я, с другой стороны, считаю это полезным, поэтому я буду :)

14
23.08.2008 15:14:09

Относительно прямого процедурного программирования, первый фундаментальный принцип ООП - это понятие сокрытия и инкапсуляции информации. Эта идея приводит к понятию класса, который отделяет интерфейс от реализации. Это чрезвычайно важные концепции и основа для создания основы, позволяющей думать о разработке программ по-другому и лучше (я думаю). Вы не можете спорить против этих свойств - здесь нет компромисса, и это всегда более чистый способ модулировать вещи.

Другие аспекты ООП, включая наследование и полиморфизм, также важны, но, как уже упоминали другие, они обычно используются чрезмерно. То есть: иногда люди используют наследование и / или полиморфизм, потому что они могут, а не потому, что они должны иметь. Они представляют собой мощные концепции и очень полезны, но их необходимо использовать с умом, а не автоматические выигрышные преимущества ООП.

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

14
24.08.2008 12:51:08
Повторное использование является чем-то вроде грааля для разработчиков программного обеспечения, не так ли, независимо от того, какую парадигму они используют, будь то ОО или функциональная или что-то еще? Это вступает в противоречие с постоянно меняющимися требованиями, предъявляемыми к программному обеспечению, и, похоже, вопрос заключается в создании гибких конструкций.
Geoglyph 14.01.2009 15:59:13
«Понятие класса, который отделяет интерфейс от реализации» - я думал, что интерфейсы были интерфейсами, а классы - реализациями? Может быть, я просто слишком ориентируюсь на процесс, но я думаю, что это полиморфизм, разница в коде с единообразием в использовании, это начало OOP; Я полагаю, что «группа функций C» отделяет интерфейс от реализации так же, как и «класс Java». Может я все не прав?
Jonas Kölker 25.06.2009 22:15:22
@Jonas - Для вашей «связки функций C» - я согласен, что они могут отделить интерфейс от реализации, и в этот момент он становится ООП. Если в примере продолжается определение структуры C, с которой работает API, вы в основном создали инкапсуляцию (особенно, если API работает непрозрачно в структуре) ... и тогда это действительно ООП в C.
Tall Jeff 26.06.2009 00:38:10

@Джефф

Относительно прямого процедурного программирования, первый фундаментальный принцип ООП - это понятие сокрытия и инкапсуляции информации. Эта идея приводит к понятию класса, который отделяет интерфейс от реализации.

Который имеет более скрытую реализацию: iostreams C ++ или FILE * s C?

Я думаю, что использование непрозрачных объектов контекста (HANDLE в Win32, FILE * в C, чтобы назвать два хорошо известных примера - черт, HANDLE живут по другую сторону барьера режима ядра, и это действительно не получает гораздо более инкапсулированный, чем это) также встречается в процедурном коде; Я изо всех сил пытаюсь понять, как это что-то особенное для ООП.

Я полагаю, что это может быть отчасти из-за того, что я изо всех сил пытаюсь увидеть преимущества: части, которые явно хороши, не являются специфическими для ООП, тогда как части, которые являются специфическими для ООП, явно не хороши! (это не означает, что они обязательно плохие, скорее, я не видел доказательств того, что они широко применимы и неизменно полезны).

5
23.08.2008 15:54:57

ООП имеет снижение затрат и повышение эффективности.

Когда я сделал переход с классического ASP / VBScript на C #, я заметил ОГРОМНОЕ увеличение производительности благодаря ООП.

0
23.08.2008 15:57:02
Я не понимаю, огромный рост. Я обнаружил, что огромное увеличение происходит после создания классов, которые вы можете использовать повторно. В неопорных языках огромная производительность достигается после создания ваших библиотек / модулей. Для меня это всегда было сочетание инструментов и библиотек / классов.
bruceatk 10.10.2008 12:35:12

Я думаю, что использование непрозрачных объектов контекста (HANDLE в Win32, FILE * в C, чтобы назвать два хорошо известных примера - черт, HANDLE живут по другую сторону барьера режима ядра, и это действительно не получает гораздо более инкапсулированный, чем это) также встречается в процедурном коде; Я изо всех сил пытаюсь понять, как это что-то особенное для ООП.

HANDLEs (и остальная часть WinAPI) - ООП! C не очень хорошо поддерживает ООП, поэтому специального синтаксиса нет, но это не значит, что он не использует те же понятия. WinAPI во всех смыслах этого слова - объектно-ориентированная структура.

Видите, в этом и заключается проблема с каждым отдельным обсуждением, связанным с ООП или альтернативными методами: никто не знает точно об определении, все говорят о чем-то другом, и, следовательно, консенсус не может быть достигнут. Похоже, трата времени для меня.

21
23.08.2008 16:05:08
Я собирался опубликовать что-то очень похожее.
Brad Gilbert 15.09.2008 16:17:16
Я согласен, что вы можете использовать концепции ООП без специального синтаксиса, но с другой стороны, я не думаю, что WinAPI является хорошим примером концепций ООП.
Lena Schimmel 6.03.2009 01:55:48

РУЧКИ (и остальная часть WinAPI) - ООП!

Они все же? Они не наследуются, они, конечно, не заменяемы, им не хватает четко определенных классов ... Я думаю, что они далеки от "ООП".

1
23.08.2008 16:31:57

РУЧКИ (и остальная часть WinAPI) - ООП!

Они все же? Они не наследуются, они, конечно, не заменяемы, им не хватает четко определенных классов ... Я думаю, что они далеки от "ООП".

Вы когда-нибудь создавали окно, используя WinAPI? Затем вы должны знать, что вы определяете class ( RegisterClass), создаете экземпляр it ( CreateWindow), вызываете виртуальные методы ( WndProc) и методы базового класса ( DefWindowProc) и так далее. WinAPI даже берет номенклатуру из ООП SmallTalk, вызывая методы «сообщения» (Window Messages).

Дескрипторы не могут быть наследуемыми, но есть finalв Java. Им не хватает класса, они являются заполнителем для класса: вот что означает слово «ручка». Глядя на такие архитектуры, как MFC или .NET WinForms, сразу видно, что, кроме синтаксиса, ничто не сильно отличается от WinAPI.

11
23.08.2008 16:42:13
WINAPI это не ООП. Это просто показывает способ написания расширяемого процедурного кода. Хорошие методы хороши независимо от того, являются они ООП или нет. Я могу писать WINAPI-программы на C и использовать те же методы в своем собственном коде, поэтому я предполагаю, что C - ООП.
bruceatk 10.10.2008 12:38:27
Возможно, это не то, что имел в виду Алан Кей (Google!), Но, тем не менее, это ООП.
Konrad Rudolph 10.10.2008 20:32:54

Слишком часто класс используется просто для его синтаксического сахара; он помещает функции для типа записи в их собственное маленькое пространство имен.

Да, я нахожу это слишком распространенным. Это не объектно-ориентированное программирование. Это объектно-ориентированное программирование и ориентированное на данные программирование. За 10 лет работы с OO Languages ​​я вижу людей, которые в основном занимаются объектно-ориентированным программированием. OBP ломается очень быстро IMHO, так как вы получаете худшее из двух слов: 1) процедурное программирование без соблюдения проверенной методологии структурированного программирования и 2) ООП без соблюдения проверенной методологии ООП.

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

Большинство разработчиков, которые работают на языках ООП, используют примеры ООП, сделанные прямо в рамках и типах, которые они используют изо дня в день, но они просто не знают об этом. Вот несколько очень простых примеров: ADO.NET, Hibernate / NHibernate, Logging Frameworks, различные типы языковых коллекций, стек ASP.NET, стек JSP и т. Д. ... Все это в значительной степени зависит от ООП в их кодовых базах.

42
23.08.2008 16:42:45

Вы когда-нибудь создавали окно, используя WinAPI?

Больше раз, чем я хочу вспомнить.

Затем вы должны знать, что вы определяете класс (RegisterClass), создаете его экземпляр (CreateWindow), вызываете виртуальные методы (WndProc) и методы базового класса (DefWindowProc) и так далее. WinAPI даже берет номенклатуру из ООП SmallTalk, вызывая методы «сообщения» (Window Messages).

Тогда вы также узнаете, что он не отправляет сообщения самостоятельно, что является большой зияющей пустотой. У этого также есть дерьмовый подкласс.

Дескрипторы не могут быть наследуемыми, но в Java есть финал. Им не хватает класса, они являются заполнителем для класса: вот что означает слово «ручка». Глядя на такие архитектуры, как MFC или .NET WinForms, сразу видно, что, кроме синтаксиса, ничто не сильно отличается от WinAPI.

Они не наследуются ни по интерфейсу, ни по реализации, минимально заменяемы, и они существенно не отличаются от того, что процедурные кодеры делали с незапамятных времен.

Это действительно так? Лучшие биты ООП - это просто ... традиционный процедурный код? Это большое дело?

4
23.08.2008 17:13:26
Вы должны помнить, что интерфейс Win32 был в основном повторной реализацией Win16. Который был разработан более двух десятилетий назад.
Brad Gilbert 15.09.2008 16:20:27
Когда я учился программировать в колледже, в основном на C, но также и на некоторых других языках, нас учили некоторым базовым идеям и знакомили с несколькими платформами, но было понятно, что общая ответственность за разработку проектов, платформ, лучшие практики, и т.д. будет зависеть от нас на рабочем месте. Мы изучали техники, а не мировоззрения. С ОО вы должны изучить религию, прежде чем сможете сделать что-то полезное, и она полностью определяет, как вы видите решения. Я не думаю, что это действительно правильно.
user4624979 2.07.2015 18:03:09

ООП - это не создание повторно используемых классов, а создание классов Usable.

45
23.08.2008 18:04:49
Хороший! И так правда.
Toon Krijthe 28.09.2008 18:53:10
Справедливо. Но тогда это не решает проблему «изобретать колесо», которая, честно говоря, является серьезной в разработке программного обеспечения - вместо того, чтобы иметь одну библиотеку, которая имеет N пар глаз, ищущих недостатки, мы имеем N библиотек с парой глаз, которые делают так. Существует так много полезных классов, которые вы можете создать, прежде чем начинать их повторное использование. И ООП, по моему образованному мнению, в корне неверно именно в этой области - повторное использование кода. Он скрывает данные и «объединяет» их с методами, эффективно делая указанные данные недоступными или едва ли совместимыми.
amn 9.06.2013 10:35:51

В моем опыте анализа кода и разработки проектов, через который я прошел, ценность ООП не полностью осознана, потому что многие разработчики должным образом не концептуализировали объектно-ориентированную модель в своих умах. Таким образом, они не программируют с ОО-дизайном, очень часто продолжают писать процедурный код сверху вниз, что делает классы довольно плоским . (если вы можете даже назвать это "дизайн" в первую очередь)

Довольно страшно наблюдать, как маленькие коллеги знают о том, что такое абстрактный класс или интерфейс, не говоря уже о том, чтобы правильно спроектировать иерархию наследования в соответствии с потребностями бизнеса.

Однако, когда присутствует хороший дизайн ОО, просто радостно читать код и видеть, что код естественным образом превращается в интуитивные компоненты / классы. Я всегда воспринимал системную архитектуру и дизайн как проектирование различных отделов и рабочих мест в компании - все это для того, чтобы выполнить определенную часть работы в общей схеме вещей, испуская синергию, необходимую для продвижения организации / системы вперед.

Это, к сожалению , довольно редко . Как и соотношение красиво сконструированных и ужасно сконструированных физических объектов в мире, то же самое можно сказать о разработке программного обеспечения и проектировании. Наличие хороших инструментов в своем распоряжении не обязательно дает хорошие практики и результаты.

10
31.12.2008 02:43:30
Я никогда не достигал фазы радости процедурно или ООП при чтении кода. :)
bruceatk 10.10.2008 12:29:46
Просто радость, нет, но, может быть, маленькая улыбка?
Dan Rosenstark 31.12.2008 01:41:41

Может быть, капот, колени или дерево не стул, но все они ISittable.

9
25.08.2008 20:19:07
Вам никогда не приходилось использовать ОО-язык без интерфейсов? Ты счастливчик.
finnw 28.09.2008 19:27:57
Нет, это не так. Это вещи, которые не были предназначены для сидения, так что я думаю, что это соответствует аналогии, они не были бы написаны для реализации интерфейса ISittable. Они из сторонней библиотеки, и теперь, когда вы пишете проект, включающий домен, который включает в себя сидячее, вы обнаружите, что вам придется писать объекты-адаптеры, чтобы обернуть их, чтобы сделать их ISittable. Увидеть? Не очень похоже на реальный мир.
EricS 6.02.2014 22:47:48

Может быть, капот, колени или дерево не стул, но все они ISittable.

Да, но только ex post facto. Они ISittable, потому что кто-то сел на них.

1
27.08.2008 20:11:52
Обычно домен наивен и не полностью смоделирован. Хороший дизайн означает, что мы моделируем только то, что нам нужно. Поэтому нам нужно сидеть на стуле, коленях или дереве. Мы реализуем ISittable на этих классах.
Johnno Nolan 29.09.2008 11:17:12

Я знаю, что ООП полезен почти исключительно на синтаксической основе (инкапсуляция, перегрузка операторов, проверка типов). Что касается преимуществ ООП ... я не знаю. Я не думаю, что это хуже, чем процедурные вещи.

С другой стороны, мой лектор ООП сказал, что ООП важен, потому что в противном случае «код имел бы слишком много циклов». Да уж. Иногда удручает, что я плачу 500 долларов за бумагу. :(

1
29.08.2008 01:30:38
Я думаю, что он / она имел в виду "если", нет?
Dan Rosenstark 17.05.2009 18:04:41

Я полностью согласен с ответом Джеффа из InSciTek , просто добавлю следующие уточнения:

  • Сокрытие информации и инкапсуляция: критически важны для любого поддерживаемого кода. Это можно сделать, проявляя осторожность на любом языке программирования, не требуя OO-функций, но это сделает ваш код слегка OO-подобным.
  • Наследование: Существует одна важная прикладная область, для которой все эти ОО -типа являются своего рода и содержат- идеально подходят: графические пользовательские интерфейсы. Если вы попытаетесь создать графический интерфейс без поддержки языка OO, вы все равно будете создавать функции, подобные OO, и это будет сложнее и более подвержено ошибкам без поддержки языка. Поляна (недавно) и X11 Xt (исторически) например.

Использование OO-функций (особенно глубоко вложенных абстрактных иерархий), когда нет смысла, бессмысленно. Но для некоторых областей применения это действительно важно.

4
23.05.2017 12:25:33
Да, я думаю, что вы должны использовать ООП для объектов, функциональное программирование для функций ...
Svante 7.11.2008 04:51:40

Повторное использование не должно быть целью ООП - или любой другой парадигмы в этом отношении.

Повторное использование является побочным эффектом хорошего дизайна и надлежащего уровня абстракции. Код достигает повторного использования, делая что-то полезное, но не настолько, чтобы сделать его негибким. Неважно, является ли код ОО или нет - мы повторно используем то, что работает, и нетривиально делать это самим. Это прагматизм.

Мысль об ОО как о новом способе повторного использования посредством наследования в корне ошибочна. Как вы заметили, нарушений LSP предостаточно. Вместо этого ОО должным образом рассматривается как метод управления сложностью проблемной области. Целью является ремонтопригодность системы с течением времени. Основным инструментом для достижения этого является отделение открытого интерфейса от частного внедрения. Это позволяет нам иметь правила типа «Это должно быть изменено только с помощью ...», применяемые компилятором, а не проверку кода.

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

32
13.09.2008 00:14:21
верно, что повторное использование и ОО являются отдельными проблемами.
Dan Rosenstark 31.12.2008 01:39:51

Я считаю, что наиболее выгодным качеством ООП является скрытие / управление данными. Однако есть много примеров, когда ООП используется не по назначению, и я думаю, что именно здесь возникает путаница.

То, что вы можете превратить что-то в объект, не означает, что вы должны это делать. Однако, если это сделает ваш код более организованным / более простым для чтения, тогда вам определенно следует это сделать.

Отличный практический пример, где ООП очень полезен, - это класс «product» и объекты, которые я использую на нашем веб-сайте. Поскольку каждая страница является продуктом, а каждый продукт имеет ссылки на другие продукты, может возникнуть путаница в отношении того, к какому продукту относятся ваши данные. Является ли эта переменная "strURL" ссылкой на текущую страницу, домашнюю страницу или страницу статистики? Конечно, вы можете создать различные переменные, которые ссылаются на одну и ту же информацию, но proCurrentPage-> strURL гораздо проще понять (для разработчика).

Кроме того, прикрепление функций к этим страницам намного чище. Я могу сделать proCurrentPage-> CleanCache (); Вслед за proDisplayItem-> RenderPromo (); Если бы я просто вызвал эти функции и предположил, что текущие данные были доступны, кто знает, какое зло произойдет. Кроме того, если бы мне пришлось передать правильные переменные в эти функции, я бы вернулся к проблеме наличия всех видов переменных для различных продуктов, лежащих вокруг.

Вместо этого, используя объекты, все данные и функции моего продукта приятны, понятны и просты для понимания.

Однако. Большая проблема с ООП - это когда кто-то считает, что ВСЕ должно быть ООП. Это создает много проблем. У меня есть 88 таблиц в моей базе данных. У меня всего около 6 классов, и, может быть, мне нужно около 10. Мне определенно не нужно 88 классов. Большую часть времени прямой доступ к этим таблицам совершенно понятен в тех обстоятельствах, которые я им использую, и ООП фактически затруднит / утомителен, чтобы добраться до основной функциональности происходящего.

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

4
15.09.2008 21:27:39

Да, ООП не решил всех наших проблем, извините за это. Однако мы работаем над SOA, которая решит все эти проблемы.

11
17.09.2008 04:59:06
Разве ты не слышал? SOA это прошлое. Сегодня это облачные вычисления, которые будут нашим спасителем.
DrPizza 17.09.2008 09:59:47
Мне действительно интересно, если ваши ответы ироничны или нет. Мне нравится ирония, но обычно ее снимают, это заставляет меня задуматься ...
Lena Schimmel 6.03.2009 02:03:06
Я думаю, что это иронично, и я не буду голосовать за это. Но я тоже не буду голосовать! :-)
Yarik 26.05.2009 15:21:55
Вопрос довольно риторический, так что это правильный ответ (и лучший ответ).
Jeff Davis 30.07.2010 14:51:52

«Реальный мир - это не« ОО »»

В самом деле? Мой мир полон объектов. Я использую один сейчас. Я думаю, что наличие программных «объектов» моделирует реальные объекты не так уж плохо.

ОО-проекты для концептуальных вещей (таких как Windows, не окна реального мира, а панели дисплея на мониторе моего компьютера) часто оставляют желать лучшего. Но для реальных вещей, таких как счета-фактуры, заказы на доставку, страховые претензии и тому подобное, я думаю, что эти вещи в реальном мире являются объектами. У меня на столе стопка, поэтому они должны быть настоящими.

2
1.10.2008 08:08:59

Я думаю, что эти вещи реального мира являются объектами

Ты сделаешь?

Какие методы есть в счете? Ой, подожди. Он не может заплатить сам, он не может отправить себя, он не может сравнивать себя с товарами, которые поставщик фактически поставил. У него нет никаких методов вообще; это абсолютно инертно и не функционально. Это тип записи (структура, если хотите), а не объект.

Также и другие вещи, которые вы упоминаете.

То, что что-то реально, не делает его объектом в ОО-смысле этого слова. ОО-объекты - это своеобразная связь состояния и поведения, которая может действовать самостоятельно. Это не то, что в изобилии в реальном мире.

8
2.10.2008 08:31:38
Возьмите любую машину, электронное устройство или живое существо, все это «связь состояния и поведения».
TM. 7.11.2008 04:34:44
Я согласен, что такие методы, как Send () или Pay (), являются «неестественными» для счетов. Но, например, как насчет общей суммы в качестве производного, но врожденного атрибута счета? Разве это не пример того, что ООП позволяет моделировать очень «естественным» образом даже для полностью инертных реальных объектов? Не большое достижение само по себе, но все же ...
Yarik 26.05.2009 15:36:31
@Yarik: эти "инертные" сущности приводят к объектно-ориентированному дизайну. Для меня единственное правильное ОО - это симуляция, где объекты «могут действовать сами по себе» , как говорится в этом ответе. Если ОО является единственным подходящим способом достижения чего-либо, хорошо, но в противном случае мы не можем придерживаться чего-то более простого и более похожего на решаемую проблему?
user4624979 1.07.2015 14:56:50

Для меня ценность ООП состоит в том, чтобы уменьшить область и отделить состояние от поведения. С меньшей областью код легче понять.

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

Поскольку набор классов эффективно моделирует домен, магического метода не существует. Как пианино, мы должны практиковаться. ООП - это абстрактный инструмент, он может помочь вам создавать код более простым способом, но он не может думать и анализировать область вашего приложения для вас.

Что мне подходит, так это как можно дольше оставаться рядом с доменом, при этом избегая дублирования кода.

1
23.10.2008 15:58:49

ООП хорошо подходит для программирования внутренних компьютерных структур, таких как «виджеты» GUI, где, например, SelectList и TextBox могут быть подтипами Item, которые имеют общие методы, такие как «перемещение» и «изменение размера».

Проблема в том, что 90% из нас работают в мире бизнеса, где мы работаем с такими бизнес-концепциями, как Счет, Сотрудник, Работа, Заказ. Они не очень хорошо подходят для ООП, потому что «объекты» более туманные, подверженные изменениям в соответствии с реинжинирингом бизнеса и так далее.

В худшем случае ОО с энтузиазмом применяется к базам данных, включая вопиющие «усовершенствования» ОО к базам данных SQL, которые по праву игнорируются, за исключением тех, кто использует базы данных, которые считают, что они должны быть правильным способом, потому что они новее.

10
23.10.2008 16:12:15
Это все верно, но ... возможно, тот факт, что ООП может упростить НЕКОТОРЫЕ не связанные с бизнесом аспекты приложения (например, реализацию пользовательского интерфейса), является как раз одной из главных причин, почему разработчик (наконец-то!) Может тратить больше времени на работу в бизнесе. аспекты?
Yarik 26.05.2009 15:43:01