We categorize an object’s peers (loosely) into three types of relationship. An object might have:
Dependencies: Services that the object requires from its peers so it can perform its responsibilities. The object cannot function without these services. It should not be possible to create the object without them. For example, a graphics package will need something like a screen or canvas to draw on–it doesn’t make sense without one.
We’ve read the second chapter from the Practical Object-Oriented Design in Ruby, by Sandi Metz.
These are the concepts and links brought up during the discussion:
Data Clump at the bliki Refactoring with Loops and Collection Pipelines, indirect link to the article by Martin Fowler When Worse Is Better: Incrementally Escaping Local Maxima, indirect link to the article by Kent Beck Getting It Right by Betting on Wrong, indirect link to an article by Sandi Metz
Organizing Code to Allow for Easy Changes Asserting that code should be easy to change is akin to stating that children should be polite; the statement is impossible to disagree with yet it in no way helps a parent raise an agreeable child. The idea of easy is too broad; you need concrete definitions of easiness and specific criteria by which to judge code. If you define easy to change as
I was changing a massive amount of files (>1000) for a repeated code. The search and replace query was not too exact and it broke many tests in the system. For that, I preferred reverting those tests.
Here’s how to do it automatically:
Copy all the failing tests to a text editor:
Input:
testSearchXMLDocument(io.company.controller.dms.DocumentControllerTest) testCreateXMLDocument(io.company.controller.dms.DocumentControllerTest) testUpdateXFPageMetadata(io.company.controller.dms.DocumentControllerTest) testCreateDocumentCrop(io.company.controller.dms.DocumentControllerTest) testUpdateCropMetadata(io.company.controller.dms.DocumentControllerTest) testDeleteDocument(io.company.controller.dms.DocumentControllerTest) testUpdateXmlDocumentMetadata(io.company.controller.dms.DocumentControllerTest) testUpdateXML(io.company.controller.dms.DocumentControllerTest) testSearchXFPage(io.company.controller.dms.DocumentControllerTest) testCreateXFPage(io.company.controller.dms.DocumentControllerTest) testUpdatePage(io.company.controller.dms.DocumentControllerTest) testSearchCrop(io.company.controller.dms.DocumentControllerTest) testUpdateCrop(io.company.controller.dms.DocumentControllerTest) testMoveDocument(io.company.controller.dms.DocumentControllerTest) testGetDocument(io.company.controller.dms.DocumentControllerTest) regex:
(tested in Sublime 3, build 3083, Windows 64)
I was prefer committing to the repo with commits that are as small as possible as long as it makes sense. It makes it much easier to rever the changes.
This is why I have some scripts to commit all the changes, even with the same message. This is one of them:
for f in $(git status -s |grep "^M"|awk '{print $2}'); do git add $f git commit -m "generic commit for all files" done
Note: all quotes on this post come from this paper: Strachey, C. Fundamental Concepts in Programming Languages. Published in Higher-Order and Symbolic Computation, 13, 11–49, 2000.
Contents This paper starts slow, from the mathematical and philosophical point of view, until it gets to the basic concepts on the fundamental concepts:
Assignment command L-Value and R-Value Definitions Names Numerals Conceptual models: an explanation about the relationship between the code, the memory store and the abstract concepts Later, it gets more in depth to the conceptual constructs, where most of the content is explained and contains: