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

Имея

Книги читал. Фаулер, Бек, SICP, HTDP, Макконел, Эккель, Хорстман и прочие. Понимаю , как надо делать правильно.

Пишу каждый день уже несколько лет.

Странно, что получаем

Как только объем проекта превышает 1000 строк, я перестаю в нем ориентироваться.

Может, стоит ещё раз перечитать?

SICP, HTDP, и несколько книг Кента Бека перечитывал буквально месяц назад. Периодически перечитываю главы Макконела.
Не помогает.

Приходило еще в голову - грызть матан, для общего просветления в мозгах

Я не дочитал SICP (остановился где-то в начале); HTDP, Макконела, Эккеля, Хорстмана, Фаулера - вообще не читал; у Бека - только одну маленькую книжечку, и то про смолток. Описанных проблем не испытываю, по ночам сплю нормально, в своём коде ориентируюсь. ЧЯДНТ?

Вы все так делаете. Вопрос в другом - что _я_ не так делаю :)

Примерно та же фигня. Если я сейчас открою код полугодичной давности своего GrabVK - хрен я там что пойму, потому что весь код навален в кучу. А все от чего? Потому что когда пишу, стараюсь не сделать код правильным, а нафигачить абы как, но чтоб работала нужная фича. Теперь вот придется переписывать с нуля, используя какие-то старые наработки, но пытаясь сделать код грамотным.

Фаулер, Бек, SICP, HTDP, Макконел, Эккель, Хорстман

чувак, у тебя здесь половина книг вообще не о том, типа того Эккеля и SICP, ну и особенно, конечно пугает:

и прочие

почитай «Чистый код» Роберта Мартина, весьма недурственная книга, как мне кажется она лучше пойдёт, нежели многие из данного списка

Как только объем проекта превышает 1000 строк, я перестаю в нем ориентироваться.

правило номер 1: анализируй, нужно научиться выявлять, что именно мешает тебе ориентироваться

В итоге само приложение со временем начинает походить на кучу говна.

и это нормально, в какой то момент всё равно текущая архитектура перестаёт удовлетворять потребностям

правило номер 2: не пиши проект заново - делай рефакторинг

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

правило номер 3: дрессируй себя, доводи работу до конца

но иногда и полезно оставить ненадолго проект, отдохнуть, если код работает корректно конечно

смотрел код некоторых open-source проектов - там код часто ужасен, но архитектура приложения нередко очень хороша, на недосягаемом для меня сейчас уровне

правило номер 4: анализируй решения, которые кажутся тебе красивыми и правильными, пробуй делать так в своих проектах

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

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

SICP, HTDP, и несколько книг Кента Бека перечитывал буквально месяц назад. Периодически перечитываю главы Макконела. Не помогает.

запомни чувак - волк жиреет своим собственным жиром, а не жиром баранов, которых он съел

книжки - это хорошо, но зачем их перечитывать то? от перечитывания твоё кунг-фу не улучшится :)

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

Я не дочитал SICP (остановился где-то в начале); HTDP, Макконела, Эккеля, Хорстмана, Фаулера - вообще не читал; у Бека - только одну маленькую книжечку, и то про смолток. Описанных проблем не испытываю, по ночам сплю нормально, в своём коде ориентируюсь. ЧЯДНТ?

Вы все так делаете. Вопрос в другом - что _я_ не так делаю :)

сам же написал:

Книги читал. Фаулер, Бек, SICP, HTDP, Макконел, Эккель, Хорстман и прочие. [..] SICP, HTDP, и несколько книг Кента Бека перечитывал буквально месяц назад. Периодически перечитываю главы Макконела.

Читал пока учился в университете для общего образования. И в последнее время - для решения описанных выше проблем. Опыт именно в регулярном написании кода уже около 5 лет (большая часть этого опыта - работа)

Книги перечитывал - после возникновения проблем. А не до.

Бессмыслица. То ли троллинг, то ли нытик-тред.

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

Если это правда, то это круто. Значит ты работаешь для души, а не на Дядю. А Дядя тебе за это ещё и деньги платит. Куча начатого и брошенного кода, это не каждый работодатель может себе позволить.

p.s. смотрел код некоторых open-source проектов - там код часто ужасен, но архитектура приложения нередко очень хороша, на недосягаемом для меня сейчас уровне.

