Здравствуйте, Artifact, Вы писали:
A>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания.
Это все потому, что единственной парадигмой программирования, которая обеспечивает читаемость программы, является не ООП и не ФП и не другое хП, а прямые руки и светлая голова программиста. А это приходит только с опытом. А уж на плюсах, лиспе или джаве он будет писать — дело десятое.
Здравствуйте, 0x7be, Вы писали:
0>Это все потому, что единственной парадигмой программирования, которая обеспечивает читаемость программы, является не ООП и не ФП и не другое хП, а прямые руки и светлая голова программиста.
Для этого тоже существует аббревиатура — BDD (Brain Driven Development).
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Enomay, Вы писали:
Не сработало разделение. В случае наследования — не сработало обобщение. В случае паттернов вообще молчу.
E>какой-то совершенно непонятный поток сознания. E>вы б хоть по пунктам с примерами.
Осталось только определится с критерием понятного потока сознания. А вот с этим как раз большие проблемы. Даже если мы предположим что смена интерфейса (объекта, функции и т.п.) символизирует о нарушении в каком-то смысле задачи инкапсуляции, то как нам это измерить? Тем более что последний интерфейс вполне выполняет свою задачу, иначе нафига его оставили?
Только давайте без разговоров о правильном сознании, правильных программистах, правильном выборе интерфейса и правильных объектах, а также противопоставление всего этого программистам сомневающимся в ООП. Чего-то ООП не хватает, знать бы чего?
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, Artifact, Вы писали:
T>Да, да, во всем виновато ООП, а вовсе не кривые руки!
Привет пряморуким, осталось выяснить у кого руки прямее. Давайте организуем конкурс, каждый будет оценивать кривость своих рук, ведь понятно что у всех остальных руки кривее чем у себя любимого. Или можно пройти тест, если через месяц программирования вас посещала мысль что нужно было программировать совсем не так то можете себя поздравить — у вас кривые руки
Здравствуйте, Artifact, Вы писали:
A>Что-то нетак с ООП
А с жизнью разве так? Смотрите, все в течение жизни болеют, маются всякими проблемами, а итог — помирають.
Сам посыл абсурден — куча ПО написано и работает как раз с использованием ООП, но вдруг с ним что-то не так.
А с чем извините все так? С ФП? И много на нем написано работающего годами ПО?
А может с логическим программированием все замечательно?
Что у нас еще есть — структурное? Да, ядро Linux — известная вещь.
Но с ним как, с структурным программированием — все так, все замечательно?
Присоединяюсь же к ответам в теме — проектировать нужно вначале. На чем бы потом ни кодировал.
А тяп — ляп — никакой подход программирования не простит.
Когда нужно больше чем вывести в консоль "Hello world!"
Здравствуйте, IT, Вы писали:
0>>Это все потому, что единственной парадигмой программирования, которая обеспечивает читаемость программы, является не ООП и не ФП и не другое хП, а прямые руки и светлая голова программиста.
IT>Для этого тоже существует аббревиатура — BDD (Brain Driven Development).
Если это и так, то расшифровка как Behavior Driven Development сейчас более популярна.
Надо заменить.
Здравствуйте, Son of Northern Darkness, Вы писали:
SON>Здравствуйте, Artifact, Вы писали:
A>>И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?
SON>Это не правда. Хороший код, это код в который можно расширить, не переделывая уже сделанную работу или переделывая минимально. SON>Вот за этим ООП и нужно.
Не то что бы не правда. Просто устарело. Новые задачи требуют нового подхода.
Здравствуйте, netch80, Вы писали:
IT>>Для этого тоже существует аббревиатура — BDD (Brain Driven Development).
N>Если это и так, то расшифровка как Behavior Driven Development сейчас более популярна. N>Надо заменить.
Это временное недоразумение.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, LaptevVV, Вы писали:
LVV>Однако некоторые языки (Додиез и Ява, например) программу сразу считают неким классом. И тут легко скатиться от ясных и понятных процессов в полную неразбериху объектов... Инструмент как бы провоцирует...
Та а чем процедуры и функции не классы. Если в голове порядок, то классы сами организуются. Если в этом имеется смысл. у ООП единственный недостаток это жесткое наследование класс-объект. Чуть отличия у объекта так требуется новый класс, что не всегда разумно с предметной точки зрения. ИМХО, конечно.
V>Осталось только определится с критерием понятного потока сознания. А вот с этим как раз большие проблемы. Даже если мы предположим что смена интерфейса (объекта, функции и т.п.) символизирует о нарушении в каком-то смысле задачи инкапсуляции, то как нам это измерить?
а с чего вы взяли что смена интерфейса каким-то образом нарушает инкапусуляцию? реализация алгоритмов и внутренние способы представления данных как были так и остались скрыты от внешних глаз.
казалось бы, причем тут изменение интерфейса?
если у вас изменение интерфейса раскрывает внутреннюю реализацию, так это ведь исключительно ваши проблемы.
V>Тем более что последний интерфейс вполне выполняет свою задачу, иначе нафига его оставили?
а я не понимаю для чего вы меняли интерфейс, если он вполне выполняет свою задачу
V>Только давайте без разговоров о правильном сознании, правильных программистах, правильном выборе интерфейса и правильных объектах, а также противопоставление всего этого программистам сомневающимся в ООП. Чего-то ООП не хватает, знать бы чего?
от вас много слов, но о сферическом коне в вакууме. полно отсутствие какой либо конкретики. и для чего вы их пишете, совершенно непонятно.
SON>>Это не правда. Хороший код, это код в который можно расширить, не переделывая уже сделанную работу или переделывая минимально. SON>>Вот за этим ООП и нужно.
B>Не то что бы не правда. Просто устарело. Новые задачи требуют нового подхода.
любой подход, будь то ООП, будь то FP, требуют придерживания данного принципа. это основа.
Здравствуйте, Vaako, Вы писали:
V>Здравствуйте, mrTwister, Вы писали:
T>>Здравствуйте, Artifact, Вы писали:
T>>Да, да, во всем виновато ООП, а вовсе не кривые руки!
V>Привет пряморуким, осталось выяснить у кого руки прямее.
Не, ну что ты, у тебя конечно же длиннее, только, вероятно, ООП мешает в полный рост встать
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, supacrazypusher, Вы писали:
S>>Для этого нужно нормально проектировать систему и управление зависимостями в ней. Если архитектура ужасная, модульности не и в помине и не делаются попытки улучшить ситуацию, то, боюсь, тут уже неважно ФП, ООП или брэйнфак. WH>Практика показывает, что повторно использовать можно только тот код, который специально для этого проектировался. WH>А это по факту исключительно библиотеки общего назначения.
SON>>>Это не правда. Хороший код, это код в который можно расширить, не переделывая уже сделанную работу или переделывая минимально. SON>>>Вот за этим ООП и нужно.
B>>Не то что бы не правда. Просто устарело. Новые задачи требуют нового подхода.
E>любой подход, будь то ООП, будь то FP, требуют придерживания данного принципа. это основа.
Нам шашечки или ехать? Прадигма выбирается под задачу или наоборот? Я как-то не очень понимаю такие принципы. Но если хочется. Имеете право придерживаться
Здравствуйте, batu, Вы писали:
B>Здравствуйте, Enomay, Вы писали:
SON>>>>Это не правда. Хороший код, это код в который можно расширить, не переделывая уже сделанную работу или переделывая минимально. SON>>>>Вот за этим ООП и нужно.
B>>>Не то что бы не правда. Просто устарело. Новые задачи требуют нового подхода.
E>>любой подход, будь то ООП, будь то FP, требуют придерживания данного принципа. это основа. B>Нам шашечки или ехать? Прадигма выбирается под задачу или наоборот? Я как-то не очень понимаю такие принципы. Но если хочется. Имеете право придерживаться
вы даже не читаете исходное сообщение и не пытаетесь понять то, на что отвечаете. о чем еще можно говорить?
Если нам не помогут, то мы тоже никого не пощадим.
