Suhrid Karthik wrote:Implement a Java equivalent of the Tree command.
Mohamed Sanaulla wrote:Cohesion is the degree to which the class is focused one its responsibilities- Highly cohesive classes are desirable.
Lets consider this situation: We have a Student who enrolls for certain subjects as part of the academic requirements. So a Student will have a list of Subjects and other personal details
Now if you see that the classes are specific to what ever responsibilities assigned. Lets make the class Student- less cohesive- lets add one method- getTeacherForSubject() in Student class.
Now you see- its not part of Student to get the name of the teacher for a given subject. Its the responsibility of the Subject to return the name of the teacher. This way the class Student is less cohesive.
(I just thought of some example, hope this clears up the concept)
Coupling: Degree to which the classes are related to each other- Low coupling is desired. If the classes are very closely related to each other- one possibility of this happening is when one class tries to access the fields of other class without using a public method. So any change in the internal implementation of this class will break the other class which was relying on it. Lets use the same example given above.
Now the requirement changes- its said that the numberOfCredits will be calculated based on the numberOfHoursPerWeek. So what happens is that there will be a getter provided in the Subject class to get the number of credits based on the number of hours per week. Now introducing this method breaks the rest of the other classes using the numberOfCredits field directly. So in order to avoid that classes should not be tightly related to each other. They should interact with each other via the public methods only. So the changed class definition would be
Hope these examples help you to understand the concept.
I had written a blog post related to this long back (Sorry for referring to my own blog)
Peter Johnson wrote:Here are my tips:
1) Practice makes perfect. That is, the more programs you write, the more comfortable you will be with it. Think of apps you could write and write them. Try extending existing open source projects. Just do it.
[Also try this - work on a new app. Once you are done, throw the code away and the write it again. You will probably write it different, because of what you learned the first time. Make note of those differences and why you did it differently. This will help you build a coding style and help you refine your skills, as well as teach you what is and is not important.]
[Also try this - write an app and then put it aside. Then 3, 6, 12 months later comes back and try to add some features to the app. After cursing the idiot who wrote the original code, rewrite the app. Repeat this until you are no longer cursing the idiot. You will then be able to write understandable and maintainable code. Note that the time period is critical here - this will not work with code you work with every day or periodically. It will only work if the amount of time has been so long that you don't recall what you did, or more importantly, why.]
2) Look at what others have written. This is one of the great things about open source - you can download and look at code other people have written. Pick a well establish and well thought of project (or several) and examine their source code. (One caveat on this - much of the source code, even from well-established open source projects is awful. Not that it doesn't work, but it often doesn't follow what I would consider to be best practices. Recall what I said about cursing the idiot in the prior tip.)
3) Find a mentor. Having someone with good programming skills and have them review and comment on what you have written.
4) Read algorithmic books. These are texts not on basic programming skill, but on how to best apply those skills to tackle specific problems. Books like the Design Patterns by the Gang of Four fall into this.
5) Read books about polishing your development efforts. Programming is not just about slapping down some code until a simple test case works. Books such as Code Complete come to mind.