This code tends to be complicated because it is sometimes very abstracted and is hard to be understood at the beginning this arises due to the fact that it is only pure abstraction, the base in reality and business logic being performed in the code presented 1 from this reason this code is not expected to be changed once tested. Connecting code now here I believe stands the problem.This code basically represents the code that actually does the functional stuff, described in requirements. Micro-Modules which are hooked up in the micro-framework: these modules are easy to be understood, developed and maintained as single units.I believe I tend to write code overly abstracted and I don't know how good is it I often tend to write it like it is some kind of a micro-framework, which consists of two parts:
SOLVE ANY PROBLEM WITH INDIRECTION HOW TO
But where should this abstraction stop? How to make the trade-off between abstraction and all it's benefits (flexibility, ease of changing etc.) and ease of understanding the code and all it's benefits.
As programmers I feel that our goal is to provide good abstractions on the given domain model and business logic.
0 kommentar(er)
