Related
I was reading this article on why getter and setters are evil. The article doesn't say not to use them ever, but, it's telling you to think in a way that limits the use of those methods, or to quote the article:
Don't ask for the information you need to do the work; ask the object
that has the information to do the work for you.
what happens when you need to display data in a GUI, but don't have getter methods? The article covers this briefly, but not fully. It mentions passing a JComponent to the class, but if you're GUI changes, it could lead to a lot of work to fix.
Take for example, you have a Book class (making this example limited to keep it readable).
public final class Book {
private String title;
//Authors is class with the attributes authorFirstname, authorLastname
private List<Author> listofAuthors;
public Book(String title, List<Author> listofAuthors)
{
//initialization
}
//other methods that do work
}
If I have a GUI that has a JTextField to display the book title and a JTable to display the list of authors, how would I write my method to "do the work" for me and display the result? Is this one of those times where a getter is necessary?
Allen Holub's article (the one you mentioned) is completely right, you shouldn't ask for data, at least when you're doing Object-Orientation. And no, displaying things is not a valid excuse to open up an object.
If you have a Book, just ask for the Book to display itself! It shouldn't matter whether that uses a JTextField or JTable or whatever. Depending on your requirements of course, you could do:
public final class Book {
...
JComponent display() {
...
}
}
The point of Object-Orientation is of course, that you are trying to localize changes (restrict to one class as much as possible). The only way to do that is to localize the functionality that depends on the same things into (preferably) the same class. Also called increasing "cohesion".
So now, if the Book internals change, all of the things, including how the Book is displayed is in the Book itself, so there is no need to "hunt" for code that uses the Book.
Now, for the answer that this is not "clean", because you are mixing presentation code with "business logic". It may be interesting to note, that the whole idea of not mixing presentation with "business logic" comes from earlier times, when we still thought that presentation might be "remote" to the "business objects", where "business objects" might be used by multiple applications for different things. Ie. multi-tier designs. YAGNI. Most of the time there is no real reason to have artificial technical boundaries inside a single application. There is no harm done if the Book knows it's part of a GUI application, and there are real benefits (maintainability) to have.
Edit: this is how the `display() method could look like in detail, with displaying the title and authors (pseudocode for Swing):
public final class Book {
private final String title;
private final List<Author> authors;
...
public JComponent display() {
JPanel bookPanel = new JPanel();
bookPanel.add(new JLabel(title));
JList authorsList = new JList(); // Or similar
for (Author author: authors) {
authorsList.add(author.display());
}
bookPanel.add(authorsList);
return bookPanel;
}
}
And then you can simply add() that component to whatever swing container you want to display the book in.
Think of it this way: Getters (public functions) are a bridge for private attributes.
I'll write you a simple example to modify your TextField using OOP.
Book class:
public final class Book {
private String title;
//Authors is class with the attributes authorFirstname, authorLastname
private List<Author> listofAuthors;
public Book(String title, List<Author> listofAuthors)
{
//initialization
}
public String getTitle() {
return this.title; }
}
GUI:
author1 = new Author("jhon");
author 2 = new Author("alsojhon");
list = new ArrayList();
list.add(author1);
list.add(author2)
b = new Book("stack",list);
JTextField field;
field.setText(b.getTitle());
You can create three kind of classes:
Entity, classes that represents a business concept and have only one unique id, like Client class with Id the username. It is usually a mutable class. You should have all the business logic here. You should not open his data with getters and setters.
Value object, classes that represents a business concept but not have an unique id, like Email class. It is usually an imm.utable class. You should have all the business logic here.
Data structure (kind of DTO), classes to save data only, without behavior, maybe you have setters and getters to access those datas.
What can I do if I need to access all Client data if I do not have accesors? Well, you should transform Client to a DTO. You can use a framework like Orika. Or you can create a method into Client class to ask for information (mediator pattern).
I like second option but it implies more work:
class Client{
private String name;
...
public void publishInfo(ClientInfo c){
c.setName(name);
...
}
}
class ClientInfo{
private String name;
//GETTERS
//SETTERS
}
Are you asking about a method to display all the information for you? I'm not following.
If that is what you're asking, here's my recommendation: Don't write it in the class with the window code in it. It won't be very clean. Make a new class with that method in it (Yes, getters are necessary, they make OOP easier, but that's biased).
What I do if I want to iterate through a list is make a StringBuilder, along with a for loop, that adds the name of the author. Then, have the method return the list of authors.
List<Authors> a;
StringBuilder d = new StringBuilder();
for (int i = 0; i < a.size(); i++) {
d.append(a.get(i).getName() + ", ");
}
return d.toString();
//It's just sudo code, but still.
Assuming I have the following DB model:
Car(
id INT
plaque_id INT
)
Plaque(
id INT
identification TEXT
)
So in ActiveJDBC, my models are:
public class Car extends Model {
static{
validatePresenceOf("plaque_id");
}
public Car () {}
}
..
public class Plaque extends Model {
static{
validatePresenceOf("identification");
}
public Car () {}
}
Assuming my specification says: a car must have a plaque.
As you can see, I am enforcing the presence of plaque_id to the Car model.
Now. When I try this:
Car model_s = new Car();
Plaque plaque_a = new Plaque();
plaque_a.set("identification","A-8000");
plaque_a.saveIt();
car.add(plaque_a);
car.saveIt();
I got the following exception thrown:
java.lang.IllegalArgumentException: You can only add associated model
to an instance that exists in DB. Save this instance first, then you
will be able to add dependencies to it.
If I understand correctly, my car model_s must be saved first before being able to link plaque plaque_a. But I cannot save model_s without a plaque due to my validation rule. It's a catch-22.
Note: I am new to activeJDBC.
I think you got it backwards. Since your table Car has a column plaque_id, it means that a Plaque has many Car(s), which is a One-to-Many association: http://javalite.io/one_to_many_associations.
Therefore, you need to add Car to Plaque, and not the other way around:
Car model_s = new Car(); // set parameters on the car
plaque_a.set("identification","A-8000");
plaque_a.saveIt();
plaque_a.add(model_s);
Other recommendations:
1) In Java, use CamelCase: modelS, not model_s
2) Add constructor to Plaque:
public class Plaque{
public Plaque(String identification){
set("identification", identification);
}
public Plaque(){} // must have default constructor
}
then your code will look cleaner:
Car model_s = new Car(); // set parameters on the car
Plaque plaque = new Plaque("A-8000");
plaque_a.saveIt();
plaque_a.add(modelS);
Generally, try to avoid dynamic setters and getters, they are OK for a small project, but writing permanent setters and getters will get you an amazing power of Java refactoring, something you do not have in Ruby.
I dont know how to really ask this.
But like...
Student stud1 = new Student("Shady");
Student stud2 = new Student("Nick");
Student stud3 = new Student("Name");
stud2.addBook(new Book(Book.BOOK_MISERABLES, 3););
Now if we assume we have the following variable in the Book class:
private Student owner;
And now the question, inside the constructor of "Book" -> Is it possible to get the "stud2" object it's being called to? Without adding an additional parameter to the constructor? If so, how? I think it's possible... So it will be something like this:
private Student owner;
public Book(int bookNum, int weeks){
this.owner = this.GET_THE_TARGET_THIS_IS_CALLED_ON;
this.bookNumber = bookNum;
this.time = weeks;
}
What you're asking is not directly possible. You will need to either
Pass a reference to the Student instance to your Book constructor
or
Use a setter inside the Book class to set the value of the owner field to your Student instance.
The latter would be a method that looks like this:
public void setOwner(Student owner) {
this.owner = owner;
}
Additionally, you may want to modify your Student.addBook method to call this setter, like this:
book.setOwner(this);
As you mentioned in your comment, you can traverse the stack using Thread.currentThread().getStackTrace() However, you'll be unable to obtain an object reference using that technique. You can obtain the class or method name but the uses for that are limited unless you intend to construct a new instance. That's all highly unorthodox and not at all appropriate for this situation.
I'm looking for some object oriented design help basically.
At the start of my program I need to load a whole bunch of data into the program(not from a database or anywhere; in this case I'm just loading it into the program) by building objects and assigning variables. However this takes up a lot of room and I feel like I'm just clogging up the main method and making it unreadable.
I'm wondering what's the right way to approach this is, as far as OOP goes.
I tried to make a class SubjectBuilder, and create everything in the constructor or variable space, and then create a new object in the main method. But it seems that alldata is out of the scope of the main method so when I need to manipulate it later I can't.
Student jack = new Student("Jack Smith"); // Creating all the Student objects
Student jim = new Student("Jim Lucas");
Student beck = new Student("Beck Barber");
Student ann = new Student("Ann Walker");
Student lucy = new Student("Lucy Boxer");
Subject maths = new Subject("Maths"); // Creating all the Subject objects
Subject business = new Subject("Business");
Subject java = new Subject("Java");
Subject design = new Subject("Design");
Subject project = new Subject("Project");
business.addStudent(jack, 70);
business.addStudent(jim, 65);
business.addStudent(beck, 70);
business.addStudent(ann, 83);
business.addStudent(lucy, 78);
^^ That's a snippet data I need to load. I have a bunch of marks for each subject.
At this stage I only have the Application class, Subject class (HashMap of student and Integer mark), and Student.
All I need to do is create this program that displays individual data for students or subjects and allows changes to particular marks etc. I'm confident I could complete the whole project in the main method but I feel like that's not very object oriented. I just don't know how to do it otherwise.
Firstly, how about creating a method to do this so it is not in your main
e.g.
Class MyClass {
public void main (String args[]) {
myClass mc = new MyClass();
mc.loaddata ();
}
private void loadData () {
}
Now in your loadData method you could load this data from a CSV file maybe? See http://opencsv.sourceforge.net/
A simple suggestion for: create a StudentFactory to encapsulate students instantiation, the facory method might looks like: public List createAllStudents();
And the same to Subject class.
If you are only going to access the students from the business class you could do the following
business.addStudent(new Student("Jack Smith"), 70);
business.addStudent(new Student("Jim Lucas"), 65);
business.addStudent(new Student("Beck Barber"), 70);
business.addStudent(new Student("Ann Walker"), 83);
business.addStudent(new Student("Lucy Boxer"), 78);
Keep your data in arrays or some other data structure like
String names = {"Jack Smith","John","Asley"};
int grades = {70,65,85}; //you can generate local or global array , its up to you
int main()
{
for(int i=0;i<names.length;i++)
business.load(names[i],grades[i]);
}
//Do your work in load method
You should use a map to hold your students, and use Long or String or any other immutable class as your key. I recommend using a Map because it's O(1) to access data from this kind of collection, against O(n) if you use, for instance, an ArrayList<Students>.
private Map<Long, Student> students = new HashMap<>();
Then you should move your loading data to a method such as:
private void loadStudents(){
student.put(1L , new Student("Jack Smith"));
student.put(2L , new Student("Joe Doe"));
student.put(3L , new Student("Jane Doe"));
}
For your Subject you could use again some map:
private void loadSubjects(){
subjects.put("MATH" , new Subject("Mathematics"));
subjects.put("JAVA" , new Subject("Java"));
subjects.put("DESING_PATTERNS" , new Subject("DesingPatterns"));
//for instance you could have more advanced subjects such as:
subjects.put("C++" , new Subject("C++" , "lecture" , "class 101" , "prof. T. Richards"));
}
Since by calling an object's constructor means that that object is ready for use, you should call your loadStudent() (and possibly loadSubjects() method, or any methods you use to load your data into the application) into this constructor.
public BusinessLogic(){
loadStudents();
loadSubjects();
//and so on
}
This is the prefered way against having to call load data methods on your newly created object, and always remembering you have to call these methods before using your object:
BusinessLogic business = new BusinessLogic();
business.calculateFinalGrades(); // NOT GOOD BECAUSE YOU HAVE FORGOTTEN TO CALL loadStudents();
So, you'll end up having something like:
public static void main(String[] args){
buildUI();//build your command line interface / graphical user interface
BusinessLogic businessLogic = new BusinessLogic();//you can probably now make this object a Singleton in order to prevent having multiple instances
...
}
You are right, building the whole application in the main is not the way to do it. In my opinion you should build a class that provides data let's say DataProvider that has methods for providing given data. As there are multiple ways of storing data, you can make this an interface/ abstract class depending on the common code. As your project can evolve and later maybe you want to extract data from DB or XML or something else. Like this it will be loose coupled and easy to replace. It might look like this:
interface DataProvider<T> {
Collection<T> loadData();
//...other useful methods
}
class DummyStudentDataProvider implements DataProvide<Student> {
Collection<Student> loadData() {
///...your logic
}
}
I used generics as the same logic could be used for different classes that you might need. Hope this helps you.
I'm struggling to come up with a good way of adding a bidirectional relation in OO model. Let's say there is a Customer who can place many Orders, that is to say there is a one-to-many association between Customer and Order classes that need to be traversable in both directions: for a particular customer it should be possible to tell all orders they have placed, for an order it should be possible to tell the customer.
Here is a snippet of Java code, although the question is largely language-agnostic:
class Customer {
private Set orders = new HashSet<Order> ();
public void placeOrder (Order o) {
orders.add(o);
o.setCustomer(this);
}
}
class Order {
private Customer customer;
public void setCustomer (Customer c) {
customer = c;
}
}
What buggers me is that given the model someone could easily call:
o.setCustomer(c);
instead of correct
c.placeOrder(o);
forming unidirectional link instead of bidirectional one.
Still learning OOP, could anyone please help with what would be an idiomatic and practical way of solving this problem without resorting to "reflection" or fancy frameworks (that would anyway rely on reflection).
P.S. There is a similar question: Managing bidirectional associations in my java model, however I don't feel it answers my plea.
P.S.S. Any links to source code of real-life projects implementing business model on top of db4o are greatly appreciated!
This is a very interesting question, which has profound implications on the theory and practice of OOP. First I will tell you the quick and dirty way to (almost) accomplish what you requested. In general I don't recommend this solution, but since nobody mentioned it and (if memory doesn't fail me) it is mentioned in a book from Martin Fowler (UML Distilled), it is probably worth talking about; you can change the definition of the setCustomer method from:
public void setCustomer (Customer c) {
customer = c;
}
to:
void setCustomer (Customer c) {
customer = c;
}
and make sure Customer and Order are in the same package. If you don't specify an access modifier, setCustomer defaults to package visibility, which means it will be only accessible from classes within the same package. Obviously this does not protect you from illegitimate access from classes other than Customer within the same package. Also, your code will break if you decide to move Customer and Order in two different packages.
Package visibility is largely tolerated in common programming practice in Java; I feel like within the C++ community the friend modifier is not as tolerated as package visibility in Java, despite the fact that it serves a similar purpose. I can't really understand why, because friend is much more selective: basically for each class you can specify other friend classes and functions which will be able to access the private members of the first class.
However, there are no doubts that neither Java's package visibility nor C++'s friend are good representatives of what OOP means, and not even of what Object-Based Programming means (OOP is basically OBP plus inheritance and polymorphism; I'll use the term OOP from now on). The core aspect of OOP is that there are entities called objects, and they communicate by sending messages to each other. Objects have an internal state, but this state can only be altered by the object itself. State is typically structured i.e. it is basically a collection of fields such as name, age and orders. In most languages messages are synchronous and they can't be dropped by mistake, like a mail or a UDP packet. When you write c.placeOrder(o) it means that sender, which is this, is sending a message to c. The contents of this message are placeOrder and o.
When an object receives a message it must handle it. Java, C++, C# and a lot of other languages assume that an object can handle a message only if its class defines a method with an appropriate name and list of formal parameters. The set of the methods of a class is called its interface, and languages such as Java and C# also have an appropriate construct, namely interface to model the concept of a set of methods. The handler for the message c.placeOrder(o) is the method:
public void placeOrder(Order o) {
orders.add(o);
o.setCustomer(this);
}
The body of the method is where you write the instructions that will alter the state of object c, if necessary. In this example the orders field is modified.
This is, in essence, what OOP means. OOP was developed in the context of simulations, in which you basically have a lot of black boxes that communicate with each other, and each box is responsible for its own internal state.
Most modern languages adhere perfectly to this scheme, but only if you restrict yourself to private fields and public/protected methods. There are a few gotchas, though. For instance, within a method of class Customer you could access the private fields, such as orders, of another Customer object.
The two answers on the page you linked are actually very good, and I upvoted both. However, I think, it is completely reasonable with respect to OOP, to have a real bidirectional association, as you described. The reason is that to send a message to someone, you must have a reference to him. That is why I'll try to outline what the problem is, and why we OOP programmers sometimes struggle with this. Long story short, real OOP is sometimes tedious, and very akin to a complex formal method. But it produces code that is easier to read, modify and extend, and in general saves you from a lot of headaches. I've been wanting to write this down for a while, and I think your question is a good excuse to do it.
The main problem with OOP techniques arises whenever a group of object must alter the internal state simultaneously, as a result of an external request, dictated by business logic. For instance, when a person is hired, lots of stuff happen. 1) The employee must be configured to point to his department; 2) he must be added to the list of hired employees in the department; 3) something else must be added somewhere else, like a copy of the contract (maybe even a scan of it), insurance information and so on. The first two actions that I cited are exactly an example of establishing (and maintaining, when the employee is fired or transferred) a bidirectional association, like the one you described between customers and orders.
In procedural programming Person, Department and Contract would be structures, and a global procedure like hirePersonInDepartmentWithContract associated to the click of a button in an user interface would manipulate 3 instances of these structures by the means of three pointers. The entire business logic is inside this function, and it must take into consideration every possible special case while updating the state of these three objects. For instance, there is the possibility that when you click the button to hire someone, he is already employed in another department, or even worse in the same. And computer scientists know that special cases are bad. Hiring a person is basically a very complex use case, with lots of extensions which don't happen very often, but that must be considered.
Real OOP mandates instead that objects must exchange messages to accomplish this task. The business logic is split among the responsibilities of several objects. CRC cards are an informal tool to study business logic in OOP.
To get from the valid state where John is unemployed, to the other valid state where he is a project manager at the R&D department, it is necessary to go through a number of invalid states, at least one. So there is an initial state, an invalid state and a final state, and at least two messages exchanged between a person and a department. You can also be sure that one message must be received by the department, to give it a chance of altering its internal state, and another one must be received by the person, for the same reason. The middle state is invalid in the sense that it doesn't really exist in the real world, or maybe exists but is of no importance. However, the logical model in your application must in a way keep track of it.
Basically the idea is that when the human resource guy fills the "New Employee" JFrame and clicks the "Hire" JButton, the selected department is retrieved from a JComboBox, which in turn may have been populated from a database, and a new Person is created based on the information inside the various JComponents. Maybe a job contract is created containing at least the name of the position and the salary. Finally there is appropriate business logic that wires all the objects together and triggers updates for all the states. This business logic is triggered by a method called hire defined in class Department, which takes as arguments a Person and a Contract. All of this may happen in the ActionListener of the JButton.
Department department = (Department)cbDepartment.getSelectedItem();
Person person = new Person(tfFirstName.getText(), tfLastName.getText());
Contract contract = new Contract(tfPositionName.getText(), Integer.parseInt(tfSalary.getText()));
department.hire(person, contract);
I would like to stress what's going on at line 4, in OOP terms; this (which in our case is the ActionListener, is sending a message to department, saying they must hire person under contract. Let's have a look at a plausible implementation of these three classes.
Contract is a very simple class.
package com.example.payroll.domain;
public class Contract {
private String mPositionName;
private int mSalary;
public Contract(String positionName, int salary) {
mPositionName = positionName;
mSalary = salary;
}
public String getPositionName() {
return mPositionName;
}
public int getSalary() {
return mSalary;
}
/*
Not much business logic here. You can think
about a contract as a very simple, immutable type,
whose state doesn't change and that can't really
answer to any message, like a piece of paper.
*/
}
Person is way more interesting.
package com.example.payroll.domain;
public class Person {
private String mFirstName;
private String mLastName;
private Department mDepartment;
private boolean mResigning;
public Person(String firstName, String lastName) {
mFirstName = firstName;
mLastName = lastName;
mDepartment = null;
mResigning = false;
}
public String getFirstName() {
return mFirstName;
}
public String getLastName() {
return mLastName;
}
public Department getDepartment() {
return mDepartment;
}
public boolean isResigning() {
return mResigning;
}
// ========== Business logic ==========
public void youAreHired(Department department) {
assert(department != null);
assert(mDepartment != department);
assert(department.isBeingHired(this));
if (mDepartment != null)
resign();
mDepartment = department;
}
public void youAreFired() {
assert(mDepartment != null);
assert(mDepartment.isBeingFired(this));
mDepartment = null;
}
public void resign() {
assert(mDepartment != null);
mResigning = true;
mDepartment.iResign(this);
mDepartment = null;
mResigning = false;
}
}
Department is quite cool.
package com.example.payroll.domain;
import java.util.Collection;
import java.util.HashMap;
import java.util.Map;
public class Department {
private String mName;
private Map<Person, Contract> mEmployees;
private Person mBeingHired;
private Person mBeingFired;
public Department(String name) {
mName = name;
mEmployees = new HashMap<Person, Contract>();
mBeingHired = null;
mBeingFired = null;
}
public String getName() {
return mName;
}
public Collection<Person> getEmployees() {
return mEmployees.keySet();
}
public Contract getContract(Person employee) {
return mEmployees.get(employee);
}
// ========== Business logic ==========
public boolean isBeingHired(Person person) {
return mBeingHired == person;
}
public boolean isBeingFired(Person person) {
return mBeingFired == person;
}
public void hire(Person person, Contract contract) {
assert(!mEmployees.containsKey(person));
assert(!mEmployees.containsValue(contract));
mBeingHired = person;
mBeingHired.youAreHired(this);
mEmployees.put(mBeingHired, contract);
mBeingHired = null;
}
public void fire(Person person) {
assert(mEmployees.containsKey(person));
mBeingFired = person;
mBeingFired.youAreFired();
mEmployees.remove(mBeingFired);
mBeingFired = null;
}
public void iResign(Person employee) {
assert(mEmployees.containsKey(employee));
assert(employee.isResigning());
mEmployees.remove(employee);
}
}
The messages I defined have, at the very least, very pittoresque names; in a real application you might not want to use names like these, but in the context of this example they help to model the interactions between objects in a meaningful and intuitive way.
Department can receive the following messages:
isBeingHired: the sender wants to know whether a particular person is in the process of being hired by the department.
isBeingFired: the sender wants to know whether a particular person is in the process of being fired by the department.
hire: the sender wants the department to hire a person with a specified contract.
fire: the sender wants the department to fire an employee.
iResign: the sender is likely an employee, and is telling the department that he is resigning.
Person can receive the following messages:
youAreHired: the department sends this message to inform the person that he is hired.
youAreFired: the department sends this message to inform the employee that he is fired.
resign: the sender wants the person to resign from his current position. Note that an employee who was hired by another department can send the resign message to himself in order to quit the old job.
The fields Person.mResigning, Department.isBeingHired, Department.isBeingFired are what I use to encode the aforementioned invalid states: when either one of them is "non-zero", the application is in an invalid state, but is on its way to a valid one.
Also note that there are no set methods; this contrasts with the common practice of working with JavaBeans. JavaBeans are in essence very similar to C structures, because they tend to have a set/get (or set/is for boolean) pair for every private property. However they do allow for validation of set, for instance you can check that a String being passed to a set method is not-null and not empty and eventually raise an exception.
I wrote this little library in less than a hour. Then I wrote a driver program and it worked correctly with the JVM -ea switch (enable assertions) at the very first run.
package com.example.payroll;
import com.example.payroll.domain.*;
public class App {
private static Department resAndDev;
private static Department production;
private static Department[] departments;
static {
resAndDev = new Department("Research & Development");
production = new Department("Production");
departments = new Department[] {resAndDev, production};
}
public static void main(String[] args) {
Person person = new Person("John", "Smith");
printEmployees();
resAndDev.hire(person, new Contract("Project Manager", 3270));
printEmployees();
production.hire(person, new Contract("Quality Control Analyst", 3680));
printEmployees();
production.fire(person);
printEmployees();
}
private static void printEmployees() {
for (Department department : departments) {
System.out.println(String.format("Department: %s", department.getName()));
for (Person employee : department.getEmployees()) {
Contract contract = department.getContract(employee);
System.out.println(String.format(" %s. %s, %s. Salary: EUR %d", contract.getPositionName(), employee.getFirstName(), employee.getLastName(), contract.getSalary()));
}
}
System.out.println();
}
}
The fact that it worked is not the cool thing though; the cool thing is that only the hiring or firing department is authorized to send youAreHired and youAreFired messages to the person that is being hired or fired; in a similar way, only a resigning employee can send the iResign message to its department, and only to that department; any other illegitimate message sent from main would trigger an assertion. In a real program you would use exceptions instead of assertions.
Is all of this overkill? This example is admittedly a little extreme. But I feel like this is the essence of OOP. Objects must cooperate to achieve a certain goal i.e. changing the global state of the application according to predetermined pieces of business logic, in this case hiring, firing and resign. Some programmers think that business problems are not suited for OOP, but I disagree; business problems are basically workflows, and they are very simple tasks by themselves, but they involve a lot of actors (i.e. objects), which communicate through messages. Inheritance, polymorphism, and all the patterns are welcome extensions, but they are not the base of the object-oriented process. In particular, reference-based associations are often preferred to implementation inheritance.
Note that by using static analysis, design-by-contract and automatic theorem provers, you would be able to verify that your program is correct, for any possible input, without running it. OOP is the abstraction framework that enables you to think this way. It is not necessarily more compact than procedural programming, and it does not automatically lead to code reuse. But I insist that it is easier to read, modify and extend; let's have a look at this method:
public void youAreHired(Department department) {
assert(department != null);
assert(mDepartment != department);
assert(department.isBeingHired(this));
if (mDepartment != null)
resign();
mDepartment = department;
}
The business logic relevant to the use case is the assignment at the end; the if statement is an extension, a special case that only occurs when the person is already an employee in another department. The first three assertions describe forbidden special cases. If one day we want to forbid this automatic resign from the previous department we only need to modify this method:
public void youAreHired(Department department) {
assert(department != null);
assert(mDepartment == null);
assert(department.isBeingHired(this));
mDepartment = department;
}
We can also extend the application by making youAreHired a boolean function, which returns true only if the old department is ok with the new hiring. Obviously we may need to change something else, in my case I made Person.resign a boolean function, which in turn may require Department.iResign to be a boolean function:
public boolean youAreHired(Department department) {
assert(department != null);
assert(mDepartment != department);
assert(department.isBeingHired(this));
if (mDepartment != null)
if (!resign())
return false;
mDepartment = department;
return true;
}
Now the current employeer has the final word in determining whether an employee can be transferred to another department. The current department could delegate the responsibility of determining this to a Strategy which may in turn take into consideration the projects in which the employee is involved, their deadlines and various contractual constraints.
In essence, adding an order to a customer really is part of business logic. If a bidirectional association is required, and reflection is not an option, and none of the solutions proposed on this and the linked question are satisfactory, I think the only solution is something like this.
first, unless you plan on moving orders between customers, I think you shouldn't provide a setCustomer() method, the customer should be a parameter for the constructor and leave it unchanged.
then, the constructor shouldn't be accessible for the user, only use the factory method of Owner.
There is no single answer. It really depends on the classes involved. In your case, you obviously don't want to give people the option of doing something invalid so I would get rid of Order.SetCustomer.
That may not always be the case though. Like I said, it depends on the classes involved.
If you are maintaining the bidirectional relationship in Customer.placeOrder(Order), why don't you do the same thing in Order.setCustomer(Customer)?
class Order {
private Customer customer;
public void setCustomer (Customer c) {
customer = c;
c.getOrders().add(this);
// ... or Customer.placeOrder(this)
}
}
It seems like duplicating code but it solves the problem. The simpler thing to do though is to avoid bidirectional relationships where possible.
I think the best way in this case is to delegate the responsibility for wiring to another class:
class OrderManager {
void placeOrder(Customer c, Order o){
c.addOrder(o);
o.setCustomer(c);
}
}
class Customer {
private Set<Order> orders = new LinkedHashSet<Order>();
void addOrder(Order o){ orders.add(o); }
}
class Order {
private Customer customer;
void setCustomer(Customer c){ this.customer=c; }
}