Back to The tech awesomeness
Table of contents
Java chapters
//public class ExactStepCycle extends EndlessCycle {/*...*/}
//public class EndlessCycle extends PeriodicCycle {/*...*/}
//public class PeriodicCycle extends ExactStepCycle {/*...*/}
//public class Cycle extends Object {/*...*/}
//public class Object extends Object {/*...*/}
//public class Object {/*...*/}
//interface Trip extends Walk {/*...*/}
//interface Walk extends Trip {/*...*/}
//public class String extends Number {/*...*/}
//public class Number extends String {/*...*/}
//public class NumberStringStringNumber extends Object {/*...*/}
//public class StringNumberNumberString extends Object {/*...*/}
//public class PenPineAppleApplePinePen extends Object {/*...*/}
//public class Lamayamal extends Object {/*...*/}
//public class OOP extends Object {/*...*/}
//public class AOP extends Object {/*...*/}
//public class TOP extends Object {/*...*/}
//public class ProgrammingSubject extends Object {/*...*/}
//public class MachineLearningSubject extends Object {/*...*/}
These two are as of view point of single extensibility principle:
//public class Object extends Object {/*...*/}
//public class Object {/*...*/}
//public class String extends Number {/*...*/}
//public class Number extends String {/*...*/}
Unless there is a rule, which allows to create hierarchies, where at least one class in it has extension from Object class.
So this one is not ok, because neither from objects has visual or hidden extension from Object class:
//public class String extends Number {/*...*/}
//public class Number extends String {/*...*/}
And this one is just an exception or something like that.
//public class Object extends Object {/*...*/}
While if there is an exception, there is an antiexception, or not.
So for example such hierarchy:
//public class String extends Object {/*...*/}
//public class Object extends Number {/*...*/}
//public class Number extends String {/*...*/}
public class String2 extends Object {/*...*/}
public class Object extends Object2 {/*...*/}
public class Object2 extends Number {/*...*/}
public class Number extends String2 {/*...*/}
With these two hierarchies both rules are in satisfaction: single extensibility principle and cyclic inheritance and even no self object extension. The object package is different.
The Object is extensible, and not redefinable by other means other than overriddance of the publicly open method contents during inheritance.
The cornerstone of overcoming the cyclic inheritance rule is impossibility of redefinition of the Object class by other means other than overriddance of the publicly open method contents during inheritance.
To express it in other words: in scope of the single extensibility principle, the rule to override the Object class in each hierarchy blocks the creation of the cyclic hierarchies and the rule to deny the redefinition of the Object class blocks the creation of cyclic hierarchies together with the Object class itself.
So in the current configuration the hierarchies will be uncyclic, tree like ones with no cyclic subhierarhies because of single extensibility principle and with no cyclic hierarchies because of previous mention of combination of two rules.
Under this circumstances such hierarchies are not possible:
Object
/ \
extends extends
/ \
Number--extends---String
Object
|
Object2
/ \
extends extends
/ \
Number--extends---String
Object--extends---Object2
| |
extends extends
| |
Number--extends---String
That is not necessarily a case in multiple extensibility principle.
For example for interfaces.
//interface Number2 {/*...*/}
//interface Number3 {/*...*/}
//interface Number4 extends Number2, Number3 {/*...*/}
//interface Number5 extends Number2, Number3 {/*...*/}
//interface TwentyThree extends Number2, Number3 {/*...*/}
And with cyclic inheritance:
//interface Number extends String {/*...*/}
//interface String extends Number {/*...*/}
Because if two or more objects extend either data in class or methods in interface within cyclic inheritance it is probably a subject to combine the contents in those two or more objects in one object other than creating a hierarchy with cyclic inheritance within such configuration.
The update from 2020-06-25.
Such inheritance is immutable for unchangable base Object class, while in case of cyclic inheritance and changable base Object or other class the inheritance is mutable. Mutable and immutable inheritance class hierarchies.
//new Cycle().startFrom(1).plus(1).until(10).with(strings, String.class).do(new Contents()/*.setValue()*/).startCycle();
//new PeriodicCycle().until(conditionToSuffice).startCycle();
/*public class Cycle extends Object {
private int initial = 0;
private int end = 0;
private int plus = 0;
public Cycle startFrom(int initial) {
this.initial = initial;
return this;
}
public Cycle until(int end) {
this.end = end;
return this;
}
public Cycle plus(int plus) {
this.plus = plus;
return this;
}
public void startCycle() {
for (int index = this.initial; index < this.end; index = index + plus) {
//method contents; predicate.
}
}
}*/
The update from 2020-12-14.
class PartBitBitPart{/*Mobile*/}
class BitPartPartBit{/*Mobile*/}
The update from 2021-02-08.
An instance of postcrossplatformeity, but it seems that it out of SRE single responsibility principle, as well as out of single extensibility principle. Moreover it was already available in one of the triggeral systems приблизно 15 years ago. There was even a sub typing there.
The update from 2021-03-26.
The contrary situation for single responsibility pronciple (SRP) is nesting of the code or dispersion of the code. When the center for SRP has a conventional definion, as per classes or as per methods in class, per applications and so on.
The update from 2020-12-14.
Принцип одиничної розширюваності і циклова належність.
Оновлення від 2020-12-14.
клас ЧастинаБітБітЧастина{/*Мобільна*/}
клас БітЧастинаЧастинаБіт{/*Мобільний*/}
Оновлення від 2021-02-08.
///Зразок післякрізьплатформенності, але здається що воно є поза принципом одиничної відповідальності, також як і принцип одиничної розширюваності. Більше того він був доступний вже в одній з перемикачевих систем приблизно 15 років тому. Там навіть була його під типізація.
Оновлення від 2021-03-26.
Зворотньою ситуацією для принципу одиничної відповідальності (ПОВ) є накопичення коду чи розповсюдження коду, особливо коли центр для ПОВ має узгоджене визначення, для класів чи для методів у класі, для додатків і тому подібні.
Оновлення від 2021-05-15.
The update as of 2021-05-15.
Воно з'явилося 2021-04 десь майже 2 тижня потому протягом позамережевого доступу до цих сторінок в інтернет.
It appeared on 2021-04; 2 sem ago during internetless access to these web pages.
Оновлення від 2021-06-30.
The update as of 2021-06-30.
Some classes have data and methods.
Деякі класи мають дані і методи.
Some classes with Data Transfer Object design pattern have the data sometimes only of primitive types.
Деякі класи з Дата Передаючим Об'єктним патерном дизайну має дані іноді лише примітивних типів.
Так що будь-який клас можливо вмістити в наступну таблицю;табличку:
So that any class is placeable to the following table:
лише примітивні дані | лише об'єктні дані | суміш типів даних | має захищені методи | має приватні методи | ...
назва типу класа
....
only primitive data types | only object data types | mix of data types | has protected methods | has private methods | ...
the name of the class type
....
Знову ця пісня: Massive Attack - Splitting The Atom (Edouard Salier Version): this song again.
Оновлення від 2021-07-24.
The update as of 2021-07-24.
Зайняло в мене десь 5 діб, щоб осягнути, про те що існує, виявляється таке явище, разом з postcrossplatformeity як compatibility залежність або залежність від сумісності, як повідомили у сусідів в історії про сумісність.
It took me ~120 hours to grasp, that there is such a phenomenon, along with postcrossplatformeity as compatibility dependence, as neughbours have notified in the story about compatibility.
Зразок цього достатньо простий через таку відмінність: це оновлювати якесь ПЗ там де існують так звані ламаючі зміни і оновлювати якесь ПЗ там де їх нема.
An example of this one is pretty and simple via such difference: it is to update some software where there are so called breaking changes and to update some software where they are absent or in other words where they are not present.
Оновлення від 2021-08-21.
The update as of 2021-08-21.
ПЗ у хмарі чи ні, з ЗВ чи ні, з СОА чи ні, не вільно від циклових перепосилань. АЛЕ. Деякі фреймворкові програмні каркаси дозволяють вирішити подібні ситуації за допомогою можливості інтроспекції до деякого ступіню. Мені не відомо як це у СОА ПЗ.
Software in cloud or not, with DI or not, with SOA or not, is not free from cyclic rerferences. BUT. Some software frameworks allows to solve such cases with a help of introspection feature to an extent. I have not found how it is with SOA software.
Оновлення від 2022-12-18.
The update as of 2022-12-18.
Принцип одиничної розширюваності має один такий недолік. А саме як у ситуації з веб сервісами і веб послугами http://thetechawesomeness.ideasmatter.info/internet-and-exinternet-and-internetless.html;2022-10-27 ; http://thetechawesomeness.ideasmatter.info/issues.html;2022-09-01 при неможливості змін цей тягар переходить користувачам і користувачкам такого елемента. Це також помітно у функціях без можливості переїзда як то без @Override як у java та у користувацьких інтерфейсах без можливості зміни елемента з тієї чи іншої причини .
..
Щось віртуально наразі не можливо за 2 хвилини попри обіцянку але ймовірно далі буде. Переважно з за не відкладаємих процесів як то синхронізованих тобто звірених у часі а не асинхронних, блокуючих процесів тобто не таких як NIO та wait-interrupt режима. На відміну від веб клієнтів у електронно поштових клієнтах про це повідомляють доданням даних про статуси у відповідні електронні листи. Ймовірно це є і схожим рішенням для клієнтів повідомлювачів як то для messenger clients. Також подібні ситуації були достатньо присутні у ПЗ у VCh.
Принаймні для тієї ситуації для створення достатньо незмінного визначника серед велекої кількості таких визначників тобто серед великої кількості даних. При тому що дигітура на відміну від деяких інших просторів як то mediums відрізняється як раз такою властивістю як змінність щодо даних для такого.
Оновлення від 2023-06-17.
The update as of 2023-06-17.
Деяким визначенням у словнику притаманна циклова належність.
http://thetechawesomeness.ideasmatter.info/three-types-of-cycles.html.
Наприклад для прагнення.
З різними довжинами у таких ціпках.
Подібно також до node.js обробки та деякої агентної системи.
Одна з систем принаймні є обслуговувачем веб застосунків.
Адже обидва про цикли з запитами і відповідями, то ці очікуюючі запитів тобто не проактивні що відрізняє їх від систем або від частин систем з обидвома особливостями. Як то наприклад з вбудованим http клієнтом який запитує самостійно.
Тобто і від такого як yacy.
Оновлення від 2023-07-01 .
The update as of 2023-07-01 .
Для тієї людини комент якої я отримав сьогодні яка висловила про те щоб я перестав так робити, якщо я висловлю щось подібне взаємне то ми швидко досягнемо чогось накшталт public static void...
Після цього я розчарований у принаймні цій реалізації того що звуть free internet. Він є або його нема. Тобто з цього це те що і у старому й знайомому цензуруванні. Якщо він був а потім перейшов до часових проміжків з подібним то його не стало. Тобто у ній його нема. При тому якщо і був імплементаційно. Або у ньому виявили помилку. Що те саме що і його нема. Навіть якщо це частковий або одиничний випадок. Також попередньо проект зачиняли замість подібного.
У такому виконанні це нагадує якісь http://thetechawesomeness.ideasmatter.info/table-chapters.html;3 з зсувом від ПЗ до цієї пари.