I think the problem is not OOP - the author approached the problem bottom-up, they were trying to foresee usage for code they were writing. The resulting code is a bit of a mess, not OOP (there’s even instanceof) Instead we should start with the usage, with the code creating the value and then filling in the details. In this problem, if we choose to simulate the circuit I would start with the simulator code, introducing abstractions for components only if it would help the simulator.
I liked the demonstration of this approach in Chapter 6 of Robert C. Martin’s Agile Software Development: Principles, Patterns and Practices. It’s available online here:
I found the book Growing Object-Oriented Software Guided by Tests to be very inspiring. The book demonstrates how to evolve the code architecture, how and when to add new concepts and abstractions, how to listen to the tests, when to refactor etc. The tech in the examples is dated, but the gist of the book is very relevant.
Another classics are:
- Working effectively with legacy code
- Refactoring: Improving the Design of Existing Code
If you are reading papers on water softeners you might already know everything this video contains. For me it was a good intro to the topic of good water for making coffee: https://youtu.be/jfElZfrmlRs
"without your knowledge"... is there a way to check if my IP was participating in the DDoS? If they are filtering the traffic, they might be able to create a list of IPs that I can check. Or perhaps, an IP can be associated with a contact info so the if any of my devices would be infected and participate in DDoS, I would get notified by the victim and could take action.