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)
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)
