Talk:Hall of fame

What is the rationale of Information hiding being an inviolable law? Why can there NEVER be a case when this can be broken? --Matthew Harward 09:37, 23 July 2009 (UTC)

Oooo that's a really interesting question. How important is info hiding anyway? What was it about info hiding that led to its nomination as inviolable? --Wal 00:32, 24 July 2009 (UTC)

Because information hiding is the foundation to reuse if someone using your class needs to know it's internal workings not just the interface then the class does not have behavioural completeness. --AlexGee 03:32, 24 July 2009 (UTC)

Of course you can always break the laws, even the inviolable ones. You can use gotos, but it is considered harmful. I think the same applies to information hiding: you can make all your attributes public, but I'd consider that harmful too. Maybe it's clearer when you replace 'inviolable' with 'not justifiable'? --TobiW

There is an old joke, a man comes up to a stop light, but instead of fully stopping he keeps driving. I passing cop sees his antics and pulls him over. The cop explains to the man that he needed to stop, but the man claimed, "but I slowed right down." To this, the cop asked the man to get out of the car, he pulls out his truncheon and begins beating the man. The cop then asks the man: "Would you like me to slow down or stop?" I think that this sort of analogy applies in this situation. The term inviolable is equivalent to forbidden, not considered harmful. I would agree that Information hiding is very important, but it is not unquestionable. Maxims such as You ain't gonna need it, Premature optimization and Once and only once have the potential to be violated by this concept. In essence, I draw your attention to No silver bullet. Sure, IH is very important, but there are times when other factors may conspire to make it the logically less attractive choice... Or am I just shaking the coconut palm? --Matthew Harward 10:48, 28 July 2009 (UTC)

Hmm, I think that information hiding is probably better of in the "most excellent ideas section" rather than the inviolable laws section as well. I see your point Matthew about how some other principles could potentially conflict with information hiding but I think that information hiding is hugely fundamental because following it provides a large number of related benefits (e.g. lower coupling, better modifiability) that I think it would still be logically highly attractive even when looking at the other maxims you brought up. --Janina

---

Command query separation - I’ve added Command query separation to ‘Most excellent ideas’ to sit beside Design by contract. An exception would be a stack. -BenMcDonald 12:01, 28 July 2009 (UTC)

Sounds good to me! --Matthew Harward 20:57, 28 July 2009 (UTC)

I changed my mind and moved Command query separation to Inviolable laws. I think a stack should have a query to look at the top object, even if another method(command) removes and retrieves it. This is because if you have an immutable object, like a returned attribute of an object, then you can only perform queries on it. If queries have not been separated then immutable objects become useless and immutable object should be very useful not useless. Which segways into my next maxim placement of Don't expose mutable attributes as an Inviolable laws. --BenMcDonald 12:30, 6 October 2009 (UTC)

I agree that this law is important, but as I read it, this law applies to any command/query applied to an object. This law seems to suggest that, as command and query are separate, that either the calling object should be responsible for keeping the object in a valid state or the we are going to duplicate functionality, breaking DRY. For example,

String theString;
boolean isValid(String testString) { //<--Query
    return list.contains(testString);
}

boolean void setString(String newString) { //<-- Command
    if (isValid(newString)) // We want a class to control its data
        theString = newString;
}

We have followed the CQS... Yet when we call this it seems counter intuitive... as our calling would proceed as follows...

if(obj.isValid(myString)) //We want to be able to discover if an operation will/has worked...
    obj.setString(myString);

We seem to be repeating ourselves. What am I missing? I know this a VERY contrived example. --Matthew Harward 04:22, 8 October 2009 (UTC)

Well I went back over what I said and CQS is more rigorous than I thought it was. I was advocating “always having an object queryable”, like the peek() method in a stack, which is not quite CQS. It turns out that Martin Fowler has said what I wanted to say and better http://martinfowler.com/bliki/CommandQuerySeparation.html.

He muses on the idea of a language enforcing this and then remembers C++ “The only case I've really come across it is the const modifier in C++. Since I haven't used C++ for many years it's hard for me to assess how useful it is in practice. My sense is that C++ers use const a lot and like it.”

Yes and yes, a const modifier is very helpful.

“This is because you can use queries in many situations with much more confidence, introducing them anywhere, changing their order. You have to be more careful with modifiers.”

But I was thinking more about immutability.

I think in your code examples you are getting more into DBC and so my answer is 'I have no idea'.

--BenMcDonald 00:58, 9 October 2009 (UTC)

---

Behavioral completeness - The article A New Vision of Object-Oriented Programming reminded me of behaviour completeness when it talked about objects being about human understanding. Software quickly becomes very complex and maintaining an understanding of the software is important. I find behaviour completeness of objects is always important when trying to get my head around code. It is easy, although, to find tempting departures from this rule. Like the example in class where a 'Frog' can save itself in XML. --BenMcDonald 15:54, 25 August 2009 (UTC)

So just to clarify, the frog having the ability to save itself to XML is not behaviourally complete, right? --Matthew Harward 02:29, 26 August 2009 (UTC)

Yeah. That was an example of an object not being behaviourally complete. I don't know if it's justified. We also discussed in class changing the design to include a visitor pattern so that the Frog object could retain behavioural completeness. --BenMcDonald 03:24, 26 August 2009 (UTC)

---

Keep it simple is conceptually very similar to Don't repeat yourself... Maybe their should be a closer in terms of status on this page? --Matthew Harward 02:29, 10 September 2009 (UTC)

The interesting thing about DRY as an inviolable law is that this is a really strict rule to follow. As the authors of the rule say, it's not just code but things such as data schemas. So to have a single authority on each piece of data requires "code generation tools, automatic build systems, and scripting languages". Maybe we need to be this strict and do this but I know that I currently don't. --BenMcDonald 12:49, 6 October 2009 (UTC)

That is fair enough. I would say that DRY should be an ultimate goal, but Keep it simple really should trump it. I would say that my belief on the importance of DRY is probably something related to Shannon's information theory, if we repeat ourselves then we are duplicating data. The other part, oc, is that DRY means that a change in one place is the only change needed, hence vastly improving maintainability --Matthew Harward 04:00, 8 October 2009 (UTC)

Yes, DRY should be an ultimate goal so that data are maintainable and in sync. Better programming tools will help with this. --BenMcDonald 03:12, 9 October 2009 (UTC)

---

I think Don't expose mutable attributes should be moved from "Inviolable laws" to "Most excellent ideas" or even "Helpful ideas". Suppose a class contains a collection of Foo objects and wants to allow its clients to be able to access items in it. It could create a getter that makes an immutable copy of the collection, but this could be problematic in performance sensitive contexts (this could easily turn an O(n) algorithm into an O(n^2) algorithm, for example - but beware Premature optimization). Alternatively it could provide additional methods for various functions, such as getFooAtIndex(int index), getIndexOfFoo(Foo f), etc. However this adds interface clutter and violates One key abstraction and Keep it simple. Other considerations are frameworks such as Cocoa where a mutable array is a subclass of a standard (immutable) array. Is it then OK to return a mutable array in a getter provided the return type is the immutable superclass? Finally, there's a blurry line about what exactly is defined as an attribute. Suppose you have a Window class which contains a View object representing the root view in the window's view hierarchy. Does this count as an attribute? If not, what makes it different from a Collection attribute? If so, should clients have to go through methods in the Window object to modify the View object? --Stephen Fitchett 07:41, 10 October 2009 (UTC)