1 / 13

Elements of Design - Simple Smells

Elements of Design - Simple Smells. Basic Design Mistakes. A Class should have. Class Person { String getName(); void setName(String name); int getAge(); void setAge(int age); Car getCar(); void setCar(Car car); } What do we see ?

alaric
Download Presentation

Elements of Design - Simple Smells

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Elements of Design -Simple Smells

  2. Basic Design Mistakes

  3. A Class should have • Class Person { • String getName(); • void setName(String name); • int getAge(); • void setAge(int age); • Car getCar(); • void setCar(Car car); • } • What do we see ? • A class should have one main responsibility and some behavior not just holding state • Minimal access to its data!

  4. Confusing • Class City extends Place { … } • Class Jerusalem extends City implements Capital { … } • Class TelAviv extends City { … } • What is wrong here? • Confusing inheritance and instantiation • Too much inheritance?

  5. Do not expose implementation

  6. Do not overuse conversions • nodes asSet • removes all the duplicated nodes (if node knows how to compare). But a systematic use of asSet to protect yourself from duplicate is not good • nodes asSet asOrderedCollection • returns an ordered collection after removing duplicates • Look for the real source of duplication if you do not want it!

  7. Hiding missing information • Dictionary>>at: aKey • This raises an error if the key is not found • Dictionary>>at: aKey ifAbsent: aBlock • Allows one to specify action aBlock to be done when the key does not exist. • Do not overuse it: • nodes at: nodeId ifAbsent:[ ] • This is bad because at least we should know that the nodeId was missing

  8. Avoid returning nil • Avoid to return special results as nil • messages := self fetchMessages. • messages isNil •   ifFalse: [ messages dispatchFrom: self ] • What if we would simply return an empty collection in • fetchMessages instead of nil? • Less conditional and ugly tests!!

  9. Objects not strings! • Strings are dead objects • You can only concatenate strings • Use objects not their textual representation

  10. Objects not tuples! • spec first • spec second • spec third • spec action • spec selector • spec menuItem • And add a printing • aSpec(‘open’, #openBrowser, ‘open (O)’)

  11. Tell, Don’t Ask • no condition and case based on the receiver type • Use polymorphism as much as possible to avoid type checking

  12. Tell, Don’t Ask! • MyWindow>>displayObject: aGrObject • aGrObject displayOn: self • And not: • MyWindow>>displayObject: aGrObject • aGrObject isSquare ifTrue: […] • aGrObject isCircle ifTrue: […] • …

  13. Don’t violate encapsulation • No overuse of accessors • Encapsulation principle: minimize data representation dependencies • Offer complete interface

More Related