Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    goqp
    @goqp
    Awesome! Is it all clear then on how to compose the vertical decorators for the people list, and when to just use a person object rather than a list of people?
    Paulo
    @ptrecenti
    The problem i think is the of my objects
    Yes is pretty clear to me
    goqp
    @goqp
    Ok excellent.
    Paulo
    @ptrecenti
    You really help me
    goqp
    @goqp
    Try this rule of thumb: if the object looks "cute" and tiny, then it is okay. If it looks like a complex machine with lots of gears and parts, something is wrong. Refactor into smaller objects.
    Thanks, very glad I did !
    Each object should be a lightweight model that is mostly made of "air". The air is the (imagined) space in the text file that you literally write the code. Make sense? Here is a visual representation:
    { a,b } --- { a,b,c } ----- { a } ------ { a,b,c,d }
    Now here is what you dont want:
    { a,b,c,d,#e,%$#@,g,h,hi } --- { a,b,@%#^c,x^y,z } ----- { a@%,d,l,e,y,m,e^ } ------ { a,##%^^^b,c,d,d,v&#@@h }
    LOL! See...
    Paulo
    @ptrecenti
    LOL hahahaha
    good metaphor
    goqp
    @goqp
    :)
    Luca Guadagnini
    @tryIO

    @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:

    goqp
    @goqp

    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.

    goqp
    @goqp
    ....
    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.
    matrixbot
    @matrixbot
    RayoGundead can Observable be treated as container like HashMap?
    RayoGundead I don't know if it's even possible to make an immutable implementation of an observable
    Mihai A.
    @amihaiemil
    @goqp interesting aproach
    Yegor Bugayenko
    @yegor256
    I have a question, please help me understand. I believe that if there are no static variables in the software, memory leakage is not possible. Am I right?
    Mihai A.
    @amihaiemil
    Not an experd, but doesnt a unclosed InputStream count as a leak too? That doesnt have to be static
    Kirill
    @g4s8
    @amihaiemil I think it's rather resource leake, not a memory leak
    Kirill
    @g4s8
    What about memory leaks, static variables not the only cause of them. We can occupy memory with incorrect cache or pool usage e.g. if we keep references in cached item and of course JNI code and unsafe operations can cause memory leak
    Mathias STRASSER
    @roukmoute

    @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.

    Silas Reinagel
    @SilasReinagel
    @yegor256 Memory leaks are still possible without static. Just keep adding items to a collection instance that is retained for the lifetime of the app.
    Paulo
    @ptrecenti
    OnBoardingProcress could be a valid object to implement the user regiatration?
    Yegor Bugayenko
    @yegor256
    @SilasReinagel but in order to retain an instance for the lifetime, I need to make that instance static, right? Or the app that encapsulates it.
    @roukmoute yes, it’s still a very relevant article. I believe that a single return statement is a must.
    Silas Reinagel
    @SilasReinagel

    @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);
        }
    }
    Yegor Bugayenko
    @yegor256
    @SilasReinagel public static void run()
    see the word static?
    Silas Reinagel
    @SilasReinagel
    Sure. That comes from the language though
    Yegor Bugayenko
    @yegor256
    Exactly my point.
    Silas Reinagel
    @SilasReinagel
    No app exists without state
    That's fair
    Yegor Bugayenko
    @yegor256
    So, memory leakage may only happen in global (read “static”) objects, right?
    I’m talking about “leakage”, not overflow
    The example you gave is not leakage
    It’s just overflow
    Leakage means we don’t know where the memory is. It’s occupied by some objects that we are not using any more. Right?
    Kirill
    @g4s8
    @yegor256 right. See this sample without 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");
            }
        }
    }
    here leakedObject leaked because class run is not static and this object can be accessed through App.this.leakedObject from Run instance
    Yegor Bugayenko
    @yegor256
    @g4s8 got it, you seem to be right
    every new thread is a new global space
    Stian Soiland-Reyes
    @stain
    yes, thread leakage is common in Java
    typically by doing like above, that you accidentally made a nested class that should have been static, final or separate