Writing Good Code Flashcards Preview

Ruby Language > Writing Good Code > Flashcards

Flashcards in Writing Good Code Deck (14):

What is "tell-dont-ask" and why is it useful?

When working with a object, it is better to tell the object what to do (by calling an instance method on the object) rather than querying the internal state of the object and then deciding what to do to that object.

This is useful because it decreases coupling by encapsulates the logic involved in changing a given object's state to instance methods within that object.


What's a data clump, what's an example, why is it a code smell, and how can it be improved?

When you have two variables that always travel together through the code.

An example would be start_date and end_date.

This is a smell because those values are coupled together, and forgetting to include one may lead to problems.

A data clump can be improved by encapsulating the variables into an object.


What is parameter coupling?

Method A calls Method B. Method B may fail based on the type of parameter passed to it from Method A.


How do you lower parameter coupling?

Decrease the amount of parameters a method takes. 2 is better than 3, 1 is better than 2, and 0 is better than 1.


What is feature envy? What can be done about it?

A code smell. It's when a class is very concerned with the internal state of another object.

This can be corrected by moving the logic out of the envious class and into the class of concern.


When a class is very concerned about the internal state of another object, what do we call this code smell?

Feature envy.


What quality will make public methods easier to use by yourself and others looking at your code for the first time?

Readability. Keep your public API simple and move implementation details into private methods. Users of your class (including you 3 months down the road) will care less about the implementation details and more about the readability of the public methods.


Why is it a good idea to keep your public methods readable?

It's easier for others to use your code as they don't have to spend much time understanding how it works.
(Remember, 3 months down the road, you'll likely forget quite a bit of those implementation details, and will spend extra time grokking hard-to-read code in public methods.)


What pattern is useful when you may conditionally have a nil value for an object? What is it? Why is it useful?

Null Object pattern.

It creates a sort of mock object that can stand in for when we receive nil for a factory method.

This allow us to remove "if obj.nil?" logic out of our classes. It also encourages us to encapsulate that logic within a non-null object, for instance, a Contact object that pairs with a NullContact object.


What type of refactoring does a Null Object pattern implement?

Replace conditional to Polymorphism.

Rather than use if's, we send the same message to different classes and obtain different behavior.


When is a good time to refactor?

When going in to change code. Do the refactor in such a way that it allows the change to be easy to write.


How do you figure out which objects are the "God" objects?

Sort the model objects files by number of lines.


What principle does long-chaining potentially violate?

The Law of Demeter: only talk to your neighbors. Only use one dot.


Should you write tests for private methods? Why or why not?


Private methods are implementation details.

They're not "what does it do?" but rather "how does it do that" and that's not any other class's business.