Discussion (8)4
Log in or sign up to continue

I think you might want to track these numbers instead:

  • Number of properties. $lb is list, so the larger the number of elements in a list the longer the time to get to the last element. Also larger larger lists exhaust the global buffer faster, so they might be less optimal. 
  • Method size in sloc. Ideally, your class shouldn't have methods spanning hundreds (thousands) of lines.

I wouldn't worry about total class length, but rather the number of individual elements and method sizes.

There's also class limits docs, but if you hit them, you probably have an issue already.

Hi Evgeny!

First, kudos on developing such complex logic; no easy feat! As far as the question itself, it's a good question, but leading down the wrong line of thought.

The question shouldn't be "how big can I make this one class," but rather, "how is this logic and code going to be maintained." Having a class with so many lines of code, while possible, will be a nightmare to extend and maintain.

For example, say you're working on adding functionality and discover a bug in the code already in production. As a monolithic design, are you going to remove your not-ready-for-production feature, fix the bug, promote to live, and add the feature code back? What if you bring on another developer? Depending on server side/client side change control, you may end up limiting to one developer being able to work on the code at any given time. And what about multi threading and bottlenecks identified during testing and live processing? A single class will already likely need refactoring to deal with these sorts of things.

There is a reason ISC is implementing IPM and "micro services" as a strategy moving forward. The less monolithic, the better in the long run (within reason, as you don't want code scattered everywhere for no reason).

Look at options to break things up a bit. You'll thank yourself later!