427 design standard
From CSSEMediaWiki
(Difference between revisions)
(→Getters and setters) |
|||
Line 6: | Line 6: | ||
* Always call getter, even in same object. | * Always call getter, even in same object. | ||
− | + | This standard was influenced by the [[Getters and setters]] and [[Encapsulation boundary]] ideas. | |
− | : | + | :Here's an alternative set of guidelines our group came up with: |
+ | :* Always make fields have ''private'' access. | ||
+ | :* Only write getters and setters as needed. | ||
+ | :* External: access to fields using getters and setters. | ||
+ | :* Internal: access to fields directly, but only if it's the same object. Use getter and setters if same class, but different objects. | ||
+ | :* Getters should be read-only (i.e. Collections should be returned as unmodifiable Collections) | ||
+ | ::--[[User:Yugan Yugaraja|Yugan]] 06:09, 23 July 2008 (UTC) | ||
+ | |||
+ | :::Agreed, I prefer ''private'' access to instance variables, One's private bit is private, though it is protected, it is still private. Also, we have agreed to minimize access so private is the most minimum access for one's private bit. --[[User:Johannes Pagwiwoko|Jojo]] 02:48, 30 July 2008 (UTC) | ||
== Nouns == | == Nouns == |
Revision as of 09:31, 30 July 2008
What rules do we all agree on? Let's write them here so everybody can follow them in their design study.
Getters and setters
- Always make fields have protected access.
- Always write a getter, but minimize access.
- Always call getter, even in same object.
This standard was influenced by the Getters and setters and Encapsulation boundary ideas.
- Here's an alternative set of guidelines our group came up with:
- Always make fields have private access.
- Only write getters and setters as needed.
- External: access to fields using getters and setters.
- Internal: access to fields directly, but only if it's the same object. Use getter and setters if same class, but different objects.
- Getters should be read-only (i.e. Collections should be returned as unmodifiable Collections)
- --Yugan 06:09, 23 July 2008 (UTC)
- Agreed, I prefer private access to instance variables, One's private bit is private, though it is protected, it is still private. Also, we have agreed to minimize access so private is the most minimum access for one's private bit. --Jojo 02:48, 30 July 2008 (UTC)
Nouns
When discussing the Frogs design we came up with a new principle/heuristic in class: Class names should be nouns. Do we (collectively as a class) want to make this a principle? --Yugan 04:14, 23 July 2008 (UTC)
- Yup, I'm cool with it...Hmm do we think this is more of a coding/design standards? --Jojo 04:23, 23 July 2008 (UTC)
- What about interfaces? Should we make them nouns as well? But I have seen many cases (including this one) where interfaces represent behavior, so is it still a good idea? --Yugan 04:57, 23 July 2008 (UTC)
- Yea, I think nouns generally would be a good idea. As for that case, you can name it in a "verb+able" format which conveys capability (eg: Move+able = Movable), sweet no? =D --Jojo 05:42, 23 July 2008 (UTC)
- Or we can use C# convention of having 'I+noun' or 'I+whatever' format, ahaha, I have no idea now. But now when I think about it...Movable gives a sense that the Frog can be moved which doesnt really what we want. Maybe...MoveAbility (or IMoveAbility)? --Jojo 05:59, 23 July 2008 (UTC)
- I think the C# convention of using 'I' prefix for interface names is a good idea too (e.g. IComparable). But I think interfaces could be verbs too, where classes should only be nouns. --Yugan 03:14, 29 July 2008 (UTC)
- What about interfaces? Should we make them nouns as well? But I have seen many cases (including this one) where interfaces represent behavior, so is it still a good idea? --Yugan 04:57, 23 July 2008 (UTC)