Hacker News Reader

Comment by rr808 | Hacker News Reader

> This lead to futile discussions about what "one thing" really constitute, and tend to lead to "ravioli code" with innumerable tiny functions and objects, which is really hard to read and understand.

Right I dont understand this either. Instead of one file with a few hundred lines of code lots of people prefer 20 classes/files. Drives me nuts.

View on HN

On an "abstract/fuzzy" level I would say that a class with several hundreds lines of code means you are missing some terms in your domain language dictionary. For example, you might be doing a lot of inline operations on strings that represent PhoneNumber, but instead you could extract that logic into a PhoneNumber class. Even if it is only used within the scope of the larger class. Once you apply this a couple of times you will have few classes each with no more than 200 lines of code (in a language like C#).

The critical thing here is: these classes reflect terms from the domain model that can be easily intuitively understood, not some made-up abstractions adding to incidental complexity, like -Manager, -Util, -Provider, -Context, -Wrapper, and so on.

Conversely, you can imagine that you wrote a sentence, took some words from it, assumed these words don't exist, and replaced them with their dictionary definitions. Repeat a couple of times and you have your one big class. Extracting classes to capture domain language terms is like reversing this obfuscation/serialization process.

Cool article on the topic: https://www.yegor256.com/2014/11/20/seven-virtues-of-good-ob...

One of our clients is a company that franchises out their operations for different countries. I wish I could have a simple PhoneNumber class. Or simple anything class.

But realistically what happens is, e.g., each franchisee wants us to treat phone number differently than eachother. USA wants no country code. Europe does. Japan wants strict number validation. Taiwan doesn't care. And so on.

At the end of the day it all gets stored as a simple string in the database, and there's software other companies have written that can set it to whatever the hell they want so we have to handle that anyways.

Really all I need is a simple string and a validation function.

What you are saying might be a manifestation of the "bounded context" pattern/problem:

https://martinfowler.com/bliki/BoundedContext.html

It is a huge topic. Hard for me to discuss this further without knowing the specifics. But intuitively, if it was as simple as "Really all I need is a simple string and a validation function." then you wouldn't need a class with several hundred lines of code.

Or you could have UsaPhoneNumber, JapanesePhoneNumber, etc.

And instead of doing:

IsValidUsaPhoneNumber(str);

you could do:

var usaPhoneNumber = new UsaPhoneNumber(str);

and now you have the validness captured as a type:

https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

Splitting a larger function or class into smaller components is not in itself an improvement. Therefore I really dislike quantitative rules like "no more than 200 lines". Simple is better than complex, but splitting an otherwise cohesive module into multiple modules does not make the code simpler, it just increases the accidental complexity.

This is why SRP and this paper are important: They give qualitative guidelines for how to partition systems, not cuter-productive quantitative guidelines.

Reply on news.ycombinator.com