- то это получается реально странно. Большая часть программ - это работа с таблицами. Выбрал данные, применил к ним бизнес логику и далее либо записал обратно, либо вывел куда-то. И вот мы внедряем ООП. Выбрали кучу документов - на каждый документ сгенерили экземпляр класса Документ, на все позиции документа сгенерили экземпляр класса Позиция. Создали еще несколько объектов реализующих бизнес логику. Запарились взаимодействием всего этого зоопарка, делая все по канонам инкапсуляции ( никаких публичных атрибутов, все через SET/GET). И вот обработали мы все документы. И теперь мы все эти экземпляры класса Документ обратно конвертируем в плоские таблицы 😊 А если вы делаете не так жестко, то какое же это ООП? это обычное модульное программирование. И непонятно чем ваш класс лучше старой доброй группы функций )
Вопрос объемов логики. Если это пара селектов для вывода в алв - то одного класса модели с головой. А если у тебя несколько похожих сущностей, но часть логики работы с ними разная - вот у тебя уже и наследование. Если нужно айтем обрабатывать каждый по отдельности - есть смысл делать разные инстанции. Если нет - то можно сделать сущность Items и обработку их общую в этом классе. Если нет кучи логики по обработке айтемов отдельной - достаточно такую таблицу как атрибут в сущности самого документа. Ооп главное использовать на тех уровнях абстракции, на которых это имеет смысл. А большинство пытаются идти по пути "если ооп, то надо все оборачивать в отдельные классы", что не имеет смысла
Обсуждают сегодня