Здравствуйте, B0FEE664, Вы писали:

vsb>>Для тех, кто его будет читать и модифицировать в будущем.
BFE>Так. Где мой хрустальный магический шар предсказаний?

Не натёрли ещё. Путь к шару долгий и начинается с написания развесистого блока catch.

vsb>>Планка зависит от минимальной квалификации допускаемого к этому коду программиста конкретной компании. Там, где я был, эта планка на уровне начинающего разработчика, знающего основные конструкции языка.
BFE>Вы понимаете, что с какой планкой в компании будут работать только начинающие программисты?

В многоклеточной компании существует разделение труда.

vsb>>В NASA, наверное, эта планка на уровне доктора наук.
BFE>Смешно мне с такого.

А мне грустно: проскакивала информация, что в Гугле яйцеголовых бросают на цензурирование высказываний в Ютубе.

Здравствуйте, B0FEE664, Вы писали:

N>>>А о неуместных абстракциях, бесполезных интерфейсах и всяких контейнерах не к месту. Когда с маниакальной настойчивостью пишут супергибкий и расширяемый во все стороны код.
BFE>Ерунда это. Супергибкий и расширяемый во все стороны код почти никто не умеет писать. Такой код обычно не проходит тестирование.

Люто минусую.

BFE>Абстакции никак не связаны со сложностью чтения, а вот со сложностью исправления багов — очень даже. При абстракциях баг правится ровно в одном месте, а при их отсутствии приходится искать все возможные неверные конфигурации по всему коду.

Люто плюсую.

Здравствуйте, Умака Кумакаки, Вы писали:

BFE>>Абстакции никак не связаны со сложностью чтения, а вот со сложностью исправления багов — очень даже. При абстракциях баг правится ровно в одном месте, а при их отсутствии приходится искать все возможные неверные конфигурации по всему коду.

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

Вы лучше про своё место работы напишите, чтобы обходить его за милю*.

*Миля -- абстрактная единица.

Здравствуйте, B0FEE664, Вы писали:

BFE>Абстакции никак не связаны со сложностью чтения, а вот со сложностью исправления багов — очень даже.

Мне кажется, абстракция как раз-таки упрощает чтение кода, смотрим определение термина "абстрация" в википедии:
"Абстра́кция в объектно-ориентированном программировании — это использование только тех характеристик объекта, которые с достаточной точностью представляют его в данной системе. Основная идея состоит в том, чтобы представить объект минимальным набором полей и методов и при этом с достаточной точностью для решаемой задачи."

Ведь чем меньше полей, особенно если нет лишних полей, тем проще читать код.

Здравствуйте, gyraboo, Вы писали:

BFE>>Абстакции никак не связаны со сложностью чтения, а вот со сложностью исправления багов — очень даже.

G>Мне кажется, абстракция как раз-таки упрощает чтение кода, смотрим определение термина "абстрация" в википедии:
G>"Абстра́кция в объектно-ориентированном программировании — это использование только тех характеристик объекта, которые с достаточной точностью представляют его в данной системе. Основная идея состоит в том, чтобы представить объект минимальным набором полей и методов и при этом с достаточной точностью для решаемой задачи."

Странное определение. Что ещё за "с достаточной точностью"?

G>Ведь чем меньше полей, особенно если нет лишних полей, тем проще читать код.

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

Думаете легко с такой абстра́кцией работать? Скажу по опыту: работать можно, но это не просто. Гораздо проще, если методы и поля можно вызывать и использовать непосредственно. Однако есть системы, где прямые вызовы и непосредственное использование будут только усложнять код, а вот приведённая абстракция — упрощать. Поэтому уровень абстрагирования должен соответствовать сложности решаемой задачи.

Здравствуйте, B0FEE664, Вы писали:

BFE>>>Абстакции никак не связаны со сложностью чтения, а вот со сложностью исправления багов — очень даже.

G>>Мне кажется, абстракция как раз-таки упрощает чтение кода, смотрим определение термина "абстрация" в википедии:
G>>"Абстра́кция в объектно-ориентированном программировании — это использование только тех характеристик объекта, которые с достаточной точностью представляют его в данной системе. Основная идея состоит в том, чтобы представить объект минимальным набором полей и методов и при этом с достаточной точностью для решаемой задачи."

