@try io > and pay attention about prototyping, it's not easy to extend an object, unfortunatly it's much worst than you think:
oh I agree remember? I said its complicated and confusing. But the nut cases that developed prototyping for SELF thought that it would be an easier alternative to classes, they said so.
of course, I just wanted to show better the hell behind, extending a prototype object to anyone :smile:
Object thinking for BUSINESS:
So as you may know I work in business not software development. Recently I have been applying object thinking to help me organize and direct my operations. This is especially important because I have memory problems and cant remember a lot of small details accurately or for very long. One strategy I am using, is to encapsulate actions with a short time-frame within the action item. So, for example, when I get one or several short-time-frame actions (like emailing a document to a client, preparing an invoice, etc.), I grab the relevant file (or make it) and write down a memo listing the actions. Then I put it in the inbox and FORGET ABOUT IT.
....
Now the entire set of actions (i.e., the behaviors) that need to take place are encapsulated inside of the folder (i.e, the object), and are not visible to the outside (i.e., I forgot what to do). I dont need to remember what actions to take or use a master control list to track the actions. The short time frame means that they wont be relevant for very long, usually not longer than a few hours. They also change quickly. When that happens, I grab the folder, make an edit, and then re-file it in the inbox. While this method is more laborious then one would desire, it is cognitively much less demanding and makes it possible to manage large amounts of important information without burning out.
I want to point out that this is not the same method as writing down "what to do" on sticky notes that go on the thing. Because, in that case you are still relying on memory to recall the actions. The sticky note serves as a reminder and you remember the details. My technique means loading your entire working memory onto the memo. Usually this means more info than can comfortably fit onto a sticky note. The inspiration for this technique was Yegor's article (or maybe from EO v. 2) that describes how variable names only become long if your scope is too large. Just like you dont need to use complex names when the scope is small, you dont need to centralize task information when the time frame (scope) is small.
RayoGundead I don't know if it's even possible to make an immutable implementation of an observable
@yegor256
I've just seen this article: www.yegor256.com/2015/08/18/multiple-return-statements-in-oop.html
Is it still relevant?
You show an example in comments:
class If implements Number {
private final boolean condition;
private final int left;
private final int right;
If(boolean cnd, int lft, int rgt) {
this.condition = cnd;
this.left = lft;
this.right = rgt;
}
@Override
int intValue() {
if (condition) {
return this.left;
} else {
return this.right;
}
}
}I've got two questions bout that.
Finally you have just "move" condition in object, so what is the real benefit?
It is only because Object has a state?
And second, you have not respect your own article.
Why do you not do:
if (condition) {
return this.left;
}
return this.right;And more you respect Object Calisthenics.
@yegor256 You don't have to have anything explicitly static (except for an app entry point) to have a memory leak.
This is a simple memory leak:
public void run() {
var myCustomers = new ArrayList<Customer>();
while (true) {
myCustomers.add(new Customer("John", "Doe));
Thread.sleep(1000);
}
}static?
public class App {
Object leakedObject = new Object();
public void start() {
new Thread(new Run()).start();
}
class Run implements Runnable {
@Override
public void run() {
System.out.printf("run");
}
}
}leakedObject leaked because class run is not static and this object can be accessed through App.this.leakedObject from Run instance
