Начала орхетектуры.

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

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

Т.е. прдон но Вы несете какую - то ню.

И о том же говорю, Вы еще тот извращенец )))

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

Глобально, это когда не ограничено никакими рамками. Члены класса являются частью этого класса и вне его не существуют. Ничего, что есть в классе не является глобальным по отношению ни к чему.

Методы класса видят поля класса потому, что и те и другие являются членами этого класса. Т.е. вещи находятся на одном уровне видимости друг для друга.

Между прочим я не говорю что это неправильно, я просто намекаю что люди скрыли в классе работу с глобалами, как это было раньше, когда программировали в процедурном стиле. Чем больше класс, тем лучше инкапсуляция, и это не бред, а реальность.

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

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

Да ладно, тут всё равно тихо и никого нет. Можно и побеседовать. Тем более, что по теме.

Почему вы считаете класс имитацией модульности?

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

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

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

А это не про тоже самое?

Процедурное это как раз самое простое, эффективное, понятное, легко поддерживаемое(если правильно используется))

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

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

Я не увидел в вашем описании "компоненты" никаких принципиальных отличий от объектов.