Ух ты блин. Годно.

«Чистый код» я читал.

тогда пора применять на практике всё что ты читал

SICP часто советуют в подобных темах

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

Эккель все-таки тоже пишет про разработку ООП-программ (пишу в основном на java).

про Java не знаю, но по С++ книжки у него слабенькие

Работаю и для души (те самые брошенные проекты) и «на дядю».
Если вам так проще - рассматривайте это как «нытик-тред».

На практике применяю и давно. Но получается говно, а не чистый код.

Опыт именно в регулярном написании кода уже около 5 лет (большая часть этого опыта - работа)

ок, ну значит ты дозрел до следующего уровня :)

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

мне, кстати, в своё время помог фриланс, как бы это смешно не звучало, то есть проект за который я отвечал от начал и до конца, проект который я проектировал, и разрабатывал, и лет 5-6 в одно лицо поддерживал и развивал

На практике применяю и давно. Но получается говно, а не чистый код.

почему? что не устраивает?

рассматривайте это как «нытик-тред».

Если тема посвящена вопросу: «Что я делаю не так?!!», то может немного поделитесь с нами, как вы разрабатываете программы, как продумываете архитектуру, какие удачные/неудачные решения у вас были? Ну хоть что-то сможете рассказать?

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

программируй на уровне интерфейсов, предпочитай композицию наследованию

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

Рецепт один - не ленитесь думать над архитектурой и дизайном.

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

при чем тут SICP?

Есть код на показать? Быть может у тебя перфекционизм головного мозга?

У тебя не с кодированием проблема, а с планированием. Читай всякие там «getting things done» - это намного полезнее SICP-ов с Фаулерами.

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

при чем тут SICP?

да ни при чём, а лавсанчика это я так, к слову вспомнил :)

если хотите читайте цитату так:

<whatever> часто советуют в подобных темах

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

Спасибо, пришел к тому же мнению.

надо использовать Lisp

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

вместо перечитывания лучше освой eiffel, чтобы написать на нем плохо спроектированное приложение, нужно сильно постараться.

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

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

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

спасибо за уточнение Кэп :)

вообще то я осилил SICP, и моя оценка - ТС там ничего для себя, релевантного описанной ситуации, не найдёт

А хрен его знает. Мысль человеческая имеет обыкновение блуждать странными путями. И, возможно, как раз СИКП-то автору и нужен. Просто он об этом ещё не знает и думает будто он хочет проектировать ООП-программы.

В корпоративном софте обычно все достаточно примитивно: есть замепленные сущности, есть абстракций хранилища, есть кучка сервисов, есть контроллеры с вьюхами, которые все это добро выставляют наружу. Этого не хитрого шаблона хватает на 90% всех проектов. Собственно никакой архитектурной проблемы обычно и нет. Нет ее скорее всего и у тебя, особенно учитывая:

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

Мне в свое время помогло ОСОЗНАНИЕ того, что нужно всегда идти от задачи. То есть перед тем, как что-то менять в коде задумывать - а что вообще нужно сделать? Может вообще я иду не в том направлении? Обычно хорошо продуманная и ПОНЯТАЯ тобой задача очень красиво и гладко реализуется в коде. Каждый раз, когда код начинает попахивать, лично для меня это сигнал того, что я плохо понимаю задачу.

До продумывания архитектуры - какие сущности нужны, как они будут взаимодействовать, я сначала делаю определённые подготовительные действия и всегда придерживаюсь трёх простых принципов:

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

Самo начало создания чего-то выглядит так:

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

• построить роботов
• убить всех людей
• роботов - на переплавку

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

class Unit
  # внешний интерфейс
  constructor: (@name) -> 
  startGenocide: ->

    # последовательность действий    
    buildArmy: -> 
    killAllHumans: ->
    meltArmy: ->


# в каком виде оно будет использоваться
army = new Unit "Che Guevarazz"
army.startGenocide()

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

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

Несмотря на то, что опыт, как правило, осечек не даёт в плане правильности определения необходимости создания данного функционала («потребуется строить роботов»), если начинать с деталей, не продумав общее, за деревьями часто лес перестаёшь видеть. Начинаются рефакторинги, из##бы с архитектурой, тонны кода без каментов и как результат - каша.