BFE>Странное определение. Что ещё за "с достаточной точностью"?

"с достаточной точностью для решаемой задачи"
Почему странное? А как бы ты определил что такое абстракция?

G>>Ведь чем меньше полей, особенно если нет лишних полей, тем проще читать код.

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

BFE>Думаете легко с такой абстра́кцией работать? Скажу по опыту: работать можно, но это не просто. Гораздо проще, если методы и поля можно вызывать и использовать непосредственно. Однако есть системы, где прямые вызовы и непосредственное использование будут только усложнять код, а вот приведённая абстракция — упрощать. Поэтому уровень абстрагирования должен соответствовать сложности решаемой задачи.

Ну да, уровень абстрагирования должен быть "с достаточной точностью для решаемой задачи".
Перечисляющие методы — это какой-то необычный подход, я конечно же говорил про обычное ооп-шное, когда все методы и поля именуются и вызываются клиентом явно, а не через какие-то списки функций и полей. Другими словами, чем меньше методов и полей у класса, без ущерба решаемой задаче, тем проще код. Если же подходить к этому формально, то теоретически можно разбить всю бизнес-логику на простейшие абстракции, у каждой сделать всего 2 метода:
execute() — выполняет 1 операцию
getLinked() — возвращает ссылку на связанную абстракцию.
Если по бизнесу некая сущность выполняет n операций, то мы разбиваем эту сущность на n абстракций, каждая абстракция объявляет метод execute и ссылку на связанную абстракцию, которая выполняет другую операцию этой бизнес-сущности. И формально такой код должен быть наиболее простым, ведь каждая абстракция имеет всего 2 метода. Но по сути такой код превратится в гротескную и сложную для понимания кашу.

Здравствуйте, gyraboo, Вы писали:

G>"с достаточной точностью для решаемой задачи"
G>Почему странное? А как бы ты определил что такое абстракция?
Абстракция в ООП — это возможность совершать операцию над неопределённым множеством разнотипных объектов (или же метод позволяющий исполнить такую возможность).

G>>>Ведь чем меньше полей, особенно если нет лишних полей, тем проще читать код.

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

BFE>>Думаете легко с такой абстра́кцией работать? Скажу по опыту: работать можно, но это не просто. Гораздо проще, если методы и поля можно вызывать и использовать непосредственно. Однако есть системы, где прямые вызовы и непосредственное использование будут только усложнять код, а вот приведённая абстракция — упрощать. Поэтому уровень абстрагирования должен соответствовать сложности решаемой задачи.

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

G>Другими словами, чем меньше методов и полей у класса, без ущерба решаемой задаче, тем проще код. Если же подходить к этому формально, то теоретически можно разбить всю бизнес-логику на простейшие абстракции, у каждой сделать всего 2 метода:
G>execute() — выполняет 1 операцию
G>getLinked() — возвращает ссылку на связанную абстракцию.
G>Если по бизнесу некая сущность выполняет n операций, то мы разбиваем эту сущность на n абстракций, каждая абстракция объявляет метод execute и ссылку на связанную абстракцию, которая выполняет другую операцию этой бизнес-сущности. И формально такой код должен быть наиболее простым, ведь каждая абстракция имеет всего 2 метода. Но по сути такой код превратится в гротескную и сложную для понимания кашу.

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

Здравствуйте, B0FEE664, Вы писали:

G>>"с достаточной точностью для решаемой задачи"
G>>Почему странное? А как бы ты определил что такое абстракция?
BFE>Абстракция в ООП — это возможность совершать операцию над неопределённым множеством разнотипных объектов (или же метод позволяющий исполнить такую возможность).

Не совсем корректная формулировка. Ведь все эти разнотипные объекты все же состоят в отношениях с абстракцией ("is a" в случае наследования или "realize" в случае реализации). Поэтому говорить, что эти объекты разнотипны — это не совсем корректно. Их типы всегда имеют одним из базовых типов тип абстракции.
Кроме того, есть абстракции, выделенные по признакам (полям), а не по операциям, поэтому возможность совершать операцию — это не определение того что такое абстракция.
Я думаю так: Абстрагирование — это создание типа, обобщающего множество объектов разных подтипов. Абстракция — это сам обобщающий тип.

