LINUX.ORG.RU

[ООП] Как использовать на практике?

 


1

1

Я изучил общие положения ООП(наследование, инкапсуляция, полиморфизм), но так и не понял как использовать его на практике. Может быть, кто-нибудь посоветует статьи, книги, код open-source проектов?

★★

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

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

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

Даа, вы тут щас насоветуете ТСу.

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

Ага, ок. Приложение, разработанное с использованием ООП.

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

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

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

программа - это не инженерная конструкция, которую спроектировал - и дальше она не меняется

писать код надо, а ООП само вылезет

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

Спасибо, Кэп. Эта беда в любом случае возникнет. Ни одна парадигма не поможет её решить.

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

ООП-приложение сначала надо тщательно спроектировать, прежде чем писать.

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

Это лишь говорит о низком качестве анализа предметной области. Одним из критериев хорошей архитектуры является то, что небольшие изменения в требованиях приводят к небольшим же изменениям в коде. Достигается это свойство (в том числе) путем обеспечения high cohesion & low coupling, на этапе анализа и проектирования.

писать код надо, а ООП само вылезет

При таком подходе вылезет пирамида из костылей и подпорок, а не ООП.

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

Это лишь говорит о низком качестве анализа предметной области. Одним из критериев хорошей архитектуры является то, что небольшие изменения в требованиях приводят к небольшим же изменениям в коде. Достигается это свойство (в том числе) путем обеспечения high cohesion & low coupling, на этапе анализа и проектирования.

Не взлетит. Программирование — это непрерывный процесс, в котором чередуются фазы «глаза боятся, а руки делают» и «семь раз отмерь, один раз отрежь». Ты всё время говоришь о второй фазе, но без первой ты никуда дальше бумажно-теоретической диаграммы классов не уедешь.

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

Программирование — это непрерывный процесс, в котором чередуются фазы

Спасибо, кэп.

Ты всё время говоришь о второй фазе

Потому что именно с этого конца нужно браться за ООП.

Не взлетит. ты никуда дальше бумажно-теоретической диаграммы классов не уедешь.

Ничего, что мои программы крутятся на продакшн серверах по всему миру?

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

Потому что именно с этого конца нужно браться за ООП.

У тебя феерическая какая-то каша в голове. За проектирование вменяемой архитектуры надо браться в начале любого проекта, вне зависимости от использумых парадигм. При чем тут ООП вообще? До Смолтолка и Симулы программы на деревьях росли что ли?

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

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

Даа, вы тут щас насоветуете ТСу.

Я, кстати, тоже только изучаю ООП. Читаю сейчас этого Буча. Что с ним не так?

power
()
Ответ на: комментарий от geekless

У тебя феерическая какая-то каша в голове. За проектирование вменяемой архитектуры надо браться в начале любого проекта, вне зависимости от использумых парадигм. При чем тут ООП вообще?

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

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

писать код надо, а ООП само вылезет

говнокод в итоге выйдет

архитектуру сначала обдумывают
потом ее заворачивают в прадигмы ООП
а потом уже каждый компомент архитектуры можно раздать на программистов-разработчиков которые и будут кодить

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

говнокод в итоге выйдет

про рефакторинг анонимус не слышал, про экстремальное программирование не читал

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