The controller (in MVC) translates user actions into business logic actions. Keep controllers small, and be consistent in how you split them up.
The god object smell is too many responsibilities in one object.
A book that we (and you) should absolutely read as soon as possible: Working With Legacy Code by Michael Feathers. We also discussed books by Kent Beck, which are also recommended reading.
A region in C# is for use with Visual Studio to collapse and expand views of code.
The refactor called Sprout Class is to extract a class out of an enormous file of code, so you can test the little extracted class. Future TWUers: minor refactorings like this will become part of your thinking, rather than a separate concept.
"Test-friendlies" are collaborators that you can trust and directly instantiate. Encapsulation promotes maintainability. I asked a question about YAIGNO vs elegance and where on the scale one should fall. A trainer answered that "This is a debate that you'll be having with yourself for the rest of your career." So just keep that in mind.
It turns out that "Try to make the code represent the domain that you're writing in" means "When you go to the codebase, you should see the same terms that the client uses." I didn't know in what way the code should represent the domain! I thought that he meant in structure... but now that I know that he meant key terms, it makes more sense. This is different from domain-specific language even though the term sounds similar.
Us TWUers may have the honor of being able to read (and give feedback on) a chapter on encapsulation that Jim is submitting to the next TW Anthology.
We did a short pair-programming exercise on implementing the class Rectangle, and another one on implementing the class Chance and making its not() work. This is basic stuff, but it was more to teach us about pair programming and understanding logic flow and requirements than anything else. I think the assignment did its job admirably.
Packages and naming of packages: I somehow exited university with no grasp of how or why. Now I know both, at least somewhat.
"If you use inheritance, use polymorphism." "Inheritance is very costly, very expensive. Make sure that you're getting something for it."
Value objects are: mutable, easier than immutable, passed by value, and provide seams for testability. Tomorrow we learn about source code management.
Identity/compare functions should be reflexive, transitive, symmetric, and consistent. (If they aren't, is it on purpose?)
If you use Visual Studio, you will probably benefit from using the Resharper plugin.
Future TWUers:
You will want a notebook during the first two weeks of TWU. You can find them in the red cabinet near the big printer in B1, or just ask around.
Also, you will rapidly become a power user of IntelliJ, but the learning curve (for both program structure, and keybindings) is steep and may feel unpleasant. Give in to the power of option-shift-A for accessing the refactoring menu. Resist the urge to navigate by mouse. Ctrl-B will go to the originator of the variable/method/class which you currently have highlighted. To pull up the rename menu, use shift-F6. Avoid renaming things without the rename menu if they are in wide usage.
Play around with git and svn a bit. You can make yourself a github repository and experiment with it, then delete it if you want. If you are assigned a PC by 8600, strongly consider getting it dual-booting some form of *NIX, and/or run a virtual machine, depending on your preferences. This will affect your security arrangements but it can be worked around- just ask the help desk people; they're excellent.
I am having some difficulty adjusting to using a Mac, but I know it'll be worth it.
"If you don't know where to put behavior, maybe you need another class." <- this was very helpful to me. Also, "Don't expose size unless you have to; use iterator." (if you're using size to iterate over something)
Sonar makes reports on metrics of code. It is very useful for getting an overview of a codebase too large to read ("thousands of classes"). In smaller codebases, it help you monitor your test coverage. You want to install Sonar on your ci (checkin) server in such a way that when someone pushes code to your repository, your CI server will re-build the project and then trigger Sonar to run.
* problem : our fix (in the practice codebase)
* loop doing too many things : split loop
* feature envy : move method
* too many parameters : extract class (created History class)
* magic numbers : constants i.e. express intent by using variable names
* temporary variables : inline
* violating law of Demeter : create getter in Movie for title instead of calling though
Law of Demeter - only talk to your immediate neighbor. too many calls chained is called a train wreck.
minGW, cygwin, and puTTy are all *nix commandline emulators. Of the three, I prefer puTTy for its UI, but they're all pretty equivalent.
The trainers recommend that analysts should look into software which creates wireframes quickly and easily, rather than mocking them up in Illustrator. For these things, you need intermediate steps or the client will mistake a picture of the thing for the final object.
There's a google app called browsersize which helps you test your webpage in different browsers and monitor sizes etc so you can see where the fold goes.
