Reputation
1,564
Top tag
Next privilege 2,000 Rep.
Edit questions and answers
Badges
9 14
Newest
 Yearling
Impact
~250k people reached

  • 0 posts edited
  • 0 helpful flags
  • 144 votes cast
2d
comment If I implement an Interface, is it called an Inheritance?
Once you look at it that way, it's pretty clear that pre java-8 interfaces had nothing to do with the common usage of the term "Inheritance" (which is class inheritance). This is where most java programmers have an initial negative reaction to this answer... we're old-school and not used to these new-fangled functional constructs.
2d
comment If I implement an Interface, is it called an Inheritance?
I've been thinking about what bothers me so much about the terminology around inheriting abstract interface methods into abstract classes and it's that we are using the unqualified word "Inheritance". It seems much cleaner if we clearly specify the two kinds of "Inheritance", interface and class. The two terms cross over slightly in that a class can inherit a default method from an interface using "class inheritance" and a class can inherit an abstract method requirement from an interface using "Interface Inheritance". (Those two exceptions being the answer to this question).
2d
comment If I implement an Interface, is it called an Inheritance?
By the way, with the updates I think this is a fantastic answer.
2d
comment If I implement an Interface, is it called an Inheritance?
@ian it would not be inheritance. Only default methods (because they have an implementation) are REALLY inherited (With the slight and strange exception of inheriting the requirement to implement an abstract method). In general I would just say be very careful saying interfaces use inheritance to anyone who might be evaluating your programming skills for any reason.. moreover be very specific if you choose to use that wording. An extremely valid and useful test question would be "Show me examples of inheritance" looking for someone to incorrectly mention interfaces.
2d
comment If I implement an Interface, is it called an Inheritance?
With inheritance you would override a method. This is a key part, you change the way it works. With an interface you tend not to override (although default methods are an exception)--you tend to implement them. That said, what I really meant about the interview is if someone used the terminology inherits in relation to a class implementing an interface without mentioning these cases, they would certainly not understand the basic terminology and it's general usage in team communication.
2d
comment If I implement an Interface, is it called an Inheritance?
@EricLippert It does inherit the abstract method. (If the interface has an abstract method, the abstract class will too). If your class IMPLEMENTS the method it's no longer inherited, it's implemented like with all the non-abstract class definitions. that's why I said it's not really the same concept as the class inheritance that the Original question was referring to. Class Inheritance as per the original question would, for example, absolutely not apply to the concept of implementing a java 7 interface in a concrete (non-abstract) class.
Apr
28
comment If I implement an Interface, is it called an Inheritance?
@EricLippert As I said it's used correctly in that quote but really only because of Default Methods If you were to say a class inherited from an interface, you'd only be referring to default methods--not normal method definitions. You'd never use the term with java 7 unless you were to say it "inherited" the responsibility to implement an abstract method which is really not the "Class Inheritance" concept we're discussing. If you were to say that a class implementing an abstract interface inherited it, you'd be straight out wrong (and that's not what the quote in this answer says).
Apr
27
comment If I implement an Interface, is it called an Inheritance?
I'm not convinced that quote even applies to general inheritance as the word is usually used in coding EXCEPT that it points up the one case where implementing an interface is truly inheriting--default methods. I would certainly not say I was inheriting from an interface except when it comes to default methods and possibly abstract methods (Since you are truly inheriting the responsibility to implement these methods). For normal method definitions though I'd really look askance at someone who used the word inherit over implement--I'd probably even consider them plain old wrong in an interview.
Dec
3
comment Is there any “real” reason multiple inheritance is hated?
@gbjbaanb You are right, it is easy for someone who hasn't been burnt to mess up any feature--in fact it's almost a requirement for learning a feature that you mess it up in order to see how to best use it. I'm kind of curious because you seem to be saying that not having MI forces more DI/IoC which I haven't seen--I wouldn't think that the consultant code you got with all the crappy interfaces/DI would have been better also having a whole crazy many-to-many inheritance tree, but it could be my inexperience with MI. Do you have a page I could read on replacing DI/IoC with MI?
Jul
7
comment Do objects in OOP have to represent an entity?
I've been programming OO too long I guess--when I looked at MyRepository I immediately pictured a glass bowl on my dresser with a bunch of coins and crap in it. Reach in and grab out a penny, or a button....
Mar
19
comment Static functions vs classes
Utilities without business logic often don't have a good OO solution and the best you can do is static classes and fixed classes like collections. If you really must do a general purpose utility you might as well abandon oo like collections, math util and all the other utilities do. In this case, he probably is just using one collection for his business code so why implement a general solution?
Nov
15
comment Why would a company develop an atmosphere which discourage code comments?
It's all about how long it takes to comprehend the code afterwards. If having a comment makes it quicker for someone else to pick up the code and understand it, you should put them in there. The time taken to write and maintain them is completely irrelevant, most coding time (by far) is spent understanding with existing code and dealing with problems caused by a lack of understanding existing code. If you don't believe me, count the LOC in your project and divide by man hours to see how much actual code is typed an hour over the life of a project--it's not as much as you think.
Nov
15
comment Why would a company develop an atmosphere which discourage code comments?
On the other hand, I really love (not sarcastically) the requirement tracking comment referencing back into the requirement that inspired the code. I've used it a few times to find out why something was done a specific way to help me decide if a certain change was viable or not--also when the requirements change being able to track where in the code existing parts of the requirement were implemented is really a time saver.
Nov
14
comment How can Swift be so much faster than Objective-C in these comparisons?
This answer doesn't hold water at all and is horribly misleading. OO is not really slow, in fact the fastest systems you'll find around are going to be C++, Java and C# and the style (heavily OO or not) of programming will have very little to do with the resultant speeds unless you have really bad code.
Nov
14
comment How can Swift be so much faster than Objective-C in these comparisons?
@syrion I thought about the python thing too. I think the point is to avoid comparison with a fast language. Python is one of the faster scripting languages I've seen around, but last time I checked it was still 10x slower than Java and 20x slower than C for most stuff. If they were to stick either of those in there Swift wouldn't have looked quite as swift.
Oct
30
comment Use constructor or setter method?
I would say that if it needs to be set for your object to be valid, put it in every constructor... if it's optional (has a reasonable default) and you don't care about immutability, put it in a setter. It should be impossible to instantiate your object into an invalid state or after instantiation put it into an invalid state wherever possible.
Oct
7
comment OOP: Behavior + Data, but what about 'validation' behaviors?
If you go beyond trivial validations (like null checking or basic range checking) you are probably right, they aren't behaviors and don't belong in the class. Often validations can be attached to a class through external metadata (annotations and/or data files) and can therefore be more easily manipulated, adjusted and applied at different levels (UI and database, for instance). Only validations required to ensure that the class is a valid object should be coded directly into the class.
Sep
24
comment Is using `continue`, `break` in non-`switch` loops and `?:` bad practice?
Surprises are bad. If you check conditions at the beginning of a method and return, and the structure is clear and expected, it's fine. If you bury a return in the middle of a nested logic loop it will surprise someone someday, which is bad. I had my first boss tell me that ?: was "Bad" because nobody ever used or understood it and therefore it would take extra time to understand the code. If he was right about the assumption, then his conclusion was also correct. I hope he wasn't.
Jul
15
comment Is it a good idea to “#define me (*this)”?
As an alternative comment--I think the pattern of identifying members with this. is pretty bad. I really don't even like using m_, the reason is that it can be wrong. One refactor where you forget to change the name can cause a LOT more work than just letting your tools do their job. (I don't know about C++ IDEs, but in Java/Eclipse members, statics and locals can easily be differentiated at least 3 ways--by color/font, hovering and ctrl-clicking. Perhaps your team would be better served if you spent time looking into more appropriate tools?
Sep
17
comment Is a large increase in velocity realistic in a Scrum environment?
Honestly your manager should be sent to an agile/scrum refresher, he's missing the point so severely as to make me believe he's never even been given the chance to understand how agile works--what I mean is everything you said about his actions goes against agile practices, he should be given the oppourtinity to understand it from the ground-up.