cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rafaelweingartner <...@git.apache.org>
Subject [GitHub] cloudstack pull request: Fix Sync of template.properties in Swift
Date Mon, 25 Apr 2016 21:30:58 GMT
Github user rafaelweingartner commented on the pull request:

    https://github.com/apache/cloudstack/pull/1331#issuecomment-214529726
  
    I do not find them (final static) purely cosmetics (we are using too much this expression
lately).  I understand its use, as I presented the references about the GC and static variables.
Maybe we could use only the static keyword? That is what I am saying. The final keyword would
work more like an assurance, so no one can change that reference during runtime. But, I believe
we do not need such guarantees, right?
    
    I could not find anything (specs or guides from Oracle or OpenJDK) saying that the "final"
keyword would provide such improvements. Maybe you could help me find something to clarify
my doubts?
    
    About logging from static methods, I do not find that argument appealing. Even though
static methods may be appealing, they are easier to use and code, not needing to integrate
into a framework life cycle to wire all of the dependencies. I believe that if we have an
“util” class with static methods, then it (the util class) will have a static variable
“Logger”; now, mixing static methods into a singleton;  I see that as an anti-pattern.
This is very personal, I like to delegate very specific tasks to each class. I believe that
facilitates the design of the software and the writing of test cases (both unit and integration
one)
    
    I understand your feelings about Mockc. I had the same some time ago when I started working
with TDD. At that time I used Easymock. But still, the point is that, once we start writing
test cases (the unit ones), we get into a moment in which we have to write integration tests.
That means a method that uses few methods that are self-contained and unit tested. Therefore,
we do not need to test the whole method (we already assured that the units are working), but
only check if the method is calling the methods (units) it should (checking the order), with
the parameters that are expected and at the end returning what we expect it to return. To
facilitate that job we would need to use Mocks, then we would not have to prepare complicated
set ups to write our tests.
    
    About the overhead problems to the GC, as I said, I am talking about singletons, they
are created only once in the whole application life cycle. Therefore, they would not cause
overhead problems with the GC.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message