I'm very confused over what a control object actually is. Suppose that I have a BankAccount Java object, and a database with a BankAccount table. Should I consider the Java BankAccount object as a control object, and let it change the database with its deposit() and withdraw() methods, or should there be a separate BankAccountControl Java object that changes the database? With the first way, I instinctively think of the BankAccount object as an entity object, but the second way seems like procedural programming rather than object-oriented.
Joined: Apr 16, 2008
I have never heard of the term "control object" and do not understand what you may be referring to.
In regards to software design there are typically, many, many different ways something can be designed and programmed into a working solution.
For your simple example, there could be a business object which does the actual currency math equations for deposit, withdraw, and any other business logic. Then in regards to actually storing the data in a database, there would be another object (Data Access Object (DAO)) which would handle putting data in a database table, reading data from a database table, and any other operations related to data in a database.
So, the business object is what changes data via the DAO. The DAO class is where the actual SQL statements are, not in the business object class. The business object and the DAO work together and each object is responsible for specific operations.
Welcome to JavaRanch - A friendly place for Java Greenhorns!
Joined: Nov 20, 2003
If you are refering to the Entity-Control-Boundary Pattern (ECB) patter. The ECB is a variation of the Model-View-Controller Pattern.
In the case of ECB you are correct. The Java BankAccount object is indeed the controller.
If you would like to have a clear example on how to separate these concerns in a different manner.
You could also have a look at the DAO pattern.