G>>>>Ведь чем меньше полей, особенно если нет лишних полей, тем проще читать код.

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

BFE>>>Думаете легко с такой абстра́кцией работать? Скажу по опыту: работать можно, но это не просто. Гораздо проще, если методы и поля можно вызывать и использовать непосредственно. Однако есть системы, где прямые вызовы и непосредственное использование будут только усложнять код, а вот приведённая абстракция — упрощать. Поэтому уровень абстрагирования должен соответствовать сложности решаемой задачи.

G>>Ну да, уровень абстрагирования должен быть "с достаточной точностью для решаемой задачи".
G>>Перечисляющие методы — это какой-то необычный подход, я конечно же говорил про обычное ооп-шное, когда все методы и поля именуются и вызываются клиентом явно, а не через какие-то списки функций и полей.
BFE>Это обычное, но редко используемое ООП.

G>>Другими словами, чем меньше методов и полей у класса, без ущерба решаемой задаче, тем проще код. Если же подходить к этому формально, то теоретически можно разбить всю бизнес-логику на простейшие абстракции, у каждой сделать всего 2 метода:
G>>execute() — выполняет 1 операцию
G>>getLinked() — возвращает ссылку на связанную абстракцию.
G>>Если по бизнесу некая сущность выполняет n операций, то мы разбиваем эту сущность на n абстракций, каждая абстракция объявляет метод execute и ссылку на связанную абстракцию, которая выполняет другую операцию этой бизнес-сущности. И формально такой код должен быть наиболее простым, ведь каждая абстракция имеет всего 2 метода. Но по сути такой код превратится в гротескную и сложную для понимания кашу.

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

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

mgu>А вашему начальнику не нужны профессионалы: они же, канальи, всё сделают за полгода, и система будет работать как часы. Затем профессионалы откочуют в другую контору, а куда деваться начальнику?

И что мешает наальнику самому их "откочевать", а вместо них набрать раза в 3 больше джунов, которые будут в 2 раза дешевле? А что, система крутится, лавэ мутится... Мастера сделали свое дело, им заплатили $$$$$$$$ , теперь можно и лей-оффнуть.

Здравствуйте, gyraboo, Вы писали:

BFE>>Абстакции никак не связаны со сложностью чтения, а вот со сложностью исправления багов — очень даже.

G>Мне кажется, абстракция как раз-таки упрощает чтение кода, смотрим определение термина "абстрация" в википедии:
G>"Абстра́кция в объектно-ориентированном программировании — это использование только тех характеристик объекта, которые с достаточной точностью представляют его в данной системе. Основная идея состоит в том, чтобы представить объект минимальным набором полей и методов и при этом с достаточной точностью для решаемой задачи."

G>Ведь чем меньше полей, особенно если нет лишних полей, тем проще читать код.

Подкину ещё: если кто-то не видит абстракций, то это не означает, что их нет. Например, нам надо оперировать возрастом:

int age = 33;

int -- это абстракция, возраст обычно не превышает 120 лет, понадобятся проверки. А можно и чисто конкретно:

Age age = new Age(33);

А внутри будут конструктор и сеттер с проверкой. Но всё равно нужно будет отслеживать их успешность. Так что часто абстракции проще. А при предоставлении API без них вообще никак.

Здравствуйте, Lloret, Вы писали:

mgu>>А вашему начальнику не нужны профессионалы: они же, канальи, всё сделают за полгода, и система будет работать как часы. Затем профессионалы откочуют в другую контору, а куда деваться начальнику?

L>И что мешает наальнику самому их "откочевать", а вместо них набрать раза в 3 больше джунов, которые будут в 2 раза дешевле? А что, система крутится, лавэ мутится... Мастера сделали свое дело, им заплатили $$$$$$$$ , теперь можно и лей-оффнуть.

