2012-05-22T02:06:38Z

I was told by a colleague that in Java object creation is the most expensive operation you could perform. So I can only conclude to create as few objects as possible.

This seems somewhat to defeat the purpose of object oriented programming. If we aren't creating objects then we are just writing one long class C style, for optimization?

2023-04-20T16:51:13Z

I have a java class with an init method. It's different from the constructor. The constructor just initializes the variables/fields. The init method connects to a database and performs some verifications on the database + it kick starts a background thread which handles incoming requests.

If you wanna think of it in pseudo-code:

class SomeService:

    ...
    queue
    other fields
    ...

    public SomeService(Constructor input):
        initializes fields...

    public void init():
        connect to database and verify certain existence of a table
        start a thread
        initialized = true

    public String doSomething(Some Input):
        if !initialized: throw exception
        add job to queue to be picked up by the running thread

    public Integer doSomethingElse(Some Other Input):
        if !initialized: throw exception
        add job to queue to be picked up by the running thread

My question is, is it better to force the object user to call init before using the class methods? If you check the code above, any method will throw exception if it's called before init.

Benefits:

This provides separation of concerns -- a method is only responsible of doing its job.

Downside:

This, however, makes a bad class usability: what if init failed? the object user will always has to handle this. And might even try to call init before every other class method call.

The other option is call init at the beginning of every class method, internally.

Benefits:

The class user doesn't need to worry about anything but getting his services done by the object.

Downside:

Now a method isn't as good in terms of separation of concerns. It does its job after it tries to initialize the object.

Please note that the initialization procedure is a must before any other method does its job. Other methods won't be functional unless the object is initialized by calling init.

I believe it's obvious why I separated init from the constructor:

It's perfectly fine to have the object without it being initialized, and leave initialization for later.
A constructor shouldn't take long for initialization, which isn't the case. Connection to database, running multiple statements, and starting a thread. This isn't as snappy as just setting fields values.
If connection to database failed in a constructor, this will result in no object creation. This is bad behavior because the database can be available some other time after trial of object instantiation.

What I did is:

Called init at the beginning of every method. To get the benefit of that.
Availed init as public method to permit object caller for eager initialization.

So, what is it do you think is better? Call init at the beginning of every method? Leave it completely for the object user to handle it?

I tried to look it up but didn't find a fruitful answer.

I also tried to find in java 8 standard library if any class has init method, but couldn't find any. However, I found in java extension, Cipher class, which has init. and it works like approach#1 (leave it to the caller). That being said, this makes sense because its init takes user input, while mine doesn't.

I asked a chatgpt based bot and I got an answer that I should go with approach#2, calling init at the beginning of every method.

2015-04-09T18:02:40Z

I am currently working on a semi-large project that has several packages. There are 3 main packages, a "client" package, a "server" package and a "common" package. There are two jars, one for the client and one for the server each containing their own package and the common package. As is implied by the package names, there is a server and a client. The clients connect to the server and exchange messages. These messages take the form of a serilized subclass of Message. All subclasses of Message are in the common package. When a message is recieved, a method is called on the message class to handle the message. There is one subclass of Message that is responsible for sending the name of the clients to the servers. In the method that is called when the server recieves it, it then calls a setName() method on the object representing the connection between the server and client.

For obvious reasons, I don't want external programmers calling the setName() method however it has to be public because the message and the class to represent a connection are in different packages. I would like to know if it is good form to deprecate the method with a reason along the lines of "for internal use only", and if not, what is a better option?

2022-04-06T21:14:41Z

Background: I'm coding an app, the core idea is simple - I can choose a 'Task' (consists of name, code to perform aka Runnable, progress) through GUI, start it, stop it, start all 'Task's and stop all 'Task's. Each 'Task' has to be dispatched on different thread (long operations).

The problem: As mentioned, 'Task' class has ability to be started or stopped. Normally, I'd introduce a manager class like 'TaskManager' in order to literally manage tasks (let's say starting them on a different thread and keeping the handle in order to cancel it or keeping an eye on the threads amount - limited resources), but I've heard that Manager type of classes can be smelly and just poor practice.

Core question: Do I really need that kind of manager class?

2018-02-25T10:37:59Z

What should a constructor contain?

