4 ms·

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. F

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-object.html https://www.yegor256.com/2014/11/20/seven-virtues-of-good-ob...

goto11 5y ago
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.
bcrosby95 5y ago
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.
- spawarotti 5y ago
  What you are saying might be a manifestation of the "bounded context" pattern/problem: https://martinfowler.com/bliki/BoundedContext.html 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-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

goto11 5y ago

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.

bcrosby95 5y ago

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.

spawarotti 5y ago
What you are saying might be a manifestation of the "bounded context" pattern/problem: https://martinfowler.com/bliki/BoundedContext.html 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-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...