как надо проектировать ООП программы?

отдельно рекомендую глянуть на 0131489062, весьма сильная вещь, с упором на практику

Это как?

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

Собственно, ты и сам ответил на свой вопрос в цитате про сцепление и связанность.

Проблема хорошо известная и изученная. Заключается она в плохой управляемости и расширяемости кода (англ. maintainability и extensibility - важнейшие из NFR). Причинами, как правило, являются следующее:

1. Некачественная ОО-модель;
2. Неадекватная декомпозиция;
3. Высокая связность и низкое зацепление (tight coupling & low cohesion);
4. Применение неадекватных для ООП подходов и неприменение адекватных.

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

1. Поменьше увлекаться религиозной литературой (SICP, HtDP). Эти книги не решают ни одной вышеописанной проблемы или нижеописанной задачи, следовательно - нерелевантны. В основном из советуют маргиналы, неадекваты, фанатики и пустомели; данный тред - не исключение. Интерес эти книги могут представлять исключительно исторический: подивиться, какими причудливыми путями шло развитие computer science, и какие тупиковые его ветви не дожили до наших времен;
2. Прислушаться к сообщениям Reaper (это) и iZEN (вот это). Последний, хоть чаще всего и бывает капитально упорот, в данном случае исключительно прав;
3. Учиться проводить грамотную декомпозицию. Задача эта очень глубокая и комплексная и, вообще говоря, уже относится к архитекторской компетенции. Обычно выделяют 16 стратегий декомпозиции, объединенных в 5 групп. Я не буду их перечислять здесь ради экономии места. Если интересно, напишите, и мы сможем их обсудить;
4. Пользоваться современными инструментами для рефакторинга. Разумеется, вероятность того, что вы проводите рефакторинг вручную, весьма мала; но я не поленюсь напомнить, что инструменты, подобные IDEA, NetBeans или Eclispe, выполнят бОльшую часть работы за вас;
5. Показать хотя бы часть кода, которая, по вашему мнению, наиболее красноречиво описывает ваши проблемы. Вдруг окажется, что, обчитавшись SICP, вы теперь везде используете классы-функторы и рекурсию вместо итерации. Будет здорово, если вы выложите не код, но и UML-диаграммы, полученные путем reverse engineering. Это позволит сократить нам время на анализ и избежать проблем с вашими работодателями и интеллектуальной собственностью, если код проприетарный и выкладывать его нельзя.

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

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

> И, возможно, как раз СИКП-то автору и нужен. Просто он об этом ещё не знает

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

Собственно, я это к тому, что от вашего сообщения так и веет идеологией и религией. «Все программисты - лисперы, просто еще не все достигли должного просветления.»

Это у тебя профессиональная деформация личности такая. Сначала ты ходишь гадить в ФП-треды, а потом тебе начинает мерещиться лиспопропаганда там, где её и в помине нету.

[..] UML. Участники дискуссии незаслуженно забыли об этом инструменте, который предназначен аккурат для того, о чем спрашивает ОП - для проектирования.

для проектирования предназначена голова, UML нужен для документирования проектных решений

PS ради справделивости стоит отметить, что часто применение UML ту голову на правильные рельсы может поставить или подсказать решение, но «golova is must»

> «golova is a must»
fixed

> для проектирования предназначена голова, UML нужен для документирования проектных решений

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

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

применение UML ту голову на правильные рельсы может поставить или подсказать решение, но «golova is must»

Ну, а я о чем? Я и советую ТСу повышать обазование, развивать собственную думалку, эрудицию и опыт. А мнения разнообразных советчиков (в том числе и нас с вами) - пропускать через призму вышеописанного :)

а вы пишете на эйфеле? серьезно? или на википедии прочитали и прониклись?

> применение UML ту голову на правильные рельсы может поставить или подсказать решение, но «golova is must»

Ну, а я о чем? Я и советую ТСу повышать обазование, развивать собственную думалку, эрудицию и опыт.

