Обсудим идеи как можно радикально облегчить и упростить программирование?

[Flex Ferrum]

Цитата Исмаил Прокопенко @ 07.11.16, 07:51

Вы так говорите, как будто рады этому.

Нет. Я это говорю, потому что перед тем, как что-либо делать, надо бы подумать, как именно это делать. Ну или делать как-то так:

Скрытый текст

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

[Исмаил Прокопенко]

Цитата Flex Ferrum @ 07.11.16, 07:47

Ага. Есть у меня такой скилл.

Понятно.
Значит никакой конкретики/деталей от Вас не будет.
Ну что ж. Произнести с умным видом какой-нибудь специальный термин (типа "абстрактные интерфейсы"), причем ни к месту, а потом "уйти в тень" - так очень просто выглядеть умным.

[Flex Ferrum]

Цитата Исмаил Прокопенко @ 07.11.16, 07:51

А Вам не приходило в голову, что в software можно изменить само понятия "контракта"?
И уйти от представления интерфейса в виде списка кортежей

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

[Исмаил Прокопенко]

Цитата Flex Ferrum @ 07.11.16, 07:55

для обладателя скилла "Не хочу думать, хочу программировать".

Нужно не только думать. А еще и задумываться.
А что дальше? А как этого можно избежать/обойти? А что еще можно придумать?

[Flex Ferrum]

Цитата Исмаил Прокопенко @ 07.11.16, 08:00

А что дальше? А как этого можно избежать/обойти? А что еще можно придумать?

Читать умные книжки про принципы проектирования систем, системный анализ, архитектуру, паттерны проектирования и т. п. Хотя бы осилить букварь Гарди Буча "Объектно-ориентированный анализ и проектирование".

[Исмаил Прокопенко]

Flex Ferrum
Ладно.
Я с Вами достаточно пообщался. А полезной инфы вынес ноль.
Играть с Вами в "угадайку" (попробуй угадай, что я имел в виду) и игру "я умный - ты дурак" (где роль "умного" Вы без всяких на то оснований выбрали для себя) мне не интересно. Давно уже вышел из детсадовского возраста.
Вы либо нормальным языком рассказываете, либо я пас общаться с Вами.
Впрочем, я по любому, пас.

Сообщение отредактировано: Исмаил Прокопенко - 07.11.16, 08:08

[Flex Ferrum]

Цитата Исмаил Прокопенко @ 07.11.16, 08:04

Вы либо нормальным языком рассказываете, либо я пас общаться с Вами.

А чего рассказать то? Как программы на C++ писать? Интерфейсы классов прорабатывать? Поймите - вы делаете вброс, из которого видно, что вы совершенно не разбираетесь в предмете. Примерно как "Зачем лечить воспаление антибиотиками, когда подорожник приложить можно". А потом просите что-то вам объяснить, опровергнуть очевидную глупость. Зачем?

[Исмаил Прокопенко]

Цитата Flex Ferrum @ 07.11.16, 08:07

Поймите - вы делаете вброс, из которого видно, что вы совершенно не разбираетесь в предмете.

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

Сообщение отредактировано: Исмаил Прокопенко - 07.11.16, 08:19

[Flex Ferrum]

Добавлено 07.11.16, 08:19

Цитата Исмаил Прокопенко @ 07.11.16, 08:09

Вы делаете вброс, из которого видно, что Вы вообще не въехали, о чем речь.

Так и о чём же речь? Я то грешным делом подумал про проектирование ПО и приложение этой дисциплины к языку С++. А вы про что?

Добавлено 07.11.16, 08:34
Эх... Ну вот... Спугнул...

[OpenGL]

Цитата Flex Ferrum @ 07.11.16, 08:02

Читать умные книжки про принципы проектирования систем, системный анализ, архитектуру, паттерны проектирования и т. п. Хотя бы осилить букварь Гарди Буча "Объектно-ориентированный анализ и проектирование".

А вот кстати - какие бы ты книги посоветовал на эту тему, кроме уже упомянутой?

[AVA12]

Исмаил Прокопенко:

Цитата

Но ситуация выглядит так: программист, в худшем случае, должен БЕЗОШИБОЧНО написать СРАЗУ ВСЕ кортежи сразу ВСЕХ зависимых классов

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

Вообще же самые серьезные проблемы создания правильных интерфейсов возникают при проектировании всяких API. Вот тут действительно приходится вертеться, ведь готовые приложения уже не перепишешь. Документация по Win32 API, например, читается, как приключенческий роман - четко видна история развития и то, как разработчики стелили соломку и обходили грабли. И ведь справлялись же! А если следовать вашей логике, то никакие API в принципе невозможны.

