Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm reading Code Complete 2, and I'm at the chapter where it says to (paraphrasing) "avoid programming through the interface." Why is it bad to program "through" the interface?

A more concrete example: if I have a method of a class that submits a funny picture, what's wrong with it logging me in also? Should I simply provide more "helper" methods that do it automatically?

Would it be preferred to break it up into:

  • set_login(username, password)
  • login()
  • submit_picture(funny_picture)
  • easy_submit(funny_picture) # where it will log in (if not already) and submit
share|improve this question

3 Answers 3

up vote 7 down vote accepted

In general, shorter methods are more readable and easier to test with unit tests. Even if you do not plan to reuse the login and/or submit method, breaking it down makes testing and maintenance easier.

share|improve this answer

It's elementary, my dear Watson! Code Reuse. When you separate the task of login and sending picture, some one else can also use your login, and someone else can also use your send_picture. Moreover if you have login and send_picture separate, how difficult is it to create easy_submit?

share|improve this answer

Wrong or correct it depends on the level which that code is going to be used of. What will happen, if you want to submit more than one picture? On this example, I would divide it into two levels, say, core and application. The core level provides basic facilities (login(u, p) and submit_data(data, type)), and the application layer provides helper methods. And would use them appropriately depending on the context.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.