я просто на всякий случай, для ТС, уточнил момент, чтобы не возникало ощущения что использование UML может что-то порешать само по себе :)

а так - конечно согласен

> Сначала ты ходишь гадить в ФП-треды

Для вас высказывание взвешенного, критического мнения - это «гадить»? Негативно-болезненное восприятие объективной критики присуще участникам религиозным течений и еще раз подчеркивает природу массового увлечения ФП.

тебе начинает мерещиться лиспопропаганда там, где её и в помине нету.

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

accepted :)

> использование UML может что-то порешать само по себе :)

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

Можно почитать книги по проектированию опп приложений,
например Гради Буч «Объектно-ориентированный анализ и проектирование»
возможно посмотреть лекции по теме: «Технология программирования» .

Можно почитать книги по проектированию опп приложений,

например Гради Буч «Объектно-ориентированный анализ и проектирование».

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

>Простите, а чем тогда являются вбросы о SICP чуть ли не в каждый тред о проектировании, теории ООП, архитектуре и построении программных систем?

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

>Простите, а чем тогда являются вбросы о SICP чуть ли не в каждый тред о проектировании, теории ООП, архитектуре и построении программных систем?

Напоминанием об основах.

а Вы не думали, что такое напоминание в 90% случаев никому не нужно и никак не помогает в решении вопроса ТС?

>У меня, наверное, обычная проблема кодера - проблема в написании больших программ. Как только объем проекта превышает 1000 строк, я перестаю в нем ориентироваться.

Ну, у меня в ядре фреймворка сейчас более 55 тыс. строк. И в типовых проектах на нём по 10…40 тыс. строк. И я свободно ориентируюсь в них даже без всяких IDE.

Нужно просто максимально унифицировать системы именования классов, их интерфейсы, основные принципы. Предельная инкапсуляция — обязательна. Чтобы, описывая ту или иную логику вообще почти не задумываться, какой из возможных объектов будет обрабатываться.

смотрел код некоторых open-source проектов - там код часто ужасен

Это скорее правило, чем исключение.

Как быть? Как правильно проектировать ООП программы?

Ну, я просто свой подход для себя выводил через написание десятков раз с нуля типовых задач на разных платформах, от Си++ и Форта до PHP и Java. При каждом новом написании обращаешь внимание на вещи, которые пишешь быстро и незадумываясь и на те, которые вызывают тормоза, раздумья и пересмотры принципов в новых проектах. Первое стоит за собой поощрять, для второго — искать альтернативные подходы.

В последние лет 6 работаю исключительно с одним своим продуктом, но это не мешает использовать тот же подход и внутри него. Начинаешь новый проект на нём — то, что делается быстро и легко, выходит, сделано правильно. Делаешь ошибки или тормозишь где-то — нужно переписывать. В следующем проекте уже может прижиться сразу :)

Для вас высказывание взвешенного, критического мнения

Боюсь, ты слишком высокого о себе мнения.

массового увлечения ФП.

Кто сказал ФП? Ты сказал ФП. Как баба: сама придумал, сама обиделась.

вбросы о SICP

Для альтернативно одарённых сообщаю, СИКП не учебник лисп, СИКП учебник по проектированию, архитектуре и построении программных систем.

СИКП учебник по проектированию, архитектуре и построении программных систем

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

> А ООП - это не более, чем умеренно кривой способ эту программу записать.

А ФП — полагаю, более прямой способ? А какова мера кривизны? Как её измерить, например, в радианах?

> СИКП не учебник лисп, СИКП учебник по проектированию, архитектуре и построении программных систем.

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

В 95% топикстартер не просто забыл об основах, а никогда их не знал, поэтому таки да 'напоминание' ему не нужно, ему нужен посыл читать основы в букваре.

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

Прочитал по диагонали обсуждения ... Хмм, я бы только 3 совета дал:

