DOC PREVIEW
FIU COP 2210 - Some Class and Program Design Guidelines

This preview shows page 1 out of 4 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 4 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 4 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Some Class and Program Design GuidelinesII. Avoid Unnecessary Class CouplingIII. Avoid Side EffectsIV. Not All Side Effects Are BadComputer Programming I Instructor: Greg ShawCOP 2210 Some Class and Program Design GuidelinesI. Strive for Cohesion- A class represents a single concept.- If the class interface (i.e., the public methods andconstants) are all closely related to the concept the classrepresents, then the class is said to have good cohesion.- If not, then we should rewrite the class as two or moreseparate classes. For example, CH’s CashRegister class (Section 4.2) containselements of two concepts: a cash register (collection ofcoins) and the individual coins themselves. These should beseparate classes. That way, a CashRegister object could –without any modification - process purchases in the currencyof any country, rather than be limited to just the currencydeclared in the CashRegister class.II. Avoid Unnecessary Class Coupling- A class “depends on” another class if it creates objects,uses constants, or calls static methods of that class.- If multiple classes in a program depend on one another thenwe say that there is a high degree of coupling among theclasses. The fewer the dependencies, the lower the degree ofcoupling.Why is coupling to be avoided?1. If it becomes necessary to modify a class, then allclasses that depend on it may be affected and it may benecessary to modify them too.2. If we wish to reuse a particular class in a program, andthat class depends on other classes, then we are obligedto take those other classes along as well.III. Avoid Side Effects- Recall that a method’s implicit parameter is the object forwhich the method is called.- A side effect is any behavior in a method – other thanmodifying the implicit parameter (i.e., what mutator methodsdo) - that can be observed outside the method.- One example of a side effect is changing the value of anexplicit parameter. This is not something we normallyexpect methods to do, and so may be surprising toprogrammers using the class.- Example: The GradeBook method addStudents has an explicitparameter called studentNames, which is a list of names tobe added to the GradeBook. The addStudents method has aside effect: as it adds the names to the GradeBook, itremoves them from the studentNames list. This is anunexpected behavior and should be avoided.public class GradeBook{. . ./** Adds student names to the gradebook. @param studentNames a list of names to be added*/ public void addStudents(ArrayList<String> studentNames){ while (studentNames.size() > 0) { String name = studentNames.remove(0) ; // bpp!// add name to GradeBook } }}- Another side effect to be avoided is doing output! This isa bad idea because:1. It assumes that the user of the program speaks English,and a majority of Earthlings does not.2. It assumes that a standard output device is available.In the case of embedded systems (e.g., an ATM machine’scomputer), this is not the case.(Further, it increases coupling by making the classdependent on the System and PrintStream classes.) Instead of doing output, it is preferable to have amethod simply return a value and let the user of theclass decide what they want to do with it.IV. Not All Side Effects Are BadModifying a method’s explicit parameters is a side effect, but isnot a bad programming practice if it is expected.For example, consider the transferFunds method of the BankAccountclass, which modifies both its implicit and explicit BankAccountparameters. Since a transfer of funds always involves modifyingtwo account balances, this particular side effect is not at allunexpected.public class BankAccount{ . . . /** Transfer funds from this account to another account @param amount the amount of money to be transferred @param another the account receiving the funds */ public void transferFunds(double amount, BankAccount another) { another.balance = another.balance + amount ;this.balance = this.balance - amount ;


View Full Document

FIU COP 2210 - Some Class and Program Design Guidelines

Download Some Class and Program Design Guidelines
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Some Class and Program Design Guidelines and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Some Class and Program Design Guidelines 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?