'. '

Talk:ClarityOfAccessModifiers

From APIDesign

Jump to: navigation, search

Comments on ClarityOfAccessModifiers

Name (required):

Comment:


Contents

Winheim Raulsh said ...

In Delphi, all methods are assumed to be final. This means that protected final is just protected, public final is just public, and protected abstract is protected abstract. This way methods are final by default, and you don't have this problem; making everything abstract by default has its tradeoffs. Either things are more extensible (and you can shoot yourself in the foot), or things are more restricted and less flexible.

--Winheim Raulsh 22:52, 25 March 2009 (CET)

It seems to me that those who preach OO reuse prefer flexibility. While those who did OO reuse for few years rather see a bit of restrictions to avoid future maintenance madness.

Nothing against flexibility, Delphi approach is flexible enough. But it generates less errors when used in cluelessness mode - a designer needs to think to create a virtual method. That is the important moment. So in fact, the only restriction I am relly advocating is less error prone default.

--JaroslavTulach 13:54, 26 March 2009 (UTC)

Anonymous said ...

Please don't ever apply for a Java developer job at my company. You have such an eccentric, strange view of Java and its Object Oriented design points, that I would have to tear out my hair when reviewing your code. *sigh*

--Anonymous 14:24, 26 March 2009 (CET)

Rob Grainger said ...

The language Eiffel offers a much better set of accessibility restrictions. A set of members is introduced with the 'exports' keyword.

'exports' alone is equivalent to 'exports ANY', rougly equivalent to 'public'.

Otherwise 'exports classname' exports to class 'classname' and descendants, if classname is the current class, this is 'protected'. Otherwise, more like a C++ friend.

Eiffel also introduces other mechanisms to help design resuable libraries that have yet to make the mainstream, inspite of pre-dating many OO languages.

--Rob Grainger 17:53, 26 March 2009 (CET)

Arno Nyhm said ...

please show not only a bad example for the Factorial but also a good solution for this implementation.

--Arno Nyhm 10:42, 27 March 2009 (CET)

I have extended EliminateFuzzyModifiers with real world example to satisfy your request. Enjoy!

--JaroslavTulach 11:14, 4 April 2009 (UTC)

swv said ...

Why don't YOU create that language, since you're the person who seems to have hit the limit on the OO paradigm? So what if you're not a language expert, become one. What better thing were you going to do with your life anyway? This kind of thing seems to have worked out well for Charles Simonyi

--[htttp://www.dlisted.com/node/29432 swv] 00:19, 10 April 2009 (CEST)

Eugene said_

new Factorial().sumRange(1, n); it's not a n!

--Eugene 12:12, 11 May 2014 (CEST)

How comes!? At least we know it is n! for 3, 4, 5, see the FactorialTest:

public void testFactorial3() {
  assertEquals(6, Factorial.factorial(3));
}
 
public void testFactorial4() {
  assertEquals(24, Factorial.factorial(4));
}
 
public void testFactorial5() {
  assertEquals(120, Factorial.factorial(5));
}

of course your comment brings deeper question: How do we know our software is correct? Epistemology tells us that we don't - we just know it is good enough - e.g. correct for envisioned use cases (in my test case it is 3, 4, 5).

--JaroslavTulach 04:31, 14 May 2014 (UTC)

Personal tools