1. Пойми чего хочешь — составь ПОДРОБНЫЙ список того, что от программы/проекта нужно.

2. Разделяй и властвуй — разбей список задач на МАКСИМАЛЬНО МЕЛКИЕ куски. Продумай связи между кусками — однородные куски можно объеденить в классы. Вынеси все переменные в классы (глобальных переменных быть почти не должно — легко в них запутаться). Постарайся сделать классы и блоки кода (функции) небольшими — идеально не более 1-2 экранов на класс/функцию — все более длинное сложно вспоминать, отлаживать и менять.

Ну и компонуй схожие функции в отдельный файл: отдельные файлы для описания классов, один файл для обработки сообщений, один файл для I/O, один файл для обработки данных и т.д. Хорошо бы если каждый файл не будет превышать 1000 строк (не более 20-30 функций внутри файла).

3. Документируй все — старайся называть классы/функции читаемыми именами (все одно-,двухбуквенные переменные — локальные,временные); старайся к КАЖДОЙ функции,переменной,классу написать хотя бы строчку ОСМЫСЛЕННОГО комментария (что именно она делает); старайся комментировать каждое условие,цикл или каждые 10 строчек кода. Еще лучше если можешь написать некий текст-инструкцию ... Да сложно,лень,отвлекает и т.д., но уже через полгода-год скажешь себе за это спасибо!

Пункт 3 нужен, что бы не забыть что же тут делалось и поддерживать проект. Пункт 2 нужен для отладки/оптимизации — ошибки в маленькой функции менее вероятны, да и переписать/оптимизировать ее проще. А пункт 1 нужен, что бы не уйти слишком далеко в сторону и не забыть важную фичу :).

Вот и вся архитектура.

Используя эти 3 простых принципа я до сих пор считаю (да и рисую) кодами написанными много лет назад (самые старые — 11 и 8 лет, а другим 6 и меньше).

У тебя прогрессирующий фаулер головного мозга. Это грустно, но не смертельно. Терапия очевидна

Для меня - не очевидна. Назовите, пожалуйста.

Будь добр, обоснуй своё мнение.

1) Закопать фаулера и остальных вышеперечисленных в землю. Хотя бы временно.

2) Забить болт на вопросы большой и красивой «архитектуры». Руководствоваться принципом минимальной достаточности.

3) После нескольких релизов старичка фаулера можно, пожалуй, и выкопать. Если в нем будет какой-нибудь толк.

уже обосновывал в этом треде не раз, но повторить не жалко

SICP - это как ветхий завет - не убий, не укради... но что делать с мусульманами и хакерами? нужен УПК и коран, как минимум :)

> Как правильно проектировать ООП программы?

http://ru.wikipedia.org/wiki/Парадигма_программирования

Может показаться, что ТС спрашивает о
http://ru.wikipedia.org/wiki/Компонентно-ориентированное_программирование

Но скорее всего ТС-у нужно ознакомиться с
http://ru.wikipedia.org/wiki/Субъектно-ориентированное_программирование
и
http://ru.wikipedia.org/wiki/Аспектно-ориентированное_программирование

Выбор конкретного подхода (или нескольких) может сильно зависеть от личных наклонностей и предпочтений ТС-а.

> Но, пожалуй, самая важная рекомендация - осваивать и использовать UML.

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

Вот давай не будем путать «основы проектирования программ» и «как написать музыкальный плеер на питон за 24 часа».

Да-да, зачем писать за сутки то, что можно писать всю жизнь? CL для сильных духом!

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

Вот давай не будем путать «основы проектирования программ» и «как написать музыкальный плеер на питон за 24 часа».

я тебе об этом уже второй день твержу

Зато нет надежды, что ты когда-нибудь поймешь, что аналогиями можно «доказать» что угодно.

Не путай иллюстрацию с доказательством.

Подобным образом «проиллюстрировать» можно любое лживое утверждение. Ценность такой иллюстрации отрицательна.

Зануда.