'SOLID': Five Principles for Object-Oriented Software Quality.

In Object-Oriented Programming & Design, SOLID is a mnemonic acronym for five principles intended to make source code & design more understandable, flexible, and maintainable.

This means faster software construction/modification/debugging and lower overall project's costs (programmers are paid for their work-hours).

Software engineer and instructor Robert C. Martin introduced the basic principles of SOLID design in his 2000 paper: 'Design Principles and Design Patterns about software rot'. The SOLID acronym was coined around 2004 by Michael Feathers.


1. Single responsibility principle.

Every class should have only one responsibility, which means that a class should be responsible for only ONE 'thing'.

Importance:

Maintainability: When classes have a single, well-defined responsibility, they're easier to understand and modify.
Testability: It's easier to write unit tests for classes with a single focus.
Flexibility: Changes to one responsibility don't affect unrelated parts of the system.


2. Open–closed principle.

The open–closed principle (OCP) states that software entities should be open for extension, but closed for modification.

In other words, when we define a subclass, we can ask for less or same (less or same preconditions, as defined in class/method contract), and/or provide more or same (we still must provide what is defined in contract at the minimum, but we can also provide more).

Importance:

Extensibility: New features can be added without modifying existing code.
Stability: Reduces the risk of introducing bugs when making changes.
Flexibility: Adapts to changing requirements more easily.


3. Liskov substitution principle.

LSP requirement states that we must ensure that it's possible for a class to be replaced by any of its children (subclasses). Children classes inherit parent's behaviours, MUST NOT break the contract defined for the parent's class.

Importance:

Polymorphism: Enables the use of polymorphic behavior, making code more flexible and reusable.
Reliability: Ensures that subclasses adhere to the contract defined by the superclass.
Predictability: Guarantees that replacing a superclass object with a subclass object won't break the program.


4. Interface segregation principle.

The interface segregation principle (ISP) states that no code should be forced to depend on methods it does not use. ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.

Importance:

Decoupling: Reduces dependencies between classes, making the code more modular and maintainable.
Flexibility: Allows for more targeted implementations of interfaces.
Avoids unnecessary dependencies: Clients don't have to depend on methods they don't use.


5. Dependency inversion principle.

The dependency inversion principle (DIP) states to depend upon abstractions, not upon concretes.

Importance:

Loose coupling: Reduces dependencies between modules, making the code more flexible and easier to test.
Flexibility: Enables changes to implementations without affecting clients.
Maintainability: Makes code easier to understand and modify.


See also:
> [ Design by Contract ],
> [ A few thoughts on code quality... ],
> [ Software Development & Quality ].

Advanced Mathematics & Software Tools.

... there are many tools.

i think that Skilled Mathemathicians solve challenging problems, far quicker, far more precisely than less skilled mathematicians and/or computer programmers.

i suspect that using Basic Tools with Abstract Methods of Advanced Mathematics can outperform crude software automations by far.

... i think Knowledges, Theories, Experiences, Theorems, Proofs, Lemmas, etc. - are also Tools, 'Mental Tools'.

... i think not only Strict Sciences - as for example: Mathematics, Computer Sciences, etc. - can have 'Mental Tools'.

... can 'complex integrals' be solved better using Algebraic Structures as Rings, Groups, etc ... with/or without other Mathematics Tools ?

... i supsect it's possible & efficient.

... etc.

There are Software Tools as Wolfram Mathematica, MathWorks MatLab, Microsoft Excel, probably more.

... i know so little, but i suspect that there are 'extension points', 'plugins', 'scripts', etc.

... should we investigate?


... i think Wolfram Alpha should be mentioned as well, it's more than 'Mathematics Search / Computation Engine'.

'Memory Map'.

... there are abstraction levels, high & low.

High abstraction levels are useful to plan, to experiment, to prototype, to handle complexity, ... to implement as well.

Low abstraction levels are useful foundation, allow to use hardware extremely efficiently, but usually costs are too extreme, costs measured in time, money & other resources.

