классы могут быть слишком большими?

Question

Я планирую добавить достижения, подобные Steam, на мой игровой сайт. Расчеты будут выполняться запланированным cron с результатами, хранящимися в типичной базе данных MySQL. Для удобства я рассматривал возможность сбрасывать все различные методы расчета в один гигантский класс STATS. Это методы, которые никогда не будут вызваны никакими другими аспектами сайта, только для этих конкретных достижений cron.

Нужно ли беспокоиться об увеличении этого класса? Это о 2k LOC сейчас, но нет никаких причин, он не может расширяться до 10к или 50к, в течение долгого времени ...

Это на хостингом кстати, поэтому ограничения памяти существуют в какой-то степени ...

Answer 1

Да, классы могут определенно расти слишком большими.

Когда это происходит, это обычно является признаком неуместной ответственности. Классы, которые делают слишком много, - это AntiPattern called The Blob aka God class. Эти классы нарушают Single Responsibiliy Principle и будут иметь негативное влияние на сцепление и сцепление. Это, в свою очередь, сделает ваше приложение менее многоразовым и сложнее расширить и поддерживать.

Чтобы разделить обязанности должным образом, рассмотрите, какие данные вы можете логически группировать вместе, а затем превращать их в отдельный объект. То же самое верно и для длинных методов. Разделите их. Если вы обнаружите, что определенная подпрограмма занимает много места в объекте, посмотрите, можете ли вы продвинуть этот код в Стратегии, инкапсулируя этот алгоритм.

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

Answer 2

Почему вы думаете, что класс будет слишком большим?

И если вы думаете, что несколько экземпляров одного и того же класса может использоваться, вы можете сделать все эти методы, как static (Таким образом, все функции будут иметь только один экземпляр.)

Или создать только один экземпляр этого и разрешить другим пользователям обращаться к одному экземпляру, используя & перед исходным экземпляром.

Или вы можете рассмотреть возможность использования Singleton Pattern.

EDIT

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

Это будет держать ваш код организованным и классы разделены соответственно.

Answer 3

При создании класса больше у вас есть только недостаток утечки памяти, так как большинство функций не будет использоваться и останется сидеть в памяти до тех пор, пока объект не будет существовать, но точка, что если вы создаете очень мало объектов, таких как Singleton, чем это идеально.

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

Что бы я предлагал вам реализовать наследование между классами, организация организации mater тоже, Сделать OOD для него. Таким образом, вам потребуется меньше времени для изменения и управления кодом. Примите преимущество инкапсуляции и полиморфизма :)

Answer 4

При написании класса, вы спросите себя: «Является ли эта функция необходима как экземпляр или в качестве глобальной функции?», Это лучше всего описывается на примере:

class House { 

    private $door; 
    private $window; 
    private static $adverb; 

    public function __construct(Door $door, Window $window) { 
     $this->door = $door; 
     $this->window = $window; 
    } 

    public function placeNewDoor($door) { 
     $this->door = $door; 
    } 
    public function placeNewWindow() { 
     $this->window = $window; 
    } 

    public static function advertiseNeighborhood() { 
     echo "Advertisment! " . self::$adverb; 
    } 

} 

Было бы много домов, каждый из которых, вероятно, имел бы Door и Window. Таким образом, каждый из них получает метод/свойство экземпляра. Тем не менее, вы только рекламируете свой Neighborhood один раз (не для дома), так что функция статична и к ней будет обращаться House::advertiseNeighborhood.

Почему я опубликовал этот пример? Если есть функция, которая не требуется для создания экземпляра, они должны оставаться static. Это предотвратит утечку памяти при создании нескольких объектов.

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