I had idea in Mind, idea about storing numbers in computer memory in form of numerator and denominator / pl: 'licznik i mianownik' /, in an attempt to simplify precise calculations.
I wrote some code to factor numbers, to find prime factors of a number / pl: 'rozkład liczby na czynniki pierwsze' /.
But this code does more than just determining if number is prime, and if not - finding prime factors of this number. It stores paths and partial calculations, it gives not only one solution, but all of possible solutions, that perhaps can be used and reused in creative ways.
Then I had another idea - what if numbers were stored in such form, in form of factorization tree. Perhaps adding trees, or other operations on factorization trees would allow for some swift, abstract calculations.
Then I remembered Geometry with Linear Algbera, and neutral elements of operations on structures such as Groups, Rings and Fields / pl: 'Grupy, Pierścienie i Ciała' /.
What kind of FactorizationTree would be a neutral element of FactorizationTrees' Addition?
How about Multiplying FactorizationTrees?
I'll admit that most of this is just musings and considerings, I admit that I let my imagination run wild this time.
This blog has a place for ideas exploration, after all.
I might need to research following topics:
- Abstract Algebra / also known as Modern Algebra /,
/ Downloaded an ebook in .pdf file format /,
/ Polish edition of this book was published by WNT: 'Wydawnictwa Naukowo-Techniczne',
my favourite scientific & technical books publisher;
mostly that's why I chose this book over others, looked at table of contents list too;
WNT-published books are often recommended by Warsaw University as well;
Ebooks are more eco-friendly than printed books, and a smartphone is enough to read these /,
- Group Theory,
- Ring Theory,
- Field Theory,
- Inverse element / pl: 'element odwrotny' /,
- Binary operation / pl: 'działanie binarne' /,
- Homomorphism / pl: 'homomorfizm' /,
- Isomorphism / pl: 'izomorfizm' /.
/ TO BE CONTINUED, HOPEFULLY. /
Thursday, 16 April 2026
Tuesday, 31 March 2026
Public Internet vs. Private, Leased Lines.
/ to be done. /
Things to be considered:
1. Communication speed (especially minimal guaranteed speed),
2. Communication Security (DDOS, Sniffing/MITM by insider threats in public internet, hacking the internet core (hard to hack, but still possible), attacks on DNS services in public internet and other routing attacks, passive (sniffing) and active (MITM) wiretapping in both public internet and private lines, perhaps more; importance of strong encryption (not only key length), routing/traffic monitoring, and endpoint security).
3. Costs.
4. Other limits (private connection only between two endpoints per line, vs possible connection to any endpoint available in the public internet from our endpoint in classic, broadband internet).
I don't want to dig too deep into technical details. Curious readers can do their own research on such.
I want this article to be fairly abstract, but still precise and correct.
Things to be considered:
1. Communication speed (especially minimal guaranteed speed),
2. Communication Security (DDOS, Sniffing/MITM by insider threats in public internet, hacking the internet core (hard to hack, but still possible), attacks on DNS services in public internet and other routing attacks, passive (sniffing) and active (MITM) wiretapping in both public internet and private lines, perhaps more; importance of strong encryption (not only key length), routing/traffic monitoring, and endpoint security).
3. Costs.
4. Other limits (private connection only between two endpoints per line, vs possible connection to any endpoint available in the public internet from our endpoint in classic, broadband internet).
I don't want to dig too deep into technical details. Curious readers can do their own research on such.
I want this article to be fairly abstract, but still precise and correct.
Sunday, 1 March 2026
'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 ].
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 ].
Subscribe to:
Posts (Atom)