In both cases, all three arguments are needed for the class to work.

Which approach is better and why?

class Language {
  LanguageRepository languageRepository;

  Language(LanguageRepository languageRepository) {
    this.languageRepository = languageRepository;
  }

  public void doThat(String firstArg, String secondArg) {  
      languageRepository(firstArg, secondArg);
  }
}

class LanguageDoThat {
  Language(LanguageRepository languageRepository, String firstArg, String secondArg) {
    languageRepository(firstArg, secondArg)
  }
}

class Language {
  LanguageRepository languageRepository;
  String firstArg;
  String secondArg;

  Language(LanguageRepository languageRepository, String firstArg, String secondArg) {
    this.languageRepository = languageRepository;
    this.firstArg = firstArg;
    this.secondArg = secondArg;
  }

  public void doThat() {  
      languageRepository(firstArg, secondArg);
  }
}

or other?

There are only examples, but in these classes there will be no more methods.

2018-11-09T16:32:29Z

I'm doing code review on a change my co-worker made to our Java application, and I've found something I'm not very familiar with - a nested class.

From reviewing the code, it seems like the nested class is being used as if it were a normal class - and asking my co-worker about it, the reason for putting it in as a nested class is because of a source control issue preventing her from creating a new class on the day she coded it.

Now this is bothering me - because while there's no reason to introduce this element into our code (very few classes use nested classes in our application), there's also no drawbacks to it that I can think of either. The nested class is, in a very loose way, related to the class it came from, and re-writing the code so that the nested class is an independent one would take some time.

Is there any good reason to have my co-worker redo the code so that this nested class is independent? Or would I just be asking them to waste their time on something that does not matter?

Note that there does not appear to be any functional affect on implementing the class this way - so any argument would have to be from best practice or bad structure, rather than trying to prove that it doesn't work (because it does work - I'm just not sure it's appropriate).

2017-06-24T01:05:30Z

I am learning design patterns in Java and also working on a problem where I need to handle huge number of requests streaming into my program from a huge CSV file on the disk. Each CSV line is one request, and the first field in each line indicates the message type. There are 7 types of messages, each of which should be handled differently.

The code is something like the following:

class Handler {
    private CustomClass {….}
    Map<String, CustomClass> map = new HashMap<String, CustomClass>();
    Public void runFile() {
        // Read the huge CSV file with millions of records, line by line
        // for each line, get the string before the first comma (say X)
        switch (X) {
        case 1 : myMethod1(….); break;
        case 2 : myMethod2(….); break;
        case 3 : myMethod3(….); break;
        // ...
        default: // ...
        }
    }
    // Methods 1, 2, 3 declarations
}

Note 1: Some of the methods affect the map and others don't.
Note 2: Each request (method) uses different variables from the CSV line and executes a different logic.
Note 3: requests/methods are NOT connected; i.e. myMethod2() does not logically follow myMethod1().

Now my question – What is an appropriate design pattern for this problem? Is it fine if I keep the whole logic in one class (similar to the code above) without changing?

2017-04-10T07:57:09Z

This is sort of a follow up question on Multiple Same Object Instantiation. And I think, is not really language specific, so this is applicable to Java and C#?

Version A

public MyClass {
    public void methodX() {}

    public void methodY(int i, object o) {
        GeometrySplitter splitter = new GeomterySplitter(int i, object o);
        splitter.chop();
    }

    public void methodZ() {}
}

Version B

public MyClass {
    private GeometrySplitter splitter = new GeometrySplitter();

    public void methodX() {}

    public void methodY(int i, object o) {
        splitter.chop(int i, object o);
    }

    public void methodZ() {}
}

A colleague says that Version B is a better code practice, because the class is only instantiated once. My own reasoning is that the internal variable is only used in methodY(int i, object o) and thus it should be created within the method itself, as displayed in Version A.

My colleague then reasons that if that method is called 4000 times a second. For every method call an new instance of that class is created. And this is bad for performance and memory use.

Is this true? If so or not, can someone clarify this?

2012-08-14T05:35:54Z

What exactly happens in Java when you instantiate the same object multiple times?

For example:

Test test = new Test();

then later on I will call it again, Test test = new Test(); again or inside a loop. Will the previous instantiation be disposed?

