SayPro How to think about the design of a program

All programs transform input into output, even if that input was hard-coded into the source at design-time. It’s obvious enough to be forgotten and programmers can get so lost in the fuss of implementing features that they forget what the real purpose of the program was. Proper design can help you and your team mates avoid losing sight of the real goal.The code that does the conversion is called the business logic. The business logic will act on data structures called the model. Your program will need to convert (or "deserialize") its input into the model, transform it, and then serialize the model into output. The model will be whatever makes it easiest to perform the transformation and does not need to resemble what the user thinks of the data as. For example, a calculator converts decimal numbers into binary, performs arithmetic on them there, and then converts the binary back into decimal. The binary representation of the decimal numbers is the calculator’s model.Everything else is called overhead, and that will be code that implements the user interface, sanitizes the input, creates connections to services, allocates and disposes of memory, implements higher-level data structures like trees and lists and so-on. One of your goals will be to separate the overhead from the business logic so that you can make changes to one without having to modify the other.Some mistakes to avoid at this stage:

1. Don’t create a class or module called "Business Logic" or similar. It shouldn’t be a black-box. Later I’ll discuss how to structure this code
2. Don’t put business logic in a library1. You’ll want the ability to change it more often than the overhead, and libraries tend to get linked to other programs–multiplying the consequences of changing it
3. Don’t put business logic or overhead into the model unless it’s only enforcing constraints. The code that defines the model should expose some interfaces that let you attach what you need. More on that later

Some of the things that you can include in the model is code that enforces meaningful relationships. So if your genology program has a "Person" class with an "Offspring" collection then you should include code in the model that prevents a person from being their own grandparent. But the function to discover cousin relationships in a family tree is business logic and doesn’t belong in the model. Although it might make sense that you can’t be your own cousin, and that this rule could be enforced in the model, you also need to draw a line between what enforcement is necessary to prevent common bugs and what’s going to create complex bugs through mazes of logic that are difficult to follow.1 – "Anything Is Appropriate As Long As You Know What you’re Doing." One man’s business logic is another man’s overhead, and your project might be packaged as a library to be consumed by a bigger system. This rule is meant to apply to the point you’re at in the food chain.Please visit our website at www.saypro.online Email: info@sayro.online Call: + 27 (0) 11 071 1903 Email: info@saypro.online Tel: + 27 11 071 1903 WhatsApp: + 27 84 313 7407. Comment below for any questions and feedback. For SayPro Courses, SayPro Jobs, SayPro Community Development, SayPro Products, SayPro Services, SayPro Consulting, and SayPro Advisory visit our website to www.saypro.online