Inheritance vs Composition
How code and data is structured factors into resilence to change over time
Delta T can have lesser
or greater complexity creep
Dependent on choices in code and contracts created
All Objects Dependent on Parent Object is Problematic with Greater Change in Time
ClassA
ClassB,CLassC,ClassD extends ClassA
if ClassC requires changes to ClassA then ClassB can be effected in non ideal ways
The interdepedent nature of ClassB, ClassC, and ClassD does not lend itself well to reliance on a central piece that could require changes in unseen ways.
Imagine another Business, or Business Unit owns ClassA, potential for limited to reliance upon that Business unit in Non Ideals that lags deliveries, possibly in ways that lead to be fired due to your Business, or Business Unit unable to make swift modifications to how a piece that you are reliant upon works. Reliance is less than an ideal amplifier.
Reusable matters when creating projects.
Able to change this without affecting that matters when creating projects.
Data Contracts are Powerful, functionality contracts have potential for not always being enabling.
How things in a code base are connected matters. Private vs Public exists for a reason.
Imagine Creating a Circuit Design with Inheritance? CircuitB, CircuitC, and CircuitD all depend on CircuitBoardA.
If CircuitBoardA has a particular capacitor that is used for CircuitC that does not work for CircuitB, now there is Complexity Created due to each boards not having a component they can easily replace.
Components can be tightly coupled vs loosely coupled.
Able to perceive and project how systems will change over time is far from a given. Developers make choices, then future developers are dependent upon those choices in non ideal ways. Over time developers can learn ways to refine design does not equal initial design always suits long term ideally.
A little extra cost upfront with less reliance can go a long way in making certain features more easily changeable for others in the future.
Don’t Repeat Yourself (DRY method) is useful for reuse. Reuse creates reliance many times in non ideal ways.
Include a new Open Source project in code base? Will the Open Source project be protected, funded?
How developers are protected over time factors into continued adoption, future adoption of projects.
Clarity Upfront goes a long way in ability to Debug problems later. Debugging problems seen as will be simple easy, not always true. Investment in tools and systems that allow performance known upfront factors into ability to maintain performant code. Tool that is easy to use matters. Readability in future factors into ability to modify, ability to modify factors into usefulness.
Like a gear you can easily see the teeth in a watch, vs partially obfuscated in way that makes comprehension of system design. Can’t understand the watch and have something to deliver swiftly, high potential for have to buy a new watch to get the job done.
Obfuscation early, reduced naming length can lead to speed initially. What gets a product to market has potential to not always sustain it long term.
I like acronyms, acronyms can complicate things in a way that obfuscates.
I like full names, full names too long can complicate things in a way that obfuscates.
Two methods lf(F f) vs loadFile(File file). When there are many methods like lf and no acronym decode tables provided that can be intimidating. Has potential for creating non ideal reliance upon a single employee. Crucial to the team, only one that can decode gets hit by a bus is a possible problem. Likely to get hit by a bus? No. Likely for another amazing corporation to see their talent when you are not able to ideally cover your bases? Yes
Exercise in Readable Puzzle Pieces and Time.
Inheritance, kind of like maintaining code someone else has written. The past wrote it, now you are dependent upon it.
Past has tendency to create non ideal reliance for Future dependent upon limited visibility.
loadFile(File file) vs loadThisFileForThisComponentOnThisDayAtThisSecondAndNoOtherTime(File myFileThatIsUsingReallyLongTimeDelayingObfuscatingNamingPatterns)
Passive aggression possible from developers thrown off project possible? Yes
Potential for non ideal don’t step on the crack turned up? Yes
Problem solving rules seen as 100% throughput is not always wise. Ideally we would like to say do this in every case and not that, and that does not always amp ideally.
Best Practices can be Iffy? Yes
High Voltage gloves for all circuits? Sounds like a good idea.
Motorcycle helmets required for all? Sounds like a good idea.
Potential for all Car Drivers upsold to have to wear Motorcycle Helmets? Reduces potential for concussion in crashes, not consider the option?
Working on low voltage circuit with giant rubber gloves equals ideal dexterity? Circuit designer gets thrown on street with Hypothermia not ideal Throughput.
Throughput and Practical factors into use.
My Tech Blog 