Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm learning Java and the basics of OOP. Imagine I'm making a Person class. A person has of course a firstname and a lastname, that's why I declare two private variables in the Person class, being firstname and lastname. Both getting their initial value in the constructor. Now, how do you decide wether they both need a public getter and a setter, or only a getter and not a setter? Do you take this decission based on the kind of functionalities your application should have?
For example if you are building an application for the local sportsclub to keep track of their members (each member is a person object). Within the application there is a button to create a new member. if you push this button you have to fill in a firstname and a lastname and push the button 'create and add to club'. Behind the scenes there is a person object created. The application can show a list of all members and delete a member and thats all it can do.
Now there is no functionality like change firstname or lastname of a member. Could this be a reason why I should not have a setter for firstname and lastname? So if I created a member maked a typo in his firstname, I first have to delete him and then create him again without the typo. If the application had a button 'change name' I should need a setter or a method like changeName or something because I want to alter an already existing object.
Is this the correct mindset or has functionality nothing to do with encapsulation?
Ps. I know it's simple example but it's just to base my question on.
Thanks
You make that kind of decisions based on the character of attributes. Are they public (used by external to the object/class entities?). Are they private (for object/class internal use only?). Should they be read-only after construction? When they are read-only "to the public", you don't need a public setter. If internally you still want to change them, you probably can access them directly without going through a setter.
It also makes sense to be able to fix an erroneous attribute without having to destroy the object and recreate it.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am making a semester project for my University OOP course. I am making a Restaurant Management System as my project.
I have an Order class, Main class, and my constants stored in a class called GlobalConstants.
I read in a post on this site that said constants should be in related classes. In GlobalConstants I have a method running in a static block that reads order data (order no., time, items etc.) from a file and stores it in an ArrayList (static and final) which is accessed by multiple methods in the Main class.
So, can anyone suggest a better way to do this that follows OOP practices?
First, don't create any logic in a class, called GlobalConstants. This is the Separation of Concerns principle.
This made clear, you could:
First: create a util class e.g. FileUtil where you will move your static method. It wont store the result in a field, but will return the result instead (or alternatively take the list as an argument and populate it). Storing (if needed) or whatever other work with the result is needed is the job of the class that is calling the method, not of the util.
Second: I suppose that you have to store the content of your file in memory in order to do something with it for your order. You must decide what is the scope of this data.
If these are some global settings to your applicaton comming from this file - you could easily create a Settings class that will be Singleton (find info and read about Singleton - this will be a good start to get known with Design Patterns).
If it is some session data - maybe the order itself is coming from a file - then store this data in your Order class - this is its purpose after all.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm newbie programming in java.
I'm doing some forms and in one of them I put some fields, a button and a JTextArea. The idea is when I click in button makes a connection to external database and in JTextArea shows me the connection return (if is okay or if is failed and the error).
So I've created a class with the UI and a class(connection name) with the attributes database, port, username, password ... that make connection to external database.
I don't know if these organization mode is the best way to make it. I should include class connection in the same class of the UI,? How should I pass values of the form to the class connection, by a method?
Could you suggest me how to make it?
As lealceldeiro commented, this is opinion based, but there are some structures that it is good for these types of applications. What I've been taught and have been using is MVC(Model, View, Controller) structure.
The model is responsible for managing the data of the application. It receives user input from the controller.
The view means presentation of the model in a particular format.
The controller responds to the user input and performs interactions on the data model objects. The controller receives the input, optionally validates it and then passes the input to the model.
I usually make packages/modules called controllers, views and models. So I think you're on the right track here.
Let's say you have one class for your GUI, where the button onClickListener is. That would be your View.
Your models would be the class that you use to connect to the database, and maybe some classes/models in which you store the data from your database queries.
For you I would suggest to make another class that will be your controller. This class would contain your database object, and you can use this to make queries to the database and update your models. One of these could be connectToDatabase(), and you could call this method from your GUI when the button is clicked.
I hope I explained this well enough, and good luck!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Today I had an interview for test automation in one of the MNC.
They asked me "why do we need to create an object?"
I explained about OOPs concepts with example of individual bank account holders. But he is not convinced. He just need a definition.
What could be a suitable answer for that question?
You require an object to represent state.
At the most simple definition, a class defines behaviour and an instance of a class (an object) represents state.
Of course there are other things like static contexts which can also maintain state, which you can mention also, but above is the clearest answer which I believe they were looking for.
It also always helps to give an example. You could talk about, for example, an Employee class. You would need an object to represent John and another to represent Jane.
I think that this question is kind of generic and does not give much value to an interview. But some generic question should have a generic answer, and here is mine:
We need to create objects in java so we can get instances that have a state inside our application. This allows us to have persistent encapsulated elements that contain any required information, and methods that operate with it.
Just plain basic OOP theory.
There are many reasons why we create a object apart from basic oops
1) To bring up persistent state data to transactional state to perform action (curd and other) and persist back to data storage.(EJB, POJO,etc )
2) Creating handler to serve service and send fluid data across wire like web-service.
3)Stuctural behavior in action.for example you designed a class for a workflow and to make in action state we create a object and serve the behavior example validation , authorization , etc class
All in all to make design time architecture to response based live system
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a dilemma on how to implement this requierement:
Let's say I have the following Contact classes
Student,
Tutor,
AdminStaff.
I am not sure what is the best way to structure it in DataStore:
shall I have one Contact entity which will contain shared fields and also corresponding extra fields for given type
or shall I have three separate entities
first approach allows me to search through all my contacts, and the second is to avoid extra filtering when I just need contacts of certain kind.
However I have one more requirement which I am not sure how to accommodate with any of these approaches. What if I have contact with multiple personalities e.g. Tutor and AdminStaff. This suggests I have a separate Contact entity and link to its various personalities. So for the above example I would have data about that person kept in three entities Contact,Tutor,AdminStaff.
I would appreciate for any suggestions
Regarding your concern about searching over all your contacts - even if you have 3 different entity types, I think you could still create an index that would allow you to search over all contacts.
I don't know how many attributes there are that are unique to the different contact roles, but I'd be worried about creating a single mega-class/entity that encompassed them all - it could be a very big and messy class.
And, as you have indicated, your final requirement does make things more complicated. It suggests that perhaps you should have a single contact class/entity for all roles, and then create class(es) for the 3 roles that can be #embed'ed into to the contact entity.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have some trouble finding appropriate patterns for what I want to do.
I have a block game with two game modes. In one mode, any removed blocks are replaced by new blocks dropped from the top of the screen. In the other mode, removed blocks are replaced by a complete new row of blocks rising from the bottom and pushing the whole field up. So I thought it would be best to use the Strategy pattern to implement this.
Now the problem is, that this Strategy would need modifying access to all the positions of existing blocks in the playing field, but obviously that information lies within the Strategy's user class (the Game class) and I can't have circular dependencies.
I could pass the whole field as a reference, but I have the additional problem that all the Block generation code lies within the Game class (as it should in my opinion). So the only thing that comes to mind is pass all these methods as function references, but to me that seems like overkill.
So any way to resolve this? Maybe I'm on the wrong track by wanting to use the Strategy Pattern. Help is greatly appreciated.
Bonus points for any hints regarding the use of two Strategy Pattern objects in a class that need access to the same methods which depend on members in the user class.
I'm coding in Java if that is of help
I guess in the end it was kind of too complex to assume an out-of-the-box answer.
I kind of followed Traxdata's hint of decoupling more together with Mister Smith's suggestion to actually pass references to other objects.
My final solution consists of having a FieldManager, a Field and a Strategy class. The FieldManager contains a Field and Strategy instance. The Field class contains the block creation code.
So whenever blocks need to be created or removed, the appropriate function calls the corresponding Strategy's function and passes a reference to the field. So whenever a Strategy needs to create or remove something in the field it can do so via the field object.