и кого же Вы порекомендуете по плюсам?

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

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

Если я сейчас открою код полугодичной давности своего GrabVK - хрен я там что пойму, потому что весь код навален в кучу. А все от чего? Потому что когда пишу, стараюсь не сделать код правильным, а нафигачить абы как, но чтоб работала нужная фича.

А эта самая «нужная фича» как-то задокументирована или просто отложена в памяти, как «нужная»? Каждая реализованная/востребованная фича должа каким-то образом быть чётко определена в самом коде (самодокументирующийся код?), в функциональном тесте (который проверяет её на правильность понимания и реализации), в документации к программе (предполагается, что фича работает чётко определённым образом).

Когда число особенностей программы переваливает за определённый порог удержания в человеческой памяти, а тестов никаких нет и документация слабая, вот тут наступает развязка: старый код без документирования можно выбросить, так как поддерживать его не имеет смысла. Здесь дело не в том, что он не работает, но его изменение сможет в любой момент сделать его таковым.

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

По рефакторингу унаследованного кода почитай книжки Мартина Фаулера и Майкла Физерса.

А вот еще реальный совет: попроси кого-нибудь поревьюить. Я вобщем-то так и научился писать. Своим кодом доволен процентов на 90.

Спасибо! Полезный комментарий.

По результатам обсуждения сделал для себя такие выводы:

1. организовывать текущие задачи по типу GTD
2. сильно декомпозировать задачу
3. проектировать сверху-вниз
4. выполнение работ организовывать от поставленной задачи
5. перепроектирование разрабатываемого проекта - вполне обычное дело и не стоит этого бояться.
6. работать-работать-работать до просветления :)

Нихрена там не задукоментировано. Там вообще ярый быдлокод, но зато работает =) И комментариев нет. Так что один черт переписывать, но уже более грамотно продумать структуру классов и прочего, благо помню местами, что да как.

гуманно так :)

День DejaVu на ЛОРе? [JAVA] Как научиться правильно писать?

И внутри модулей отдельные части делать так, чтобы они имели минимальную связанность.

Это как?

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

Сцепление (cohesion) — это мера сфокусированности класса на своих задачах. В лучшем случае класс должен иметь лишь одну задачу (см. принцип единственной ответственности http://blog.evseev.ru/2009/11/single-responsibility-principle.html ). Сцепление, в отличии от связности, характеризует отдельный класс и не касается его окружения. При большом сцеплении код получается более читабельным и простым для повторного использования.

Связность (coupling, или зависимость dependency) — мера зависимости между классами или модулями. При слабой связности модули взаимодействуют через устойчивый интерфейс и не зависят от реализации друг друга. При высокой связности проявляются проблемы следующего плана:

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

Связность является объективной величиной, ее можно вычислить и зависит от таких параметров как количество используемых глобальных переменных, количество передаваемых параметров и т.п. Величина связности изменяется от 0 до 1. При нулевой связности модули не взаимодействуют вовсе.

http://blog.evseev.ru/2009/11/high-cohesion-low-coupling.html

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

вот тут написано:
0596008678 Head.First.Object.Oriented.Analysis.and.Design.pdf
0596007124 Head.First.Design.Patterns
0596527357 Head.First.Software.Development.2007.pdf
0321125215 Domain.Driven.Design-Tacking.Complexity.in.the.Heart.of.Software.pdf
Предметно-ориентированное Проектирование СТРУКТУРИ3АЦИЯ СЛОЖНЫХ ПРОГРАММНЫХ СИСТЕМ '«Эта книга должна стоять на полке у каждого мыслящего программиста». - Кент Бек (KentBeck)'
0131489062 An Introduction to Object-Oriented Analysis and Design and Iterative Development, By Craig Larman

Что пишешь-то?

за 0321125215 отдельное спасибо, почитаю

> Что пишешь-то?

Код. По работе - обычные корпоративные задачи.

и кого же Вы порекомендуете по плюсам?

зависит от задачи и уровня

возможно, как раз СИКП-то автору и нужен

он сказал что читал его уже, тут вопрос какой SICP даёт общий подход и его целесообразно использовать для общего понимания концепций, то есть чтобы в тему врубаться, ТС же говорит, что он в теме