“What if it changes?”
chriskiehl.com
chriskiehl.com
The reason a lot of Java or C# code is written with all these abstractions is because it aids unit testing. But I've come to love just doing integration testing. I still use unit testing to test complex logic, but things like "does this struct mapper work correctly" are ignored, we'll find out from our integration tests. If our integration tests work, we've fulfilled our part of the contract, that's all we care about. Focus on writing them and making them fast and easy to run. It's virtually no different to unit tests but just 10x easier to maintain.
That is a good rule of thumb, and I often follow it too. But it does take some discernment to recognize cases where something would benefit from an abstraction or some common code, even if it is only used twice.
I used to work for a company that imported airspace data from the FAA (the US Federal Aviation Administration) and other sources. The FAA has two main kinds of airspace: Class Airspace and Special Use Airspace.
The data files that describe these are rather complex, but about 90% of the format is common between the two. In particular, the geographical data is the same, and that's what takes the most code to process.
I noticed that each of these importers was about 3000 lines of C++ code and close to 1000 lines of protobuf (protocol buffer) definitions. As you may guess, about 90% of the code and protobufs were the same between the two.
It seemed clear that one was written first, and then copied and pasted and edited here and there to make the second. So when a bug had to be fixed, it had to be fixed both places.
There wasn't any good path toward refactoring this code to reduce the duplication. Most of the C++ code referenced the protobufs directly, and even if most of the data in one had the same names as in the other, you couldn't just interchange or combine them.
When I asked the author about this code duplication, they cited the same principle of "copy for two, refactor for three" that you and I approve of.
But this was a case where it was spectacularly misapplied.
What I like to do instead is break the shared code paths into a palette of smaller subfunctions/subcomponents and then have each use case have its own high level code path that picks and chooses from these subfunctions: One does ABCDE, another does ACDEX. It makes it supremely easy to reason about what each of them actually do, because they read almost like a recipe. It becomes a sequence of high level steps, some of which are used by several use cases, while others are unique. I've found this way of generalizing is almost "cost free" because it doesn't really couple things at a high level, and it's the kind of readability refactor that you'd often want to do anyway even if the code wasn't being shared.
Isn't this just the Command pattern? - https://en.wikipedia.org/wiki/Command_pattern
The most important (though not only) issue with frameworks is that you typically can't compose/mix more than one together - every framework is "exclusive" and takes control of the code flow. Whereas "components" can usually be easily mixed with each other, and leave control of the code flow to the programmer.
Couldn't disagree more tbh. Some of the worst code I've ever had to work with has been over abstracted "recipe" code where I'm trying to descern complex processes based off two word descriptions of them in function names.
Doing this too much is a great way to turn a readable 100 line algorithm into a 250 line clusterfuck spread across 16 files.
ok, so you're talking about overdoing it. It's still a good approach when done right.
If code is running once in order, there's no reason to break it up into functions and take it out of execution order. That's just stupid.
Basically if it works and you don't have to touch it to change it, leave it alone.
It was back when a bunch of social networks released app platforms after Facebook's success. When hi5 released their platform, rather than refactoring for our codebase to work on multiple social networks... someone ended up just copying the whole fucking thing and did a global rename of Facebook to Hi5.
For the 3rd social network I refactored our Facebook codebase to work with as many as we wanted. But we never reigned in Hi5, because it had diverged dramatically since the copy. So we basically had two completely separate codebases: one that handled hi5, and one that had been refactored to be able to handle everything else (facebook, bebo, myspace, etc)
Maybe we'll have 'Forest Software' in some time. 'A code forest is an ecosystem where the population of bugs, slugs, trees and weed balance themselves, requiring very little input from the engineer'.
That makes it sound like the problem is more of a spaghetti mess than duplication.
But I think the advice to copy something when you need two versions is supposed to be applied to specific functions or blocks or types. Not entire files. Then it wouldn't have duplicated the geographical code.
It's also important to have a good answer to how you'll identify duplicated bugs. I'm not sure how to best handle that.
This is a terrible advice. According to this, a classic program that loads data from a file, processes it, then writes the results to another file should be a single giant main() that mixes input parsing, computation and output formatting. Assuming file formats don't change, all of those would be used only once. CS 101 style. :D
The primary reason for building abstractions is not removing redundancy (DRY) nor allowing big changes, but making things simpler to reason about.
It is way simpler to analyze a program that separates input parsing from processing from output formatting. Such separation is valuable even if you don't plan to ever change the data formats. Flexibility is just added bonus.
If the implementation complexity (the "how") is a lot higher than the interface (the "what") then hiding such complexity behind an abstraction is likely a good idea, regardless of the number of uses or different implementations.
I drop in to Java shops from time to time, and am more than happy to port my simple class structures that make sense and do things into the 18 level hierarchies described in the article. I just assume there is somebody there that is really invested in all those interfaces, adapters, and impls and I’m not here to start silly fights with them. The code will still work no matter how many pieces it’s cut into and how many unnecessary redirections you add so no worries.
But for my own stuff I like to keep things compact and readable.
And why go so extreme? A main() calling into 3 functions like load, process and save will be still plenty better than a single blob of IO mixed with computation and would still contain no boilerplate.
> I drop in to Java shops from time to time, and am more than happy to port my simple class structures that make sense and do things into the 18 level hierarchies described in the article.
I certainly agree with that, but that has nothing to do with abstraction. Abstraction and indirection are different things. Those terrible FizzBuzz Enterprise like hierarchies are typically a mixture of insufficient abstraction and far too much of indirection. Abstraction reduces complexity, while indirection increases it. AbstractFactoryOfFactoryOfProblems is indirection, not abstraction, contrary to what the name suggests.
I wouldn’t. I’d break it up the same as you, with those 3 functions. After we’d shown we were going to be doing lots of similar things. But given the choice between too complicated and too simple, that’s the direction I’d lean.
Apologies if that wasn’t clear in context.
Sure. But a main() ordered into loading, processing, and saving would be similar amounts of better, despite not using the abstraction of functions.
Unless I'm the one using words weirdly here.
>
> This is a terrible advice. According to this, a classic program that loads data from a file, processes it, then writes the results to another file should be a single giant main() that mixes input parsing, computation and output formatting. Assuming file formats don't change, all of those would be used only once.
I broadly agree with you, but devils advocate time: not all abstractions are at the same level.
Writing a static function `slurp()` that takes in a filename and returns the file contents isn't an abstraction in the same sense as having a `FILE *` type that the caller cannot look into which functions like `fprintf()` and `fscanf()` use to operate on files.
I think an opaque datatypes (like `FILE`) are "more abstract" than static functions defined in the same file you are currently reading.
IOW, "Abstraction" is not a binary condition, it is a spectrum from full transparency to full opacity.
Static functions in C would be full transparency (no abstraction at all).
Opaque datatypes in C would be full opacity (no visibility into the datatype's fields unless you have the sources, which you may not have).
C++ classes would be something in-between (the private fields are visible to the human reading the header).
Also, the simpler the interface, usually the more contexts it can be used in. So those abstractions with nice interfaces naturally tend to be more reusable. But I argue this is the consequence, not the primary reason. You probably won't end up with good abstractions by mercilessly applying DRY.
Yes, if the program will be written and tested exactly once, with no change requests to come later, it's perfectly fine to write it as one big main().
It all depends on what the stakeholders need, clear communication with them is the real trick.
If the main was split into well defined, separate pieces, at least you could quickly rule out quite a lot of complexity. If it crashed in parsing, so wouldn't need to understand the processing logic, etc.
Sure it is easy to read one blob of code, if it is only 100 lines of code. But it is a different story if it is 10000 lines and now you have to figure out which of the 100 variables are responsible for keeping the state of the input parser and which are responsible for "business logic".
I mean if it's only like 50 short lines, that would be okay-ish, but in this case why do it in C and not use perl or awk?(i suppose you want fast text processing, so I won't suggest python). If the processing is hard, then you will need debugging (which is better in segregated functions) and to prototype a bit (unless I'm the only one who does that?).
In my mind, the common emphasis on the DRY/WET thing with abstractions leads many people to miss the point of abstractions. They’re not about eliminating repetition or removing work, they’re about making the work a better fit for the problem. Code elimination is a common byproduct of abstractions, but occasionally the opposite may happen to.
I see an abstraction as being comprised of a model and a transformation. The villain isn’t premature abstractions, it’s abstractions where the model is no better (or worse!) for the problem than what’s being abstracted over.
I would add, though, that in my experience you can often identity parts of a design that are more likely to change than others (for example, due to “known unknowns”).
I’ve used microservices to solve this problem in the past. Write a service that does what you know today, and rewrite it tomorrow when you know more. The first step helps you identify the interfaces, the second step lets you improve the logic.
In my experience this approach gives you a good trade off between minimal abstraction and maximum flexibility.
(Of course lots of people pooh-pooh microservices as adding a bunch of complexity, but that hasn’t been my experience at all - quite the opposite in fact)
The same criticisms for microservices (claims that it adds complexity, or too many pieces) are also seen for OOP.
Curiously, while folks sometimes complain about breaking up a system into smaller microservices or smaller classes, nobody every complains about being asked to break up an essay into paragraphs.
Splitting material into individual books makes a little more sense as a metaphor, especially if it's not a linear series of books. You can't just split a mega-book into chunks. Each book needs to be somewhat freestanding. Between books, there is an additional purchasing decision introduced. The end of one book must convince you to go buy the next book, which must have an interesting cover and introduction so that you actually buy it. It might need to recap material in a previous book or duplicate material that occurs elsewhere non-linearly.
A new book has an expected cost and length. We expect to pay 5-20 dollars for a few hundred pages of paperback to read for many hours. We wouldn't want to pay cents for a few pages at a time every 5 minutes. (or if we did, it would require significantly different distribution like ereaders with micropayments or advertising). Some books are produced as serials and come with tradeoffs like a proliferation of chapters and a story that keeps on going.
Anyway, it's a very long way to say that some splitting is merely style, some splitting has deeper implications, the splits can be too big or too small, and some things might not need splits at all.
[author] uses the [simile] to argue the [argument].
The obvious flaw in the [argument] is of course [counterargument].
[quote]: Curiously, while folks sometimes complain about breaking up a system into smaller microservices or smaller classes, nobody every complains about being asked to break up an essay into paragraphs.
[author]: Mr_P
[simile]: microservices or smaller classes are like paragraphs in an essay.
[argument]: since no one complains about breaking up an essay into paragraphs, no one should complain about breaking up a system into paragraphs.
[counterargument]: breaking up a system in smaller microservices or classes is not at all like breaking up an essay into paragraphs, which I think this comment has demonstrated.
There are orders of magnitude different amounts of work in each of these cases. (I’m not saying it’s a lot of work but it’s still significantly more in some of those cases relative to the others.)
They would if each paragraph of that essay lived at a different domain/url.
> If something is used once, ignore any abstractions. If it's used twice, just copy it, it's better. If it's used 3 or more times, look at writing an abstraction
My rule of thumb is that there are only three quantities in the software development industry: 0, 1 and infinity. If I have more than 1 of something, I support (a reasonable approximation of) infinite quantities of that something.
The right word is "generalization", and that's what you are actually doing: you start with a down-to-earth, "solve the problem you've got!" approach, and then when something similar comes up you generalize your first solution.
Perhaps part of the problem is that in OO, inheritance is usually promoting the opposite: you have a base class and then you specialize it. So the base class has to be "abstract" from day one, especially if you are a true follower of the Open Close Principle. I don't know about others, but for me abstractions are not divine revelations. I can only build an abstraction from a collection of cases that exhibit similarities. Abstracting from one real case and imaginary cases is more like "fabulation" than "abstraction".
The opposite cult is "plan to throw away one", except more than just one. Not very eco-friendly, some might say; it does not looks good at all when you are used to spend days writing abstractions, writing implementations, debugging them, and testing them. That's a hassle but at least once you are done, you can comfort yourself with the idea that you can just extend it... Hopefully. Provided the new feature (that your salesman just sold without asking if you could do it, pretending they thought your product did that already) is "compatible" with your design.
The one thing people may not know is how much faster, smaller and better the simpler design is. Simple is not that easy in unexpected ways. In my experience, "future proofing" and other habitual ways of doing things can be deeply embedded in your brain. You have to hunt them down. Simplifying feels to me like playing Tetris: a new simplification idea falls down, which removes two lines, and then you can remove one more line with the next simplification, etc.
A specific example is getters and setters for class variables. If another class directly accesses a variable, you have to change both classes to replace direct access with methods that do additional work. In other languages (Python specifically), you can change the callee so that direct access gets delegated to specific functions, and the caller doesn't have to care about that refactor.
Edit: I suppose it may be argued that you need to set some other state when you set a member variable. If that's the case, then it's no longer a getter or a setter and the function should be treated differently.
You can say that's not a getter/setter, but then your definition is just different than the people you're responding to.
interface Store { Query() }
// these all have the Query() method
type/class MySQL implements Store
type/class Cache implements Store
type/class Logger implements Store
var db Store
db = new Logger(new Cache(new MySQL()))
Of course, in more limited languages/environments they're probably the only tool you have, so there's that.
I get they can be cumbersome, but using them really matters especially as a project grows... an API that has a simple single client today may have many different (and concurrent!) ones tomorrow. The pain of using S&Gs now saves refactoring later.
At what point is it cheaper to just refactor into getters/setters later when needed? That point _has_ to be miles behind me.
Another problem (from a class/library-consumer point of view) is having getters/setters suddenly becoming more expensive to call, blocking, or even having side effects after an update.
It often only affect the runtime behavior of the code.
Changing the interface, however, will give me a hit that something else has changed.
That isn't the only type of OO. Look at CLOS in Common Lisp for a counterexample: https://wiki.c2.com/?HowObjectOrientedIsClos
Maybe for debugging you want to log a callstack every time the field gets accessed, for example.
Or when you set the field, you should invalidate some cached value that uses it.
That is just as bad as a general rule as "What if it ever changes, we need to abstract over it!". As always: It depends. If the abstraction to build is very simple, like making a magic number a named variable, which is threaded through some function calls, at the same time making things more readable, then I will rather do that, than copying copy and introducing the chance of introducing bugs in the future, by only updating one place. If the abstraction requires me to introduce 2 new design patterns to the code, which are only used in this one case ... well, yes, I would rather make a new function or object or class or whatever have you. Or I would think about my over all design and try to find a better one.
Generally, if one finds oneself in a situation, where one seems to be nudged towards duplicating anything, one should think about the general approach to the problem and whether the approach and the design of the solution are good. One should ask oneself: Why is it, that I cannot reuse part of my program? Why do I have to make a copy, to implement this feature? What is the changing aspect inside the copy? These questions will often lead to a better design, which might avoid further abstraction for the feature in question and might reflect the reality better or even in a simpler way.
This is similar in a way to starting to program inside configuration files (only possible in some formats). Generally it should not be done and a declarative description of the configuration should be found, on top of which a program can make appropriate decisions.
The key question is whether there is a functional dependency or just a similarity between some lines of code. If there is a functional dependency, it should be modeled as such the first time it is repeated. If there is only coincidental similarity then introducing a dependency is simply incorrect, regardless of how often any code happens to get repeated.
As others have said, this is a good rule of thumb in many cases because finding good abstractions is hard and so we often achieve code re-use through bad abstractions.
But really good abstractions add clarity to the code.
And thus, a good abstraction may be worth using when there is only two, or even just once instance of something.
If an abstraction causes a loss of clarity, developers should try to think if they can structure it better.
EDIT: This comment below talks about good example of how a good abstraction adds clarity, while a bad abstraction takes it away: https://news.ycombinator.com/item?id=31476408
If you write an integration test, and it fails, what's broken?
That's a valid concern, but if your unit-tests are only for making sure that part you just wrote works as expected than just have a test-case up for that specific part, and change it when you move to the next part.
The value of unit-tests is supposed to be regression testing: when you change something that breaks a different unit in a different part of the stack.
> If you write an integration test, and it fails, what's broken?
Well, I debug it it the same way I debug any bug. After all, most bug reports are from a full execution in the field; I am probably already set up to debug the full application anyway[1].
[1] Once a bug reproduction is set up in a fairly automated way.
A very good one, with effective use of matchers, you don't even have to read the test to know what you did wrong. You just know from the error message what you broke.
>
> A very good one, with effective use of matchers, you don't even have to read the test to know what you did wrong. You just know from the error message what you broke.
Agree, and agreed. The counterpoint is that unit-tests take time to write and time to maintain - you have to balance that time spent against the time that you would spend debugging an integration test.
If your unit tests are hard, you need to refactor your code.
So? You're going to have them anyway or else you can't deploy.
> Major functionality changes can affect all of your tests. With unit tests they may invalidate a few, but that’s okay because they were cheap to begin with.
The logic that usually gets ignored in unit tests is the ones that actually needs to be tested, but skipped because it is too difficult and might involve a few trips to the database which makes it tricky (in some scenarios you need valid data to get a valid test result, but you cannot just go grab a copy of production data to run some test).
And then there is the problem of testing related code, packages and artifacts being deployed to production which is really gross in my mind and bloats everything further.
A team I've worked on has resorted to building actual endpoints to trigger test code that live alongside other normal code (basically not a testing framework), so that they could trigger test and "prove the system works" by testing against production data at runtime.
>The reason a lot of Java or C# code is written with all these abstractions is because it aids unit testing.
That is the justification for talking about testing. Code is being ripped apart to make it easier to test, while the tests that are used as a justification for ripping apart the code are low quality as 99% of the work in unit testing is thinking of and setting up the test case, not the actual test code.
The only possible justification for duplicating code would be that creating an appropriate abstraction is harder. Given that there are generally economies of testing when you factor out common code, that's usually just not true.
"Duplication is evil" is a more reliable mantra.
Yes it means stuff needs to be changed in 2 places. Yes it means someone can change one and not the other. But it also means that each thing can be maintained on it's own without worrying about another. In the early stages you don't know how much can truly be reused and whether you're just cornering yourself. I've had scenarios in the past where we've written an abstraction around some common code and then the third application we want to use it in just does not fit the model we initially thought of. Could we change the library? Yes obviously. But are we going to face the same issue on the 4th project to use this library? Probably. It's a large maintainance load. At some point you end up making breaking changes to the library and you're comitted to either maintaining multiple major versions, or maintaining an abstraction that is supposed to work for every scenario, which can be a huge time sink.
There are tradeoffs to be made. I'd rather lose the maintenance burden of library when consumers have vastly different needs and just take the hit if having to do a Sourcegraph search for usages of some code. This search would need to be done to find all consumers of the code anyway if it was a library. So the end result is rarely different in my experience.
It works both ways
Someone modifies code thats used in both places and breaks othef thing
If you are looking for example into System Integration, Data Integration, ETL and so on, not using a canonical format from the beginning, will get you into the type of almost exponential grow in mappings between sources and targets.
https://www.bmc.com/blogs/canonical-data-model/
https://www.enterpriseintegrationpatterns.com/CanonicalDataM...
I do agree a lot of abstractions in C#/Java seems to be testing implementation stuff leaking into the abstraction layer. A lot of inversion of control in these languages seems purely to allow unit testing, which is kind of crazy.
Personally I prefer the "write everything in as functional a style as possible, then you'll need less IoC/DI". This can be done in C# and Java too, especially the modern versions.
Once is an incident. Deal with it.
Twice is a co-incident. Deal with it. But keep an eye out for it...
Third time? Ok, this needs properly sorting out.
This online chat had two functionalities, chat with a worker a and leave a message from worker with suggestions as to what to look at in response, there was no connection between these two functionalities specified and so my friend had written it without connection, it was difficult without doing a full rewrite to get state information from one part of the application to another one (this was written in JQuery)
Anyway, 6 months+ down the line it got respecified, now it needed shared state between the two parts of the application, which meant either significant rewrite or hacks, so hacks was chosen. Ugly hacks but worked (I think ugly hacks was the correct choice here definitely because chat application almost completely scrapped a year later for a bot)
After I was done I said "but why write it like that?" It was specified no state was needed between the two parts, "yeah but it should be obvious that is going to change, they would keep wanting to add functionality to it and probably share state as to the two communications channels"
tldr: there are some potential changes that seem more likely than others, and the architecture should take those potential changes into consideration.
You never know when you might need to change the implementation of how the "Fuzz" string is returned, so you need a FuzzStringReturner.
And you never know when you might need multiple different ways of returning "Fuzz", so you need a FuzzStringReturnerFactory.
And for SOLID it's important to separate concerns, so you want your FuzzStringReturnerFactory separate from your FuzzStringPrinterFactory.
And that barely scratches the surface of what you need!
Another note it's not what's the best SOLID design it's what that original dev thinks is the best SOLID design. SOLID in itself is loose enough that you can have designs that vary massively but are still technically SOLID.
Unfortunately that good dev is no longer employed at this company...
this.doFizzBuzz(TestConstants.INT_14, TestConstants._1_2_FIZZ_4_BUZZ_FIZZ_7_8_FIZZ_BUZZ_11_FIZZ_13_14);
Finding a good way to balance YAGNI with this-will-definitely-change-in-a-few-months-because-it-always-does is incredibly hard, and I've really appreciated working with engineers who make that prediction correctly.
As you get to learn more failure modes for software, you start to realize you can't plug all the holes in the dyke, not if you had absolute control of every hand on your team. You can stop four problems or you can hedge against twenty. The problem is that hedging is way harder to explain to people. It's how we ended up with unsatisfying concepts like 'code smells'. It's not evil, it might not even be that bad, but... don't do it anyway.
Is this a generalizable skill? To me, it feels like changes are more often driven by shifting business requirements and ephemeral victories of internal political battles rather than sound technical reasons.
The relevance here is that we can apply this concept in reverse. If we make something easy to change, is close to a two way door. Hence we reduce the time we need to spend on it's design/consideration/ etc.
Personally I like to write code that is more on the flexibler side to increase my optionality. I can then iterate faster throwing things at the wall and change my mind as needed. Of course this flexibility doesn't come for free. Overengineering and cost of carrying are real, so apply your best judgement.
The other big class of "one-way" decisions are with regards to code that live in environments you don't control, e.g. mobile and desktop apps.
One tip I would offer is when building something new, you should try and delay making one-way decisions as long as you can, until you have a clearer picture of how things should work.
Often the solution initially would have been to separate out the presentation side of the component from the behavioral wrapper that chooses what data needs to be shown / what actions are performed by interactions. By the time the component arrives at my lap (because I too need something same same but different), however, it has become a monstrosity that can take a long time to disentangle via ADD (anger driven development).
I think asking oneself a simple question such as "how would someone make this search box work with a different data source?" would probably result in components that are decomposed into simpler, smaller parts that allow for much easier reuse and adaptation.
On the flip side, I'm also of the belief that the second developer to touch a component is necessarily better equipped to answer that question, so the onus should probably be on them to make the proper generalizing changes.
(I'm still trying to figure out how to write a document that expresses this idea more concretely to my coworkers because it often isn't quite this simple..)
¯\_(ツ)_/¯
This.
Given a long enough timeline, pretty much all abstractions fail. People are too timid to replace them when they do, and given enough churn, the code gets out of hand.
- Like you've already said, prefer splitting components into purely presentational components("dumb components") and components with some logics ("smart components")
- If you are using design components, make sure to pass on those props. e.g. if you are using Chakra, pass BoxProps to <Box>.
- try to split out logic into hooks. This can be very specific to the current use case.
These aren't hard things to do but lets you quickly create a generic component by only changing the smart component/hooks or only reuse the dumb components with another specific hook, if the use case is a bit different.
I think the interactive nature of these things and years of 'training' that the average computer user has endured to expect how a search box behaves tends to hide the hidden complexity lurking in UI elements everywhere. Another great example is a <select> element.
And in the latter case, at least in my organization, we don’t often have hard “must meet” deadlines, but instead have more self-imposed deadlines that become externalized and concrete when these “deadlines” (aka ship date estimates) are communicated org wide.
So all I can figure to do is give zoom talks, write documentation that’s shared to all developers, and try to encourage coworkers to take the opportunity to push soft deadlines back if needed to pay down tech debt.
Business logic needs to change all the time, because businesses are always changing. This is why we separate it out cleanly, so it can change easily.
Know what type of code you're writing so you can plan and design appropriately.
This is like saying a good piece of furniture is easy to add to. I mean, maybe?
The trick is that writing code thats easy to understand often takes more time. Making code performant will often make it harder to read, and harder to change. Adding lots of features will make your code harder to change.
Its easy to point at the virtues of good code. And its easy to pick out some personal favorites. But the difference between an intermediate and expert programmer is knowing how (and when) to trade those values off against each other. When you're prototyping, write messy code that you can change easily. When you're writing a web browser, agility doesn't matter as much as security and performance. If lives depend on your code (eg in medical, rocketry, etc) then testing becomes a lot more important. Working with a lot of junior engineers? Try and write code they can understand and maintain more easily. And so on.
Its a fine thing to have a personal style when programming. But the mark of excellence is whether you can adapt your style to suit the actual problem you're trying to solve.
In practice you can get by with a wild collection if non-matching furniture. It will be non-asthetic but it will work.
Code projects are quite similar in that regard. On the other hand sometimes it will be such a poor fit that it starts breaking things. Does that also apply to furniture?
Perhaps if you put the bed too close to the closet you can no longer open its door all the way...
Then there are the myriad array of cabinet doors. And folks like heavy built-in cabinets, but Ikea ones are just fine. They typically have better hardware. But nobody wants to be the equivalent of an installer in software, it seems.
Since you said beds, consider getting the wrong size bed for a room. Or mismatched head and foot boards.
std::list calls malloc/free for every node instead of a bunch of them, expensive. Also they are doubly linked, for some applications a single-linked lists fit better.
std::vector<bool> lacks data() method, makes serializing/deserializing them prohibitively expensive.
Even something as simple as std::min / std::max for float and double types aren't using the correct implementation on AMD64, which is a single instruction like _mm_min_ss / _mm_max_sd.
I would add that sometimes leaving oneself room to expand/respond to changes is just what your code needs. Expansion points. Whatever you want to call it.
The maxim I use is, "avoid being overly specific." If you have polymorphism in your language the less you say about the type of a variable the more places it can be used and the more ways it can be composed with other functions. This requires a style of design that pushes side effects to the edges of the program (consequently where they're the easiest to change).
With this style of programming responding to change is straight-forward to reason about. No need for complicated indirection between objects and tracing behaviors through v-tables. If you are using OOP keep your data and behaviors separate.
The stuff that solidifies rarely changes. The stuff built on it changes a lot. And as time goes on you'll find that refactors will start pushing more upper layers down where they will eventually solidify.
Give me a definition of good code that applies to:
- the standard library
- a gui toolkit
- the kernel
- the apps built on top of vendor provided gui toolkits that change
- a web application backend
- a web application front-end
- a database
- more things I’m forgetting
MVP for business code is a great way to get the tool in front of the users and get traction, request for more work. Once you release your library, desire for changes basically drops to 0.
It's working. If it's clunky, the clunkiness just gets wrapped into a utility class somewhere deep in the belly your client application with about 1 commit change per year to change the copyright notice.
Similarly your corporate leverage falls to 0. You make a library to save people time, congrats you did it. Every update you ask people to do that does not bring new feature they need reduce your value. Good luck justifying a cosmetic change ROI.
The linked list module may have a poor interface or an awful bug with workaround. But you can’t change it until the next version of the language in 3 years because everyone relies on it. It’s not good, just a dependency. It needs to change and can’t. I want devs to embrace that changing heavily-relied upon things can be good even if it’s painful.
If you switch from mergesort to quicksort you don’t “refactor” or “extend” mergesort. You write quicksort and replace the calls of mergesort to quicksort.
Maybe. But on the other hand 99% of code is not good, and thus is more likely to need to change. And that is a reality that we need to deal with unfortunately.
The idea of making an abstract double entry accounting module that is extensible it's own thing is rare. It's probably Conway's law at play. There is no one responsible for doing so, the teams were set up with their goals and everyone shares that code.
depending on your work environment, good code may actually be bad code.
I am mostly a C++ developer but I have been on some Java projects recently, and I am a bit shocked by the "what if it changes?" culture. Lots of abstraction, weak coupling, design patterns, etc... It looks like a cult to the gang of four.
Of course, it is not exclusive to Java, and these patterns are here for a reason, but I have a feeling that Java developers tend to overdo it.
A language that evolves "is" the new code that is written in it, with deep legacy substrata written to previous versions. You can have a good top level but an embarrassing legacy. We should always strive to make our legacy embarrassing, because that marks improvement.
If ten-year-old code in your language is not an embarrassment, your language is stagnating.
The JVM is off course very clever and is, I'm sure, doing tons of shenanigans to reduce the cost, but that's not free, that's someone else investing tons of time and effort and complexity to reduce the cost of a fundamentally expensive operation.
You’re right about the “final” keyword being a placebo, but you got the rest exactly backwards.
The JVM is ridiculously aggressive in optimizing for throughout over latency: It assumes that everything is final and compiles the code with that assumption until proven otherwise. If it sees a method getting overridden, it will go back and recompile all the callers and everything that was incorrectly inlined.
A lot of Java code depends on this. For example if you only load one of several plugins at runtime, there’s no overhead vs implementing that plugin’s feature in the main code base.
But in real code you often have plenty of things like iterators or lambdas, and you'll have many of types of those. So the calls to them will be megamorphic and no JVM magic can do anything about it.
While in C++ world you'd use templates or in Rust you'd use traits, which are essentially zero cost, guaranteed.
Templates create more code
If the code becomes too large to fit in the cache, it becomes very slow
Consider the pre- Java 1.5 sort method:
Collections.sort(List list, Comparator comparator);
If you load more than one Comparator type, then the calls to comparator are megamorphic and devirtualization won't happen unless the whole sort is inlined.
In languages like C++, you'd make it a template and the compiler would always know the target type, so no need for virtual.
Don't know about harder to understand, the entire point is to remove confusing implementation details from callers.
In my experience enterprisy abstractions are a lot of motion without any progress. They impede change and stymie understanding.
The cynical part of me thinks that is the whole point.
The reality is, it is very far from free. Most Java developers are simply not aware of the real cost. Then they are surprised how the code gets 5x speedup and needs 20x less memory after rewriting it to Rust or C++.
This isn't just speculation about what the JVM does, you can examine the bytecode being generated by the JIT-process to verify whether this optimization happens.
Do you have real-world examples of this 5x speedup from this decade? 20x memory I can sort of see because the GC overhead can be pretty nasty in some edge cases, but I'd expect closer to 1.5-2x speedup from C++ if the Java code is anywhere near well written.
Does https://github.com/pkolaczk/latte count? Or the Optional cost described on my blog here: https://pkolaczk.github.io/overhead-of-optional/?
(I have more such examples, but many I can't share).
> you can examine the bytecode being generated by the JIT-process to verify whether this optimization happens.
And what do I do with that knowledge if it turns out the optimization didn't happen?
This is just Rust code. Where is the equivalent Java code?
Like the 50x-100x memory consumption is highly suspicious. If Java uses 50x the memory consumption compare to C++, how come I can allocate a long[SINT_MAX-10] on a system machine with 32 Gb of RAM? Shouldn't the process require of order 0.8 Tb of RAM if this statement is correct? Or can C++ allocate a 2 bn array of longs in 40 Mb of RAM? If so let me know, I would be very interested in using this novel compression technology.
> Or the Optional cost described on my blog here: https://pkolaczk.github.io/overhead-of-optional/?
Why aren't you using OptionalLong[1]? You shouldn't use Optional<Long>, that's never a good choice. At any rate, nobody should be claiming Java optionals are are free, they're a high level abstraction and absolutely do not belong in hot codepaths.
In general it's fairly easy to construct benchmarks that favor any particular language, which is why you constantly see these blog posts about how high level interpreted languages (JS, PHP, Haskell) are faster than C++.
You can easily construct "comparisons" that make JVM languages look superior to C++ as well, just carelessly allocate throwaway objects of different sizes and lifetimes (like you can in Java), oh no, why is C++ slowing down? Surely there's no heap fragmentation! That's a bad faith benchmark though. It doesn't really demonstrate anything other than that C++ following Java idioms isn't very good.
> And what do I do with that knowledge if it turns out the optimization didn't happen?
The way the JIT works is by aggressively overassuming, and then recompiling with more generalized interpretations of the code when assumptions turn out to be false. But the wider problems of compilers occasionally generating suboptimal instructions isn't something that is Java specific.
[1] https://docs.oracle.com/en/java/javase/12/docs/api/java.base...
1. In this particular case you might be lucky, because someone provided a hand-coded, specialized workaround. But that was not the purpose of that benchmark. And in bigger code bases you often are not that lucky or don't have time to roll your own, so you must rely on generic optimizations. Sure, you may get with Java quite close to C by forgetting OOP and implementing everything on ints or longs in a giant array. But that defeats the purpose of using Java; and that would make it lower-level and less productive than C.
2. Someone form the commenters on Reddit actually tried OptionalLong, and it did not help. See the comments section, there should be a link somewhere.
3. I can use this high-level abstraction in C++ at negligible cost in hot paths.
> This is just Rust code. Where is the equivalent Java code?
You probably won't find exactly equivalent code for software bigger than a tiny microbenchmark. The closest you can get are other tools built for similar purpose e.g. cassandra-stress or nosqlbench. I can assert you that the majority of CPU consumption in those benchmarking tools comes from the database driver, not the tool itself. And comparing tools using a well-optimized, battle tested Java driver with a similar tool using a C++ or Rust driver can already tell you something about the performance of those drivers. Generally I found all of the C++ drivers and the Rust driver for Cassandra are significantly more efficient than the Java one. Fortunately, outside of the area of benchmarking, that might not matter at all because in many cases it is the server that is the bottleneck. Actually all those drivers have excellent performance and have been optimized far more than typical application code out there.
> Like the 50x-100x memory consumption is highly suspicious.
This isn't a linear scaling factor. It applies to this particular case only. And the reason this number is so huge are: 1. the Rust tool runs in a fraction of memory that is needed even for the JVM alone; Rust has a very tiny runtime 2. the Java tools are configured for speed; so they don't even specify -Xmx and just let GC autotuning configure that. And I guess the GC overshoots by a large margin. because it often ends up at levels of ~1 GB. So it could be likely tuned down, but at the expense of speed.
More portable, yes, but it is complicated. Java runs on a VM, so it gets portability from here, if your platform runs the VM, it will run the project. However, as a user, I still had issues with using the right VM on the right version, OpenJDK and Oracle JDK are not completely interchangeable. Messing up with classpath and libraries too. Not so different from C actually, but at the JVM level instead of the platform, the advantage being that it is easier to switch JVM than to switch platform.
And most game consoles can’t run Java so they had to totally rewrite it there.
But they don’t have JREs even if they have the right kind of CPU in them.
Thanks!
I also disagree with the SOLID principles. KISS is more important than adding extra code and sacrificing performance to allow extension without touching the original source files. Unless you goal is explicitly that.
You're trying to write the simplest, most straight-forward encoding of the solution. If you can avoid duplication and make the code read well, you're golden.
People who develop web apps can go ahead and have this epiphany, but this obviously doesn't work where you don't have complete control over "redeploy", which is a large class of software.
I have seen cases where you go to pretty much the same effort as the "core" deployment, so the deployment benefits of the configurable option were fake but the complexity costs were real.
The intractable problem ends up being "fuck, half our code base implicitly depended on the current behavior and now we can't change the it without half our tests failing."
This is why 10,000 ft abstractions can sometimes be nice because now all your business logic exists in a fantasy world of interfaces you control.
Sort out your abstractions at a high level (auth, storage, routing, messaging, etc) and then write small programs to implement the logic. If one of them is wrong - redeploy.
There is some conversation here about the number of instances something has to happen before you should abstract it, which is a handy rule of thumb. You should also consider the tradeoff of complexity, sometimes even if you have 5, 10, 15 snippets of code that are almost the same you still don't need to abstract it, because the differences are not complex to manage, but an abstraction would be.
One of the best things about dynamic languages like Typescript is that in these languages you can avoid interface/implementation duality while still being able to mock or test code by using test-only runtime mutation of class instances or modules.
@Mock, @InjectMocks, and the ability to wire up an entire dependency tree has been something Typescripters have still not perfected like crusty Java devs.
You have a procedure or something that you want to test and it takes, as a parameter, a logging service? You don't want to instantiate a full logging service and set up the database, because that's heavyweight for a test and irrelevant for the particular test? Fine, you throw together a quick and dirty logger that answers the method `log` and pass that in instead. No need to know what the precise interface has to be, or implement or stub out all its other capabilities. You know it has a `log` method because the procedure under test uses it, so that's what you give your quick and dirty mock logger. No more, no less.
const instance = new MyClass()
instance.myMethod = () => getMockResult()
In nominally-typed languages with static type systems, it's more difficult to alter the behavior of specific instances of classes at runtime. Instead, convention is to declare an interface that specifies some set of methods, and then declare a class that implements the interface. Instead of using a concrete type in business logic, you use the interface type instead. Then, in your tests you can use a different class that also implements the interface:
interface MyInterface {
myMethod(): ResultType
}
class MyClass implements MyInterface {
myMethod() {
return new ResultType()
}
}
class MyInterfaceMock implements MyInterface {
private myMethodImpl: () => ResultType
constructor(myMethodImpl: () => ResultType) {
this.myMethodImpl = myMethodImpl
}
myMethod() {
return this.myMethodImpl()
}
}
const instance: MyInterface = new MyInterfaceMock(() => getMockResult())
As other commenters said, there are tools like Mockito that eliminate the need for this double-definition, and enable the same easy re-definition of method behavior at runtime. My point wasn't that is is impossible in Java or other static languages, just that one of the strengths of a more dynamic language is that flexible runtime behavior alteration is ~2 lines of code, versus the 39769 lines of code in eg Java's Mockito.
I wouldn't refer to overly generic code as easier to change.
I see this in a lot of contexts at work, not just defensive coding. Red tape that slows us down a lot, supposedly protecting us against unimaginably horrible things which no one can seem to articulate under questioning.
I mean, look how red that tape is! It must be protecting us against something pretty dangerous. Red means danger, right?
This is a bit sophisticated to teach junior developers, so we just teach them “consider the implications of your design decisions with regard to supporting future needs, including those not yet known.” Yes, you can certainly over-index on this dimension, but that doesn’t make it a useless or necessarily harmful consideration. (Not implying the article disagrees with this; it does appear to be satire)
Go figure that I’ve overheard and used “option select” in the context of technical decisions at work, among coworkers who play fighting games.
I may misunderstand your analogy here, but it seems to me that retaining optionality has a significant up-front cost here that may never be realized?
What up-front cost are you thinking of?
A non-sailing version might be say you’re on a bicycle, and you can drop down the mountain now and go lateral later, or go lateral now and drop down later, and either way you arrive at your destination after the same time and effort. Going lateral now retains optionality.
Very open to hearing better analogies for the same concept! Perhaps from the world of business?
So trying to do that first for gains you may never realize is not a great idea.
Like trying to drive your bike uphill so that may easily go downhill at some later point in time.
The biking example makes it clearer what you meant (to me anyhow).
Often the best way to design for change is to make it easy to edit the code, test it, commit, and deploy, but not everything is a web app.
I worked at a big company that assigned its summer interns to write an online sarcasm detector. At end of summer, they announced they had been completely successful. No one asked for evidence. Clearly the students had understood the assignment perfectly.
Anyway, it was said that this had been assigned. I never spoke to anyone actually involved. Or, admitted it.
In a business environment, Write code that is meant to be extended upon by people other than you.
It's not mindless tyranny, its good design.
I once encountered a 5k loc program designed to take the average of a series of Boolean values. The code had been designed such that the input data format could be changed etc etc. unfortunately, of the 5 metrics which could have ever been requested only 2 were implemented. It was to difficult to work with the code to implement the three others ( just finding where to implement them took 3 days).
Ultimately all the extra abstraction abstracted over the wrong things. The 5kloc project was replaced with a 100 line file that did exactly what was needed.
My general approach is to write my code in a way that could easily be turned into an interface once a second or third implementation needs to be introduced and hope a junior doesn’t come along and fuck it up in the meantime. I think one reason people go to the abstract interface early (when there is only one impl) is that they see it as a guard against someone else coming along and changing the well thought out layering. But it doesn’t work and just makes things harder to read and work with.
The top commenter says good code rarely needs to be changed. I think thats foolish. Good code is constantly changed, because its good enough it can be.
Historically successful protocols often have a basic feature level and later extend it with features that are not required (at the time) but improve functionality. All the more so when users with accounts need more features than federated (not authenticated) users from other platforms.
Even if you do want to target real mode DOS, good luck getting your modern app to fit in 64K. Heck, just upper-casing a Unicode string takes 640K.
I have written some DSP code that was portable between architectures that did not have same sized _char_. Thankfully it was almost 20 years ago and TMS320C55x that had 16-bit char and 16-bit int is AFAIK dead.
I know. But you're not likely to port any apps between microcontrollers, DSPs, and general purpose machines.
> Also, the size of 'long int' is definitely not constant if your code needs to be portable between Windows and something else.
It's also not portable between Linux and Mac OSX. This makes `long int` a completely useless type. Use `int` and `long long`.
> that did not have same sized _char_
I remember one person who responded to me about a DSP that had sizeof(char)==32, and how it was wonderful that the C Standard accommodated that so code could be portable.
I challenged him to port the C implementation of `diff` to it and see how far he gets with it. I predicted total failure :-)
The C and C++ standards would do the programming world a favor by standardizing on:
1. 2's complement
2. fixed sizes for char, short, int and long
3. dumping any character sets other than Unicode
Machines that don't support that will require a customized compiler anyway, and it's very unlikely any code will be portable to it without significant rewrite.
The support for 32-bit char doesn't automatically make code portable between architectures with different char sizes. But it's what makes it possible to write a C compiler at all for those weird architectures. It certainly doesn't make code that assumes things portable to architectures where those assumptions do not hold.
> The C and C++ standards would do the programming world a favor by standardizing on: 1. 2's complement 2. fixed sizes for char, short, int and long 3. dumping any character sets other than Unicode
This would be a great favour to embedded developers everywhere, because it would finally free us from the C legacy. Rust and Zig look promising, and at some point I even thought D might work but now I understand why it wouldn't. I wonder if you're aware of the standard sized type aliases int8_t, int16_t etc and what's your opinion of them.
Only if one is pedantic. There's no practical problem at all customizing C compiler semantics for weird architectures. After all, everybody did it for DOS C compilers.
> I even thought D might work but now I understand why it wouldn't
People do use it for embedded work. I don't know why you wouldn't think it would work.
> I wonder if you're aware of the standard sized type aliases int8_t, int16_t etc
I am. After all, I wrote stdint.h for Digital Mars C.
> and what's your opinion of them.
There are three of each:
typedef long int32_t;
typedef long int_least32_t;
typedef long int_fast32_t;
2. People have endless trouble with C's implicit integral conversions. This makes it combinatorically much worse.
3. int32_t makes sense for the first hour. Then it become annoying, and looks ugly. `int` is much beter.
4. `int` is 32 bits anyway. No point in bothering with stdint.h.
Resorting to non-standard extensions locks you in with that specific compiler. This is the exact reason why standards exist in the first place.
> People do use it for embedded work. I don't know why you wouldn't think it would work.
The lead developer seems to have strong knee-jerk reactions to things that he does not understand and limited understanding of what microcontrollers are or what embedded software does. Who really cares about porting diff to a system that doesn't have filesystem or text console?
I agree that integral type promotions are a great way to shoot oneself in the foot, but the other explanations are not really convincing. If you did read the comments you are responding to, you should already know that int is not always 32 bits.
As for variable sized int types, it’s a nice idea but it’s really unlikely your C program is actually portable across them. You haven’t got good enough test coverage for one thing. If someone wants to do that in a new language users should be required to declare which sizes of char/long they actually expect to work.
byte = 8 bits
short = 16 bits
int = 32 bits
long = 64 bits
add `u` prefix for unsigned version
The only variable size is size_t and ptrdiff_t, but we're kinda stuck there for obvious reasons.
There have been some issues with printf formats mismatching when moving D code between systems, but we solved that by adding a diagnostic to the compiler to scan the printf format against the argument list and tell you how to fix the format.
I think engines and libraries are the ultimate solution if you want to program defensively.
For some people, making things easy yo change means making them more complicate, adding more layers of abstractions and patterns.
I am using a more Data Oriented Approach [1] in which I keep the data separated from code, try to use immutable data structures and try to use methods and functions with as little side affects as possible. I am also trying to architect the software to be modular. I.e. split the code in classes grouped by functionalities, split it in different projects.
And I have success at this even if I am using a language that's very object oriented and being part of a community who was used to put a very high price on object orientation, abstraction and design patterns. I'm referring to C#/.Net.
[1] https://www.manning.com/books/data-oriented-programming
PS. This book and some articles and videos made by others on Data Oriented Programming can be huge helpers and big time savers for me. I'm no longer thinking in objects, I'm thinking in data and functions which process the data.
I'm no longer a prisoner in the Kingdom of Nouns. [2]
[2] http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
Wrapping external libraries ? It depends on the level of maturity of the library. I have seen HTTP libraries change their API often enough for a long time. I wrapped them because it did _change_. (Although I'd rather have fetch_my_foo wrapping calls to the lib that does http call, rather than having fetch_my_foo calling a wrapper that calls a lib)
Wrapping input / output ? That can have _some_ uses in testing (Although it might be better to have unwrapped code doing the I/O, calling code that does the logic.)
Hiding a class behind an interface that will only have a single Impl ? It the class is doing I/O, it might very well need at least a test implémentation.
'new FileInputStream(new Buffered stream(new Buffer(new Encoding( new ...' ? Yeah, this is typically the case where a proper API need to have 'File.read("xxx")' from the get go rather than force people to either wrap or share a wrapper.
Etc,etc...
If it turns out the possible future user-cases never materialize, we still benefit from the easy to understand code when we need to fix bugs in it.
There are two different types of reuse:
a) Supporting multiple use-cases of the same code, with different parameters.
b) Modifying the code to do something else than it does currently.
If the code is easy to understand it is easy to change for both cases. But if you try to make it ready for multiple use-cases from the start it becomes much harder to change it since it is already more complicated than it needs to be, to support just the initial user-case.
There is no Silver Bullet. Code is our tool for dealing with complexity. But it does not remove complexity. And more code you create more complexity you will have.
Changed my perspective on this newfound tool I'd learned to use called "indirection".
My favorite quote is something like "don't waste 10 minutes now to save yourself 2 minutes later".
A "Business Object interface" is implemented by a "Business Object implementation" which delegates its method calls to a "Data Access Object interface which defines exactly the same methods as the Business Object interface" which then is implemented by a "Data Access Object implementation" which then does a simple SQL query.
You can argue that the DAO has a right to exist. After all, you are separating concerns and organizing your codebase. The BO only exists to make me suffer through 4 layers of indirection. When I write code I just drop the DAO interface and call the original class DAO. If I ever need to migrate to something else, sure, I could just rename that damn thing to DAOImpl and create an interface with the same name as the original class and the same methods. I never had to.
One can way overdo even "door opening" and create pain and complexity for users.
As for the code ..... I like to be able to read it. I prefer not to have to jump around every 5 seconds if possible. I like it to be easy to write tests for. If it's easy to test and I have lots of tests then changing it shouldn't be too stressful.
I prefer to do things the simplest way until I have a good reason why it's not enough.
Or add "I" as a prefix to the interface's name. I always deflect this pattern of doubling code with: "what's the benefit of having it like that?" or "is this benefit worth the cost?".
As for the main question: my reply is "I'll take responsibility for that and refactor this personally.".
My experience is that good and bad code takes roughly the same time to write - the latter is just hard/impossible to modify once you delivered the feature originally requested. Code with unnecessary layers is of course hard to read and thus modify.
YAGNI indeed.
For those who didn't get it... This article is a sly dig on fresh-graduated architecture astronauts. The tone is absolutely pitch-perfect, giving nothing away to anyone who is not entirely sure it is a jape, until the last line.
Priceless.
You can ask that question about anything, but the answer should be different depending on the actual likelihood of change.
There's a few things that need to be designed in from the beginning, like security, localization, and error handling, but a lot of other stuff can be hardcoded or deferred.
In my experience, every project is different, and "hard and fast" rules are to be avoided, if possible.
Reminds me of the classic joke The Toaster (and it is "classic." That specification in the second-from-last paragraph was supposed to be over-the-top excessive):
Once upon a time, in a kingdom not far from here, a king summoned two of his advisors for a test. He showed them both a shiny metal box with two slots in the top, a control knob, and a lever. "What do you think this is?"
One advisor, an engineer, answered first. "It is a toaster," he said. The king asked, "How would you design an embedded computer for it?" The engineer replied, "Using a four-bit microcontroller, I would write a simple program that reads the darkness knob and quantizes its position to one of 16 shades of darkness, from snow white to coal black. The program would use that darkness level as the index to a 16-element table of initial timer values. Then it would turn on the heating elements and start the timer with the initial value selected from the table. At the end of the time delay, it would turn off the heat and pop up the toast. Come back next week, and I'll show you a working prototype."
The second advisor, a computer scientist, immediately recognized the danger of such short-sighted thinking. He said, "Toasters don't just turn bread into toast, they are also used to warm frozen waffles. What you see before you is really a breakfast food cooker. As the subjects of your kingdom become more sophisticated, they will demand more capabilities. They will need a breakfast food cooker that can also cook sausage, fry bacon, and make scrambled eggs. A toaster that only makes toast will soon be obsolete. If we don't look to the future, we will have to completely redesign the toaster in just a few years."
"With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialize this class into subclasses: grains, pork, and poultry. The specialization process should be repeated with grains divided into toast, muffins, pancakes, and waffles; pork divided into sausage, links, and bacon; and poultry divided into scrambled eggs, hard-boiled eggs, poached eggs, fried eggs, and various omelet classes."
"The ham and cheese omelet class is worth special attention because it must inherit characteristics from the pork, dairy, and poultry classes. Thus, we see that the problem cannot be properly solved without multiple inheritance. At run time, the program must create the proper object and send a message to the object that says, 'Cook yourself.' The semantics of this message depend, of course, on the kind of object, so they have a different meaning to a piece of toast than to scrambled eggs."
"Reviewing the process so far, we see that the analysis phase has revealed that the primary requirement is to cook any kind of breakfast food. In the design phase, we have discovered some derived requirements. Specifically, we need an object-oriented language with multiple inheritance. Of course, users don't want the eggs to get cold while the bacon is frying, so concurrent processing is required, too."
"We must not forget the user interface. The lever that lowers the food lacks versatility, and the darkness knob is confusing. Users won't buy the product unless it has a user-friendly, graphical interface. When the breakfast cooker is plugged in, users should see a cowboy boot on the screen. Users click on it, and the message 'Booting UNIX v. 8.3' appears on the screen. (UNIX 8.3 should be out by the time the product gets to the market.) Users can pull down a menu and click on the foods they want to cook."
"Having made the wise decision of specifying the software first in the design phase, all that remains is to pick an adequate hardware platform for the implementation phase. An Intel 80386 with 8MB of memory, a 30MB hard disk, and a VGA monitor should be sufficient. If you select a multitasking, object oriented language that supports multiple inheritance and has a built-in GUI, writing the program will be a snap. (Imagine the difficulty we would have had if we had foolishly allowed a hardware-first design strategy to lock us into a four-bit microcontroller!)."
The king had the computer scientist thrown in the moat, and they all lived happily ever after."How would you put a microcontroller in this?" is a stupid question without knowing why you'd want it there in the first place. It's an answer in search of a question.
Dump the king in the moat and they'd all live happily ever after, too.
But you said "instead". If you dumped only the king in the moat, then the computer scientist would still be running around loose!
Pretty sure it has way better embedded computer than i386/8MB RAM / 30MB storage / VGA.
We have too many repos that have this behaviour. Every time I've raised it as pointless I get "You just don't understand the power of DI". I guess not.
If it's longer than 2 lines, it belongs in a function.
(Really guys?)
I can appreciate a few layers of indirection as being useful for maintenance later on - handling new corner cases by giving you some opportunities for making the most minimal possible change.
There's a diminishing return after a few layers, and then of course you start to make maintenance itself harder by making it harder to understand and navigate.
Most abstractions are premature and the world always changes against initial assumptions. So the answer to “what if it changes?” is it most certainly will and in a way inconsistent with your cute abstraction.
but... devil is in the details, and to a certain degree this keeps things from getting too concrete to the point you can't solve the problem.
I think "prototype to determine it solves the immediate problem, but keep an eye on change as you do it" is far better advice, it keeps the horse in front of the cart.
Knowing that abstraction is going to add value vs. speculating that it will? That should be the difference between adding the extra investment upfront vs. inciting YAGNI (you aint gonna need it).
The footprint of “times you thought you didn’t need it but actually did” is extremely small. Also those are called “learning opportunities” not “mistakes”.
This article is ridiculous.
Keep them in check!
Code can be viewed as disposable as long as the above two concerns are addressed.
Asking questions about specific things, like numbers and hardware is in fact relevant.
Also, future-proofing is one of the worst and most difficult to avoid mistake you can make as a novice or intermediate dev.
"Shy away from numbers": I'm writing a calculator!
"concrete analysis": The intersection of Civ Eng and Maths?
"Good engineers": Hire estimators. An Estimator is often an Engineer (Chartered) and they estimate. The Estimator is generally rather better than the Engineer in estimating, because it is their specialisation.
Of course, I jest a bit but the essay was a bit slack in my estimation. We all have to deal with change on a far more granular basis than daily or even hourly. The world is a fluid environment rather than a static place and we have to live with that and we do quite routinely.
What I think our putative expert on change is describing is an approach for dealing with unexpected change. However, I think we deal with unexpected changes all the time and we do it quite well - our senses and abilities show that: Think about how complicated driving a car is.
Is it just snark? Or maybe the legacy of using a metric butt ton of reflective magic where interfaces with only one concrete implementation were common, cos Spring?
But yes, I see your point about snark / mud slinging. (The best mud you can sling back at C#: "You didn't have solid UNIX support for 15 years".) I saw the same between Perl and Python people 20 years ago. Being "fluent" in both, I never understood the fuss. They felt so similar, except syntax. You could write imperative code that looked and worked the same...
Finally, to me, the whole point of interface with "single" implementation is to easily facilitate mocking frameworks, like Java Mockito. (I am sure C# has something similar by 2022.) When the mock is created, byte code generates an ephemeral 2nd implementation. I never used Spring Framework much, but I think I can see what you mean when using @Autowire annotation constructors with interface type arguments. Spring can easily guess the correct implementation to inject.
And people that implement only the specific version end up having to implement the general version anyway.
If you write the system in a way where parts are decoupled and understandable, they can easily be replaced/modified when circumstances change... Because they always do...
Well things changed. Now what?
- What if it doesn't?
You shouldn’t spend a bunch of time preparing for something that never comes, but you should consider which scenarios would leave you totally screwed.
The reason I’m asking you, in this code review, “what if it changes?” is not because I’m infected with enterprisitis and must overcomplicate every system. It’s because I fear the answer to “what if it changes” is “this software, and everything that gets built to rely upon it over the next year, will need to be rewritten from scratch”.
And I would rather that we not take that bet without thinking through the odds.