... years ago a friend borrowed me 'Atari ST Memory Map'. More than list of memory adressess, where to put which digit so certain results can be achieved.

... if i remember correctly, it was a lot of theory and graphical models, not only 'electronic circuits', also theoretical-scientific models, explaining theory that resulted in many electronic circuits, and many other solutions - both hardware and software.

'High abstraction level approach to low abstraction level solutions'.

... why i inform about this on Project Wraithstar?

... it's just an idea to consider - should we - including me, or without me - serve society that way, as well?

Success Metrics & Risk Management in Software Development.

Software projects are considered success when:
1. Completed on time,
2. Without exceeding resources budget.

In software development there are many unknown factors.

Developers do not know which software parts work well with which software/hardware parts.

In theory, anything can be done - but at differing time/resource costs.

Worst risks to time/resources should be addressed first:
1. Business/Development Team should organize a meeting and consider dangers/risks - not only from technological/scientific perspective,
2. Dangers/Risks should be analyzed and prioritized, from worst to least,
3. Unknown factors are risks as well, the less we know - the worse risk/danger potential,
4. Research & Prototyping are tools for assessing whether something can be done within given time/resources budget costraints. This should be one of the first phases of development.

Without these steps, unhandled risks can backfire in form of excess of resources needed, and/or in form of software development time exceeding the deadline(s).

As time flows, reality changes and customer requirements might change as well.

This is also risk, usually handled by extra time and resources allocation to project's total costs - as well as by adopting iterative development methods / as opposed to outdated 'waterfall' model, in which customers' requirement changes are not allowed by business contract /.

High quality projects should also offer 'limited warranty' time - where bugfixing and minor corrections are included in project's cost, for a given time - after closing the project.

Software quality procedures allow for faster and less expensive changes - both bugfixing and functionality changes - but customers usually do not know how to assess software's quality, and prefer to not overinvest in quality procedures they can't understand.

'Immobilizer' Software Protection Method.

... i got a hint of this secret high-tech project during my professional career.

Basics of making it work are:
- Connection to server(s). Without it software/hardware 'freezes' and activity is logged in persistent memory.
- Part of code downloading from server.
- Cooperation with a detective agency, in case of suspicious activity detected by AI.

Breaking it is hard, requires reverse-engineering and provides only a 'snapshot' of software, denying updates.

Perhaps using Events is a good idea for decoupling objects and propagating lockdown state across parts of the protected application.


--
Obfuscators are also good tools that help to protect software.

Software Development & Quality.

Introduction.

There are many methods for ensuring that software development proceeds smoothly, and there are methods for ensuring and measuring software artifacts' quality.

Artifacts are documents:
- design model,
- application code,
- automated tests code,
- documentation,
- configuration files,
- resource files as art or other data,
- ...


Code's Quality.

For a code quality's practices, see if You wish:
- A few thoughts on code quality...


Teamwork vs. Showoff.

Teamwork is Professional, needless showoff is NOT Professional.

Code should be written & documented in a simple way, so other co-workers can understand it with ease.

This friendly approach - of making teamwork easier helps the most newcomers - either beginner programmers, or programmers who worked with different Programming Language(s), Tools, Ecosystem, Technology(-ies).


Automated Testing.

For automated testing article, see if You wish:
- Automated Tests.


Design & Modelling.

Software models, often presented in a graphical way, are tools to look at software's design from a 'bird's view', to grasp whole picture.

Software modelling and design's goal is to abstract & simplify project.

Designs should be as simple and as abstract as possible - as this allows for easier code modifications as reality and customer's needs change.

... but of course modelling a single object with name 'idea' is too unreasonable interpretation of above words.

There are 'views' of a model as well - each view serves a purpose - each of views is a transformed model, both reduced and filled with details, to emphasize it's purpose.

For example we can have model consisting of every of car's parts, then we can produce a view of engine - fuel interaction. Unneccessary parts for this view are omitted, and more details about heat, and other aspects can be provided in view's documentation.

Models and views can be more or less exhaustive and detailed, and always should be unambiguous.