Правильно ли я определил классы в ООП?

Question

[Max Ba]

Парни, в меня уже начало вселяться ООП. Появились два вопроса, которые меня волнуют.

1. Удобно ли писать в стиле ООП небольшие приложения, когда его программирует один программист? Или ООП сделан в основном для командной разработки.

2. Могу ли я контролировать количество запросов к БД в ООП стиле в команде? К примеру мне нужно, чтоб запросов при генерации целого сайта было не более 5, при этом я не в курсе, чем заняты другие кодеры этого проекта. С помощью ООП можно ли этот процесс отследить, или каждый класс будет обращаться к БД по своему методу?

3. Правильно ли я понял сущности самописной CMS. Класс страница (шапка, контент футер), класс витрина товаров, класс товар, класс меню навигационное, класс хлебные крошки.

Answer 1

[Виктор]

1) Конечно удобно. Еще удобнее использовать фрейм-ворки, которые (все) используют ооп
2) Можно использовать синглтон (шаблон singleton) и в нём уже контролировать кол-во запросов. Однако тут я немного могу ошибаться (ибо сложно узнать откуда пришёл запрос: из сообщений или из загрузки страницы)
3) в самописных cms лучше использовать MVC. Тут уже идёт разделение на модели (товар, хлебные крошки), вьюхи (страница, ветрина, меню) и контроллеры, которые связывают это.

Ответил на все два вопроса ;-)

Comments

[Max Ba]

Благодарю за разъяснение)
Тогда сразу два вопроса на засыпку

2) То есть я, программируя на ООП, должен еще знать фрэймворки и какие-то готовые модели или это лишь рекомендуется знать? Тут ООП бы в чистом виде выучить, а при слове фрэймворк сразу мотивация теряется.

3) Я щас и использую чистую MVC модель в инет магазинах. Все разложено по полкам и разделено на котлеты и мух. Каждая модель это функция которая имеет входные переменные, легко расширяются и return-ят результат. index его собирает и выводит. Многие ООП кодеры говорят что это не гуд. Вот я и пытаюсь перемоделировать свой CMS двиг на ООП стиль. Кроме меня мало кому интересно ковыряться в самописке, но для моего развития и освоения понтов не помешает.

[Виктор]

2) фреймворки - не такая то и страшная штука. Сам сначала боялся их, потом глянул фалкон и понял, что все что я писал - жесткий костылепед, который уже там реализован
3) тут вопроса я как-то не увидил

Answer 2

[Saboteur]

ООП это не стиль, это парадигма.
Ее можно использовать для написания программ практически любого размера, но неудобно для мелких скриптов.
Стиль это скорее нотации, типа CamelNotation

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

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

Главная идея ООП заключается вот в чем:

Есть данные. Мы их инкапсулирем в класс.
Есть методы, которые манипулируют именно этими данными. Поэтому методы должны тоже находиться в классе с данными.

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

Answer 3

[Neonoviiwolf]

ООП предназначена, чтобы структурировать код так, чтобы новые возможности вносились малой кровью и позволяет писать меньше кода. Класс "товар" имеет, к примеру, цену и наличие - этот класс будет родителем всех товаров. Дольше расширяем класс "товар", создаём несколько детей: "фототехника", "телефоны" и т.п. Берём класс "фототехника" и создаём детей, которые символизируют производителей (тут можно сразу ввести их сайт и какие либо данные помимо). Далее расширяем класс производителя по его моделям - тут забиваем оставшиеся параметры. Теперь, чтобы добавить ещё какой либо товар из созданных групп, нужно только расширить класс последнего родителя, соответственно кода писать намного меньше. Ну это чисто для пониманию зачем и почему