2016-11-13T11:51:40Z

I'm new to object oriented programming and I don't understand what's the purpose of the main.

Yes, I read that it's the "entry point" of the program but what I don't understand is what should be in the main? And what are its responsibilities?

It may happen that something written in the main could be encapsulated in another object, but how much should you use this approach?

Here is my very first main I wrote in Java, it's very simple but it may make you understand my doubt better. I have an abstract class Animal which is extended by "Cat" and "Dog". I used the main to create some object and also as an "interface" with the user, indeed as you can see I used some conditional instruction to "ask the user" what he want to do.

My question arose from the fact that the interface could be encapsulated in another object and not giving that responsibility to the main.

    public static void main(String[] args) {
    Scanner input = new Scanner(System.in);

    System.out.println("What type of animal do you want to create? \n dog cat");
    String type = input.nextLine();
    if ( Objects.equals(type, "dog")){
        System.out.println("Enter the animal's age: ");
        int age = input.nextInt(); // Scans the next token of the input as an int.
        System.out.println("Enter the animal's name: ");
        String name = input.next();
        Dog first = new Dog(name, age);
    }
    else if ( Objects.equals(type, "cat")) {
        System.out.println("Enter the animal's age: ");
        int age = input.nextInt(); // Scans the next token of the input as an int.
        System.out.println("Enter the animal's name: ");
        String name = input.next();
        Cat first = new Cat(name, age);
    }

    else{
        System.out.println("Error: the specified type does not exist.");
    }
    System.out.println("The number of animals is:" + numberOfAnimals);
}

2016-05-04T07:14:00Z

My current understanding of Inheritance implementation is that one should only extend a class if an IS-A relation is present. If the parent class can further have more specific child types with different functionality but will share common elements abstracted in the parent.

I'm questioning that understanding because of what my Java professor is recommending us to do. He has recommended that for a JSwing application we are building in class

One should extend all JSwing classes (JFrame,JButton,JTextBox,etc) into separate custom classes and specify GUI related customisation in them (like the component size, component label, etc)

So far so good, but he further goes on to advise that every JButton should have its own custom extended class even though the only distinguishing factor is their label.

For e.g. If the GUI has two buttons Okay and Cancel. He recommends they should be extended as below:

class OkayButton extends JButton{
    MainUI mui;
    public OkayButton(MainUI mui) {
        setSize(80,60);
        setText("Okay");
        this.mui = mui;
        mui.add(this);        
    }
}

class CancelButton extends JButton{
    MainUI mui;
    public CancelButton(MainUI mui) {
        setSize(80,60);
        setText("Cancel");
        this.mui = mui;
        mui.add(this);        
    }
}

As you can see the only difference is in the setText function.

So is this standard practice?

Btw, the course where this was discussed is called Best Programming Practices in Java

[Reply from the Prof]

So I discussed the problem with the professor and raised all the points mentioned in the answers.

His justification is that subclassing provides reusable code while following GUI design standards. For instance if the developer has used custom Okay and Cancel buttons in one Window, it will be easier to place the same buttons in other Windows as well.

I get the reason I suppose, but still it's just exploiting inheritance and making code fragile.

Later on, any developer could accidently call the setText on an Okay button and change it. The subclass just becomes nuisance in that case.

2016-03-28T16:44:41Z

I am wondering about best practices here.

MVC (Model - View - Controller) patterns involve separating components of your program that model the data, manipulate those models, and display those results to the user (usually through the UI) in some way.

What about a function that takes the model data and inserts it into a database? For example I have an object called a GameBoard, and I also want the ability to insert the state of this board into the SQL database for storage / historical purposes. I have a class that holds all my query functions.

But where would I call these functions from? Would this sort of functionality make the most sense to make it as a method of GameBoard? Or should it be part of the controller classes?

For example, I've got a GameBoard class and an SQLDatasource/SQLHelper class (which I call the "models"). The SQL classes have methods that take care of the queries and such. In Android, there are also Activity classes where all the "events" take place (I call these the "controllers"). The "view" takes place via code that binds the Activity to some XML. That being said, I normally instantiate the GameBoards in the Activity classes, and right now I also call the query functions from these same classes that accept a GameBoard as an argument.