Да так, собственно, обычно и происходит. Причём по спирали: в моменты, когда система начинает идти вразнос, нанимают реаниматолога.

Здравствуйте, B0FEE664, Вы писали:

BFE>Скажите, Умака Кумакаки, как часто вы исправляете ошибки в чужом коде? Не находите, а именно исправляете.

три раза в день, например

Здравствуйте, mgu, Вы писали:

mgu>int age = 33;

mgu>Age age = new Age(33);

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

Здравствуйте, Умака Кумакаки, Вы писали:

mgu>>int age = 33;

mgu>>Age age = new Age(33);

УК>если для тебя второй вариант проще, то это серьёзные проблемы с кукухой и "вон из профессии"

Зависит от абстракции. Если абстракция возраст имеет такие свойства, как особенности возраста, то инкапсулировать их в объекте Возраст — не самая плохая идея.

Здравствуйте, Умака Кумакаки, Вы писали:

УК>Здравствуйте, mgu, Вы писали:

mgu>>int age = 33;

mgu>>Age age = new Age(33);

УК>если для тебя второй вариант проще, то это серьёзные проблемы с кукухой и "вон из профессии"

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

Age age = 33;

(с перегрузкой оператора).

Но не все понимают абстракции, как например:

Здравствуйте, vsb, Вы писали:

L>Простой для кого и понятный кому?

vsb>Для тех, кто его будет читать и модифицировать в будущем. Планка зависит от минимальной квалификации допускаемого к этому коду программиста конкретной компании. Там, где я был, эта планка на уровне начинающего разработчика, знающего основные конструкции языка.

Это правильно — не найдут роту вундеркиндов в компанию по разработке софта.
Тем более, что кроме самого ЯП/технологии, следует иметь и представления о прикладной области, для которой и создаётся софт.

В NASA, наверное, эта планка на уровне доктора наук.

Самый трудночитаемый и сложно-сопровождаемый код я видел у людей науки.
Их задача — не код, а скорее концепции и формулы.
Так что — и в NASA будут те же требования, когда передадут разработку субподрядной софтверной компании.

P.S. В NASA (предполагаю) разработку ещё пару лет будут тестировать.

Здравствуйте, B0FEE664, Вы писали:

BFE>Абстакции никак не связаны со сложностью чтения, а вот со сложностью исправления багов — очень даже. При абстракциях баг правится ровно в одном месте, а при их отсутствии приходится искать все возможные неверные конфигурации по всему коду.

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

Здравствуйте, Sharov, Вы писали:

BFE>>Абстакции никак не связаны со сложностью чтения, а вот со сложностью исправления багов — очень даже. При абстракциях баг правится ровно в одном месте, а при их отсутствии приходится искать все возможные неверные конфигурации по всему коду.

S>Грамотное абстракции это самое чтение очень сильно сокащают -- не надо лапатить кучу кода, чтобы что-то найти и поправить. Ищется
S>конкретная абстракция и соотв. метод, в одном месте все и правиться. В противном случае, процедурный стиль или дурацкие и текучие
S>абстракции, править надо в нескольких местах, а значит и кода прочитать в разы больше. Абстракции именно про написания и чтение кода,
S>экономия времени на этом.

И ещё нужно соблюдать принцип SOLID/DIP. Чтобы не смешивать на одном уровне абстракцию и реализацию. Иначе детали реализации будут затруднять чтение кода абстракции.

Здравствуйте, gyraboo, Вы писали:

G>И ещё нужно соблюдать принцип SOLID/DIP. Чтобы не смешивать на одном уровне абстракцию и реализацию. Иначе детали реализации будут затруднять чтение кода абстракции.

Я же упомянул текучие абстракции (leaky abstractions), это как раз оно.

Здравствуйте, Sharov, Вы писали:

G>>И ещё нужно соблюдать принцип SOLID/DIP. Чтобы не смешивать на одном уровне абстракцию и реализацию. Иначе детали реализации будут затруднять чтение кода абстракции.

S>Я же упомянул текучие абстракции (leaky abstractions), это как раз оно.

А, ясно. Не знал такого термина, поэтому не заметил.