salazar's Profile User Rating: -----

Reputation: 104 Stalwart
Active Members
Active Posts:
613 (0.64 per day)
26-June 13
Profile Views:
Last Active:
User is offline Feb 03 2016 03:08 PM

Previous Fields

OS Preference:
Favorite Browser:
Favorite Processor:
Favorite Gaming Platform:
Who Cares
Your Car:
Who Cares
Dream Kudos:

Latest Visitors

Icon   salazar has not set their status

Posts I've Made

  1. In Topic: Why does php parse first?

    Posted 3 Feb 2016

    Well that's not always true, if I believe. Yeah, parse should always be done first, obviously. But parsing can be done either separately from interpretation or at the same time. Early TCL, I believe, was written like this, but eventually was written to separate them. When compiling a peiece of php code, I noticed that it checks for syntax errors, so it must be done separately.
  2. In Topic: Is it bad design to have dependencies between two class hierarchies

    Posted 28 Jan 2016

    Yeah, that's the same problem I see as well. You could inadvertently violate the Liskov. I think a good soultion is to encapsulate one of the classe in the other
    class A {
    B b;
    setB (B );
    // Do stuff with b
    That way, there would be no way to violate the Liskov as any class that is of type A will always have the correct type, assuming that it is set correctly. That would avoid the need to resort to using type checking code, a nasty sin, such as [b]instanceof[\b].
  3. In Topic: Is it better to reuse commonly used objects as mutable member classes

    Posted 22 Jan 2016

    View Postcfoley, on 19 January 2016 - 03:47 AM, said:

    You should declare your variable in the smallest scope possible. I think ndc85430 is saying that this would be a better option:

    Class x {
       void bar (Foo a) {
          // Do stuff with a

    I would either go with this or your second option. Your first option should only be used if you need to keep the value as an instance variable for another reason. Maybe you need to preserve it between method calls or something.

    In general when you are choosing between two options, when one is better style and the other is possibly faster go with the better style. If you do this then your code will be easier to read and maintain. If you find real performance problems then it will be easy to switch to the optimised version. However, what you will probably find is that well-factored code opens itself up to performance enhancements on a larger scale. For example, instead of minutiae like widening the scope of a variable, you might insert a caching layer. The latter might only be possible because of the modularity of the design.

    I agree with setting variables to minimalist scope. But does that apply to large classes that might have performance overhead. Is there a readability difference between global variables and local variables? By your logic, I should prefer local variables because it is more readable?

    View Postcfoley, on 22 January 2016 - 06:55 PM, said:

    For a large object, what's worse: the time to build it repeatedly or the memory involved in keeping it indefinitely? You probably won't know for sure until something gives. Go with the most maintainable design until you hit a snag. Then your maintainable design will come into its own...

    Well, memory is cheaper than processing time. But I get what your saying. They both have downfalls, just whater is more applicable to your needs.
  4. In Topic: Is it better to reuse commonly used objects as mutable member classes

    Posted 22 Jan 2016

    View PostCasiOo, on 19 January 2016 - 05:46 AM, said:

    So the real answer is: That depends.

    Can you give us an actual example?
    What is Foo, and what is it used for? Does it have to be thread safe? Is Foo communicating with other parts of the application?

    It's just a simple sublcass of JFrame. For my initial purpose, it didn't have any defined communication with other parts. It was mainly used to create an instance.
  5. In Topic: Is it better to reuse commonly used objects as mutable member classes

    Posted 22 Jan 2016

    Thanks to everyone that replied. Even thought my example code was not intended to reflect what I would normally do and hence may have bad smells, these are all really good points that were brought up. What if the class in question happens to be a large object such as JFrame. Then I guess a better question would be, "Should I create the JFrame have it available throughout the entire lifetime of the program, or would it not make a significant different if I just created a new instance of the frame everytime. I know this seems trivial, but just wanted your guys thought on it.

    void showWindow () {
        MyWindow = new MyWindow ()

    Given the above code, would there be a significant perfance overhead from create the new window everytime rather than just having it has a member.

    But since it was brought up, I do get what you mean by that, I think. You're saying that because of
    creating an instance, that is only and nothing but an instance of Foo, that it forbids and extensibility or modification that could otherwise be done. However, by using constructor method, subclasses or class with a certain interface of Foo can also be used in accordance with the Liscov substitution principle.

    Even thought the line
    "Foo a = new Foo ()a" is subtle it complete alters that semantics of the code. I hope my interpretation is correct. If not, please feel free to correct me.

My Information

Member Title:
D.I.C Addict
24 years old
November 12, 1991
Software Development
Years Programming:
Programming Languages:
Specialty: C/C++, Java
Others: Php, Bash, Perl, Prolog, Sql, UML, Javascipt, Html/CSS

Contact Information

Click here to e-mail me


salazar hasn't added any friends yet.


Page 1 of 1
  1. Photo

    JA94 Icon

    04 Nov 2013 - 11:36
    how do you pm someone on this site?
  2. Photo

    salazar Icon

    03 Sep 2013 - 18:27
    Hello me.
Page 1 of 1