Цитата

Примеры в студию.

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

Цитата

Как можно изменить имя метода класса X, чтобы использующие его другие классы "не заметили" этого?

Зачем это делать? Коллизия имен? Ну так это можно заранее предусмотреть - чем специфичнее поведение, тем специфичнее имя.

Цитата

Как можно изменить типа параметра в классе X или вообще его убрать, чтобы использующие его другие классы "не заметили" этого?

Зачем это делать? Устаревший параметр? Ну так можно просто его игнорировать. Или просто убрать, и пусть устаревший код не компилируется.

Цитата

Как можно вообще удалить из интерфейса некоторый метод в классе X, чтобы использующие его другие классы "не заметили" этого?

Зачем это делать? Устаревший метод? Опять же, поставить заглушку или пусть не компилируется.

[Исмаил Прокопенко]

Цитата AVA12 @ 07.11.16, 10:45

Ну предъявите же этот худший случай! Я просто не представляю, как можно так влипнуть.

Цитата "ИсмаилПркопенко

Ну ладно. Раз Вы так умоляете (хотя ей Богу не пойму: что непонятного-то в том, что я написал выше?)
Самой простой случай.
Есть класс X.
В нем метод g(Y,Z)
Классы Y,Z описаны, естественно, вне класса X.
В теле g вызываются метод h(W) класса Y и метод j(U) класса Z.
Таким образом, класс X уже "завязался" на 4 класса: Y,Z,W,U.
А ведь это очень примитивный пример.
В реале все гораздо сложней и запутанней.

Сообщение отредактировано: Исмаил Прокопенко - 07.11.16, 11:29

[Flex Ferrum]

Цитата OpenGL @ 07.11.16, 10:28

А вот кстати - какие бы ты книги посоветовал на эту тему, кроме уже упомянутой?

Помимо этого - "Object-Oriented Software Construction" Мэйера. Но лично у меня основные знания - от прослушанных курсов по RUP.

[Исмаил Прокопенко]

Цитата AVA12 @ 07.11.16, 10:45

Мне ни разу не приходилось продумывать одновременно все контракты

Кто-то не знаком с такими литературными приемами как "гипербола", "аллегория" и "сарказм"?
Нельзя же все буквально понимать.

Естественно чтобы АБСОЛЮТНО ВСЕ И СРАЗУ - такое редко бывает.
А вот что несколько классов завязаны друг на друга - такое сплошь и рядом.
Когда класс нельзя изменить "без оглядки" на другие

Добавлено 07.11.16, 11:24

Цитата AVA12 @ 07.11.16, 10:45

А если следовать вашей логике, то никакие API в принципе невозможны.

Ну это уже передергивание.
"Сложно" не значит "невозможно"

Добавлено 07.11.16, 11:28

Цитата AVA12 @ 07.11.16, 10:45

Зачем это делать?

Я понимаю чем вызвано Ваше недоумение. Потому что Вас приучили (надрессировали) к стилю программирования, когда не стоит что-то менять в архитектуре даже если ошибся или знаешь как ее улучшить. Так как это повлечет изрядный гимор и большой объем по переделке кода. Поэтому процветает такой подход, когда баги в архитектуре не исправляются, а обходятся и завуалируются. Разного рода обертками, переопределениями в потомках и т.п.
Вот поэтому я и говорю.
Что мало того, что нужно сразу продумать довольно большой набор кортежей вида имя_метода_класса(класс1, класс2, ..., классN).
А если ошибся - потом уже не исправишь. Слишком большой гимор потому что будет.
И обычная практика это не исправлять баги проектирования.
А завуалировать и обходить их.
Разного рода обертками, переопределениями в потомках и т.п.

Добавлено 07.11.16, 11:34

Цитата AVA12 @ 07.11.16, 10:45

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

Да я в курсе.
Изучал для общего развития исходники MFC.
Там гавнокод на гавнокоде.
И никакой книжной красоты ОО-архитектуры и в помине нет

Сообщение отредактировано: Исмаил Прокопенко - 07.11.16, 11:41

[AVA12]

Цитата

Таким образом, класс X уже "завязался" на 4 класса: Y,Z,W,U.

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

Цитата

Кто-то не знаком с такими литературными приемами как "гипербола", "аллегория" и "сарказм"?
Нельзя же все буквально понимать.

Так может все, что вы написали - это гиперболическая аллегория, и воспринимать это всерьез не нужно?

Цитата

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

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