Back to The tech awesomeness
Table of contents
Java chapters
Deepak Karanth wrote at https://dzone.com/articles/is-your-code-dry-or-wet:
Start quote: "Don’t Repeat Yourself (DRY) is a software development principle, the main aim of which is to reduce repetition of code. Write Everything Twice (WET) is a cheeky abbreviation to mean the opposite i.e. code that doesn’t adhere to DRY principle. It is quite obvious which one of the two should all developers be aiming for. But hey!, someone out there might be proving me wrong at this very moment." end quote.
And I noticed a lot of locations for:
Collection map = null;
//...
Object that = null;
//...
ConcreteSample typeInstance = null;
//...
So, the null assignment is a rather common repeatable allocation in codes.
public class ObjectV2 extends Object {/* wrapper, if not to reextend */
/* @EqualsAndHashCode */
/* static */
class ObjectV3 extends Object implements Null {
private Object object = null;
public Object objectify() {
System.out.println("calling objectify().");
/* nullify(object); */
this.nullify();
this.object = new Object();
return this.object;
}
/*
@Override
//...
@Override
//...
*/
@Override
public int hashCode() {
if (this.object == null) {
this.objectify();
}
System.out.println("No hashCode overriddance: "
+ object.hashCode());
return 0;
};
@Override
public boolean equals(Object obj) {
if (this == obj) {
return true;
}
if (obj == null) {
return false;
}
if (getClass() != obj.getClass()) {
return false;
}
final ObjectV3 other = (ObjectV3) obj;
if (!Objects.equals(this.object, other.object)) {
return false;
}
return true;
}
public int getObjectInWrapperHashCode() {
if (this.object == null) {
this.objectify();
}
System.out.println("getObjectInWrapperHashCode(): "
+ object.hashCode());
return object.hashCode();
}
public ObjectV3 ObjectV3() {
System.out.println("calling ObjectV3().");
objectify();
return this;
}
@Override
public void nullify(/* Object object */) {
System.out.println("calling nullify().");
/* object = null; */
this.object = null; /* aconst_null */
}
}
interface Null {
void nullify(/* Object object */);
}
public static void main(String[] args) {
ObjectV2 v2 = new ObjectV2();
ObjectV3 v3 = null;/* = null can be optional;
ObjectV3 v3; can be enough. */
v3 = v2.
new ObjectV3();
try {
if (v3 != null) {
v3.hashCode();
System.out.println("ObjectV3 "
+ "unoverriden by internal object hashCode: "
+ v3.hashCode());
System.out.println("ObjectV3 internal object hashCode: " +
v3.getObjectInWrapperHashCode());
} else {
System.out.println("no available ObjectV3.");
}
} catch (Exception e) {
System.out.println(e);
e.printStackTrace();
}
}
}
In turn that code outputs in my case:
calling objectify().
calling nullify().
No hashCode overriddance: 929338653
No hashCode overriddance: 929338653
ObjectV3 unoverriden by internal object hashCode: 0
getObjectInWrapperHashCode(): 929338653
ObjectV3 internal object hashCode: 929338653
The advantages at least are less null assignments, the disadvantages at least are more computations during each object constructor invocation and additional code class and its corresponding knowledge about its existance in case of not touching the java ecosystem et al.
The update as of 2021-07-16.
Оновлення від 2021-07-16.
Кожен визначник можливий до ґеш кодування, але кожен ґеш код можливий до визначення.
Each identifier is hashcodable, but each hashcode is identifiable.
The update as of 2021-10-11.
Оновлення від 2021-10-11.
If to extend this scope:
a quote "The idea is to avoid reusing a previously built image." from code to those images, which usually hold a version of a triggeral system and which is contrary to idea of image reuse, then they fit smoothly with DRY and WET.
Якщо розширити ці межі:
цитата "The idea is to avoid reusing a previously built image." що як перекладено ідея є уникнути перевикористання створеного зразка архівів файлів з кода до тих зразків архівів файлів, які зазвичай утримують якусь версію якоїсь перемикачевої системи і яка є зворотньою до ідеї перевикористання тих зразків, тоді вони є співставними з DRY та WET.
The update as of 2021-12-31.
Оновлення від 2021-12-31.
Якщо пригадати попередні версії деяких ПЗ, особливо відкрито кодових, особливо фреймворкових програмних каркасів то там був 1 файл як вихідний дістріб'ютіексчейнджі для доєднання до інших проектів. Тож потім деякі такі ПЗ, особливо фреймворкові програмні каркаси почали модуляризовувати тобто виділяти з них модулі і це полегшило не лише сам такий файл а і особливо для наступних створюваних проектів це додало і додали можливість обирати для складання такі додаткові модулі як у меню. Тобто ця особливість жорсткого зв'язування була не лише можливо зменшена протягом цього процеса а і перенесена до наступного рівня тобто до рівня модулів тобто до рівня відтепер декількох таких файлів. А значить щоби і слідкувати за цією особливістю жорсткого зв'язування потрібно було використання чи застосування більш складного ПЗ як варіант ніж попередньо. Або якась дія зі з'єднанням усіх такіх модулів тимчасово в один проект для попереднього ПЗ яке має особливість слідкування за такою особливістю жорсткого зв'язування. До речі цими веб сторінками іноді теж є меню але воно не обираєме хоча воно і не слідкує скільки і яких сторінок відкрито у табах чи у вікнах ППіНТВСуІ або у декількох таких програмах. Про що це я: а про те хоча після застосування такого методу і стало краще у тих ПЗ з тих які я використовув і хоча сама модулярізація продовжує займати час для всього циклу розробки, особливих змін для такого процесу відтоді не додалося, а саме рівнем розробки це контролюється а саме скільки і якого коду а тож скільки і яких особливостей буде у модулі. Тому про таку модулярізацію я би додав до цієї веб сторінки як підтипи для обох. Тобто DRY and WET й after modularization й before modularization. Чому я так. Тому що сам процес не змінився з тих що я помічав. Щоби якісно застосувати DRY, треба або багато знати, або багато назбирати десь якось про модулі і про немодулярізовані перед цим щоби потім запитати там чи вибрати з зібраних або мати якусь дуже якісну пошукову систему якій дозволено збирати про ці такі модулі і про немодулярізовані там і там і багато де. Тож якщо ці три щонайменш попередні можливі умови не виконані це призведе можливо до використання а можливо і не навмисно до WET, про що потім ймовірно скажуть це ж вже існує там чи там. Особливо у закрито кодових бо вони не надають доступа до тих таких пошукових систем теж. Навіть незважаючи чи присутні у них форки і копії їх чи інших. Тобто це теж частково схоже можливо з тим про атаку Сивілли від 2021-12-11 яка теж можливо зацікавлена у кращому їх пошуку. Тобто це схоже про пошуковий агрегатор по таких сховищах і репозиторіях. Але з ними так само як і попередньо вони не самостійно оновлюються і вони і такі сховища дуже різноманітні, що як альтернативно має як 1 велике сховище з багатьма проектами що при збої які вже неодноразово були призводить до зупинки або про видалення як в тому відомому випадку коли дуже якісна маленька за обсягом джаваскріпт дістріб'ютіексчейнджі після видалення з такого сховища не дозволила компіляційне складання багатьох інших проектів від нього залежних, якщо вони не використовували кеш або інщі подібні сховища і репозиторії.
The update as of 2022-03-24.
Оновлення від 2022-03-24.
Ці позначки щодо невіртуальних продуктів у бінарних межах як то віртуальні і невіртуальні продукти з позначками не мають посилань до якогось веб місця чи до веб сайта. Але вони пошукові тобто searchable. Але наприклад Apache maven dependency tree не має посилань у використанні за замовчуванням, хоча кожна з залежностей навіть у різних форматах була у якомусь віртуальному ресурсі навіть локальному тобто місцевому. Тобто тоді замість немає посилання зі шляхом. Навіть абсолютним чи відносним.
Але ті невіртуальні продукти у своїй кількості переважно не звучать. Тож як одна альтернатива це читати і промовляти текст у деякій перемикачевій системі. Тож як інша альтернатива це зразки на таких продуктах ШРкодів чи штрих кодів чи інших кодів з потрібним ПЗ та іншими посередницькими об'єктами який спрямовує до посилання яке спрямовує до навіть такого сайта як цей де таке промовляння є можливим. Щоби уминути має бути для ШРкодів чи штрих кодів чи інших як то must have. Обидва способи щоби додати доступності таким продуктами для тих хто не бачить.
Але у WYSIWYG у якій навіть опісля присутнє промовляння тексту для повідомлень навіть якщо мережею передається повідомлення повністю і одне до одного без втрат присутня наступна ситуація. Адже для обміну віртуальним повідомленням потрібно принаймні два повідомлювача. А значить у них 4 об'єкти. По 2 для додання повідомлення. І по 2 для отриманням повідомлень. Якщо використовуються ті символи які не є видимими наприклад для опису чогось в залежності від використовуємого повідомлювача можливі бути по різному показані у тих системах у яких можливо використання різних клієнтів для таких повідомлювачей. І промовлені чи ні потім. Тобто наприклвд при доданні показані, і опісля промовлені наприклад у деяких таких клієнтах повідомлювачів. А при отриманні ні. Тобто втрати можливі і тут. Ускладнює таку ситуацію невідомість щодо цього між користувачами і користувачками повідомлювачів можливо у деяких таких системах. Тобто у такій ситуації з принаймні 4 об'єктами і різними можливими клієнтами дані про WYSIWYG мають бути принаймні показані для її уникнення. Тобто WYSIWYG як властивість. WYSIWYG as a property.
[1]Lost in Translation Official Trailer #1 - Bill Murray Movie (2003) HDThe update as of 2022-05-11.
Оновлення від 2022-05-11.
Продовжуючи від 2022-03-24. Ці продукти цікаві. Помітно що деякими зазначають а деякими ні он такі ознаки як PP5. Сьогодні знайшов додатковий. ALU41. Ймовірно алюміній. https://en.wikipedia.org/wiki/Aluminium Але кумедно те що у самій публікацій дуже мало зустрічається 41. 13 частіше. Принаймні у дату і час пошука. Можливо це не про алюміній. Тоді наступна частина не має змісту. Але якщо про алюміній. То тоді існує принаймні 2 системи. Але перетворювача як то конвертера чи тобто конвертера я й досі за 20-30 рочків не знайшов що не виключає його існування. Й дійсно а навіщо він. Але ж ті дані продуктом показали тобто exposed. Тож гадаю що він можливо і з'явиться якщо його немає. Тому що якщо мені відомо де пошукати про алюміній але невідомо де пошукати про ALU 41 це не позначає що комусь невідомо навпаки. Тобто відомо де пошукати про ALU 41 але невідомо де про алюміній. Хоча це і не виключить ймовірну вирогідну появу третьої подібної системи чи краще. Якщо вона й досі десь не існує про яку мені не відомо.
Й якщо помічено там де сьогодні якесь триваюче завантаження даних це й є також зміною з WET до DRY щодо коду а також і частина http://thetechawesomeness.ideasmatter.info/eliminating-technical-debt.html. Специфічного синтакса який не має duck-typing альтернативи.
Приватний конвертер чи перетворювач такого можливо скільки завгодно краще за публічний або відкритий такий, але з ними проблема у тому що у тебе до нього немає доступу. А у тебе є. Це наприклад. Щотак можливо і з публічними або відкритими але шанси цього значно менше але поки й не знайшов чогось наприклад накшталт converter.wikipedia.org http://converters.wikipedia.org http://converter.wikimedia.org http://converters.wikimedia.org.
Наразі це трьохелементі пари. Якщо вони незмінні. Якщо ж змінні то тензор їх теж обробляє але має більше особливостей які застосовує такий додаток. У вікіпедії багато публікацій з переліками. Їх треба дуже обережно редагувати. https://en.wikipedia.org/wiki/List_of_rich_web_application_frameworks з посиланням до Learn to edit.
У одному з передавачів оновлень для веб сайтів і веб місць як цей, присутня особливість: "Автоматично видалити успішну передачу".
Адже деякі репозиторії тобто сховища залежностей також включають передавачі таких оновлень цей режим чи ця особливість застосовна і до них. У такому випадку за використання такого режима чи особливості залежності постійно завантажуються і не зберігаються. Така особливість додала б гнучкості деяким таким сховищам залежностей які мають постійно збільшуючиюся кількість тих залежностей хоча і натомість збільшеним навантаженням на передачу у мережі при невірному використанні або за постійної увімкненості за замовченням.