Только начал ООП. Тренируюсь на системе с планируемыми объектами: человек с его личным счётом, банк, магазин. Вопросы:

1. Т.к. счёта это однотипные объекты решил сделать для них класс и работать с ними как его экземплярами. Это нормально что при наличии нескольких тысяч пользователей будет несколько тыс. экземпляров этого класса?

2. Пополняется счёт в банке, а тратится в магазине, но вот методы я что-то никак не могу придумать, кто подскажет или наведёт на мысль?

3. Т.к. магазинов много и они тоже однотипные для них я так понимаю тоже рационально создать свой класс, а магазины - это его объекты?

4. Банк только один (единственный экземпляр). Для такого объекта имеет смысл создавать класс с 1 экзепляром или лучше обойтись как-то по другому?

zero50x, некоторые вещи о которых вы упоминаете весьма спорны.




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



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


Понимаете все дело в том, что невозможно определить единственный однозначно верный способ проектирования классов. Это как моделирование реальной жизни. Так если объект банк пополняет (putMoney) счета, то объект магазин снимает (getMoney) деньги со счета. Таким образом объекты имеют обыкновение взаимодействовать друг с другом.


Однотипные магазины - класс, а магазины - объекты? Этот вопрос скорее показывает, что вы не до конца разобрались, что есть класс, а что есть объект.
Класс - это описание свойств и методов объекта. Скажем описанием класса человек может быть: две ноги, две руки, шерсть на голове, нос. А Инокентий - конкретный объект класса человек.


Банк только один - тоже явное упрощение  В остальном смотреть предыдущий комментарий.

zero50x, я бы рекомендовал вам продолжить изучение ООП. Хорошая книжка в этом плане это Гради Буч: Объектно-ориентированный анализ и проектирование. Поищите ее в сети. Также настоятельно рекомендую прочитать о шаблонах проектирования. Удачи!

Если банк только один - имеет смысл реализовать его как Singleton (см. ссылку по шаблонам проектирования).

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

И еще, не стоит называть свой класс именем встроенной функции php (count).

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


методология ООП проектирования, в двух словах, такова: 
1. производим декомпозицию задачи на объекты.
2. определяем, какими сообщениями обмениваются объекты (перечень функций) и какова их семантика
3. классифицируем объекты, выявляя общие свойства/методы, в результате получается иерархия классов

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

если упростить задачу до одного вида счета, то я вижу три функции: 
- синхронизировать объект с БД, эта же функция используется в конструкторе
- выдать состояние счета
- перевести деньги на другой счет

можно движение средств осуществлять и двумя функциями - операциями по дебиту и кредиту, но врядли объект php является первоисточником информации, скорее всё в БД и логике над ней, а на php только интерфейсная часть. тогда, т.к. списывание со счета связано с начислением на (другой) счет, операция должна быть атомарной (транзакцией), и логично иметь одну функцию.

со счетом, кстати, должна быть ассоциирована история движения средств

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

Оффтоп: что-то не пойму, я вроде подписывался на сообщения в теме а на почте не было ничего.