2013-01-04T20:20:03Z

Where I work I see lots of classes that do things like this:

public class ClassThatCallsItsOwnGettersAndSetters {

    private String field;

    public String getField() {
        return field;
    }

    public void setField(String field) {
        this.field = field;
    }

    public void methodWithLogic() {
        setField("value");
        //do stuff
        String localField = getField();
        //do stuff with "localField"
    }
}

If I wrote this from scratch, I would have written the methodWithLogic() like this instead:

public class ClassThatUsesItsOwnFields {

    private String field;

    public String getField() {
        return field;
    }

    public void setField(String field) {
        this.field = field;
    }

    public void methodWithLogic() {
        field = "value";
        //do stuff            
        //do stuff with "field"
    }
}

I feel that when the class calls its own getters and setters, it makes the code harder to read. To me it almost implies that complex logic is happening in that method call even though in our case it almost never is. When I'm debugging some unfamiliar code, who's to say that the bug isn't some side effect in that method? In other words, it makes me take lots of side trips on the journey of understanding the code.

Are there benefits to the first method? Is the first method actually better?

2011-10-02T13:40:32Z

This question is subjective but I was just curious how most programmers approach this. The sample below is in pseudo-C# but this should apply to Java, C++, and other OOP languages as well.

Anyway, when writing helper methods in my classes, I tend to declare them as static and just pass the fields if the helper method needs them. For example, given the code below, I prefer to use Method Call #2.

class Foo
{
  Bar _bar;

  public void DoSomethingWithBar()
  {
    // Method Call #1.
    DoSomethingWithBarImpl();

    // Method Call #2.
    DoSomethingWithBarImpl(_bar);
  }

  private void DoSomethingWithBarImpl()
  {
    _bar.DoSomething();
  }

  private static void DoSomethingWithBarImpl(Bar bar)
  {
    bar.DoSomething();
  }
}

My reason for doing this is that it makes it clear (to my eyes at least) that the helper method has a possible side-effect on other objects - even without reading its implementation. I find that I can quickly grok methods that use this practice and thus help me in debugging things.

Which do you prefer to do in your own code and what are your reasons for doing so?

2013-08-07T17:33:27Z

About a third of my code is wrapped inside a Facade class. Note that this isn't a "God" class, but actually represents a single thing (called a Line). Naturally, it delegates responsibilities to the subsystem behind it.

What ends up happening is that two of the subsystem classes (Output and Timeline) have all of their methods duplicated in the Line class, which effectively makes Line both an Output and a Timeline. It seems to make sense to make Output and Timeline interfaces, so that the Line class can implement them both. At the same time, I'm worried about creating parallel class and interface structures.

You see, there are different types of lines AudioLine, VideoLine, which all use the same type of Timeline, but different types of Output (AudioOutput and VideoOutput, respectively). So that would mean that I'd have to create an AudioOutputInterface and VideoOutputInterface as well. So not only would I have to have parallel class hierarchy, but there would be a parallel interface hierarchy as well.

Is there any solution to this design flaw?

Here's an image of the basic structure (minus the Timeline class, though know that each Line has-a Timeline):

NOTE: I just realized that the word 'line' in Timeline might make is sound like is does a similar function as the Line class. They don't, just to clarify.

2013-08-19T11:01:26Z

I've made a file browser in java that opens and read already been made excel files. (using Apache poi 3.9 library) program read those files perfectly but i want to update some of those files. how can i be able to update those files through my program. is there is any library or function/class that might be helpful, or also any other language that can support that feature (among c/c++, python)..???

2013-05-24T20:51:50Z

This might seem like an odd question, but I'm worried that I'm putting too many things as constants/finals at the top of my java class. I've started to put every value that is in my program into a constant (At least the ones that influence it's overall effect). The reason I'm doing it is because then it's easy to find the values and change them latter, even if they are only used once, it's easier to find them at the top. Is this a bad or good practice, I really have no idea.

Here's an example:

private static final Color COLOR_SELECTED = Color.BLUE;
private static final Color COLOR_ALTERNATE_ONE = Color.WHITE;
private static final Color COLOR_ALTERNATE_TWO = new Color(240, 240 , 240);
private static final Color TEXT_COLOR = Color.black;