Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm learning about Design by Contract and I've stumbled upon this statement:
Subclasses in an inheritance hierarchy are allowed to weaken
preconditions (but not strengthen them) and strengthen postconditions
and invariants (but not weaken them).
I'm not sure I fully grasp this. From what I've gathered, the preconditions of a method are the parameters passed into the function, whereas the postcondition is, for example, a guaranteed return type or some sort of assertion on the return type of a method.
Why exactly are subclasses allowed to weaken preconditions but must strengthen postconditions? Are these simply definitions in regards to the Liskov Substituation principle or is there some underlying logic behind this?
The preconditions are not the parameters, preconditions are expectations about parameters. For example, a precondition might be that param1 is never a null reference, while param2 is allowed to be null. param3 might be an IEnumerable, but perhaps a precondition requires at least one item is returned from that enumerable.
Its ok to weaken preconditions, because a particular implementation won't break others; that is, it doesn't break other sub-classes if one of them says an empty enumerable is ok.
Likewise, post conditions are rules about the return value. One common and useful post condition is that a null reference can never be returned. A method with such a post condition means callers never need to worry about handling a null option. Weakening a post condition is not allowed because all callers are never expecting null, and thus may break if they suddenly get null from an instance.
These rules are basically a restatement of the LSP, but Design by Contract is meant to make you think about the contract a method should have up front, as it can sometimes be an afterthought, if its a thought at all, when creating methods.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
In his book "Clean Code", Robert Martin states that the ideal number of function arguments is zero. Most people will agree that too many function arguments cause lots of issues. But as far as I can see, a function with zero arguments belongs to at least one of these categories:
The function is trivial and always returns the same value.
The function lacks referential transparency, its return value depends on external mutable state.
The purpose of the function are its side effects.
Now functions of type (1) are not really useful while (2) and (3) should be avoided for well-known reasons.
I am aware that the book I mentioned is about OOP, so functions typically belong to an object and get an object reference passed as an implicit argument. But still, accessing object attributes either means (2) or (3).
So what am I missing?
If you answer this question, please don't just communicate your opinion but provide reasonable arguments or specific examples. Otherwise it will probably get closed.
So what am I missing?
The key word in Martin's statement is "ideal". If you continue reading, he writes in depth about functions with one, two, and three arguments, but only mentions niladic functions in one context - testing. He claims that they are trivial to test, presumably because there is only one possible outcome, and it's either right or wrong.
So this is an ideal, and the principle to take from it is the fewer arguments, the better. In reality, obviously, this ideal is rarely achieved. The purpose of a function is usually to take input, whether directly, or indirectly through the object or system state (note that I would call those "arguments" as well to be consistent with Martin's analysis), and provide an output. When you have multiple arguments, the number of test cases increase exponentially, the maintenance is more difficult, etc.
So you are not "missing" anything, so long as you recognize that this is an ideal goal and not something that you should take as an absolute.
Some examples of "pure" niladic functions in C#:
DateTime.MinValue
String.Empty
Niladic functions in C# that return object or system state:
DateTime.Now()
object.GetHashCode()
String.Length
The object's attributes will essentially serve as the arguments to the function. In this way, you can directly manipulate the object you are working with, rather than passing and returning values which you then attribute to the object after performing some behaviour contained in the function.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Why did kotlin drop the new keyword ?
It makes it harder to see the difference between a function call and an object allocation.
The Kotlin Coding Conventions clearly state that:
use of camelCase for names (and avoid underscore in names)
types start with upper case
methods and properties start with lower case
If you follow the above and treat constructor as regular function that can be called i.e. val invoice = Invoice() the new keyword becomes redundant.
Once you accommodate yourself with the convention it's clear what a code is doing.
In fact even in Java code you'll have many implicit allocations that happen just beneath a method call like Collections.singleton(o) or Guava's Lists.newArrayList() so I don't think your argument about allocation visibility being better with the new keyword is fully valid.
(IMO) It was done because there is NO real difference between functions and object construction, i.e. nothing prevents a function to allocate an object (and they often do).
A good example is factory functions. These functions create new objects, but they are in no way class constructors.
AFAIK, the new keyword was created because of a negative experience with C\C++, where functions, returning new objects, have to be specially marked (by name conventions) in order not to forget to (manually) free the memory. In a auto-memory-managing language like Java\Kotlin it is not a concern.
Several other languages have no new keyword (Python, Scala, maybe Ceylon) and people who have switched to those languages never seem to miss it. I know I dont.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I couldn't well understand why the go developers settled on a syntax like func (t Type) MethodName() for methods. I couldn't digest this fact especially after reading this and considering the fact that go is minimalistic. Wouldn't a simpler syntax like func Type.MethodName() or func Type::MethodName() been sufficient with the object accessed using an implicit argument like this or self. Or am I missing any advantages offered by the current syntax?
The goal of that particular syntax is very particular to the language Go and cannot easily be mapped to other language syntax:
This syntax allows you to define a method set
A type may have a method set associated with it. The method set of an interface type is its interface.
The method set of any other type T consists of all methods declared with receiver type T.
The method set of the corresponding pointer type *T is the set of all methods declared with receiver *T or T (that is, it also contains the method set of T).
Further rules apply to structs containing anonymous fields, as described in the section on struct types. Any other type has an empty method set. In a method set, each method must have a unique non-blank method name.
The method set of a type determines the interfaces that the type implements and the methods that can be called using a receiver of that type.
It isn't so much an "advantage" than it is a Go feature allowing to easily extend a type with new methods.
See for instance "What are some examples of Go interfaces?".
twotwotwo adds in the comments:
There are two particular things that an explicit receiver declaration lets you do:
decide that some methods will get pointer receivers and others (e.g., non-mutating methods on small structs) don't, and
choose a context-specific name instead of 'self' or 'this' (e.g., you might have a func (srv *Server)...).
Context-specific names are considered good style in Go
See Wiki CodeReviewComments
The name of a method's receiver should be a reflection of its identity; often a one or two letter abbreviation of its type suffices (such as "c" or "cl" for "Client").
Don't use generic names such as "me", "this" or "self", identifiers typical of object-oriented languages that place more emphasis on methods as opposed to functions.
The name need not be as descriptive as a that of a method argument, as its role is obvious and serves no documentary purpose. It can be very short as it will appear on almost every line of every method of the type; familiarity admits brevity.
Be consistent, too: if you call the receiver "c" in one method, don't call it "cl" in another.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
This is a probably a very basic question, but it's one I'm actually running into as I'm learning more about Actionscript 3 in particular. However, my first question is very general: When is appropriate to put functionality in a new class rather than a new function in the same class? According to this Java tutorial, which focuses on basic object-oriented principles, a class is supposed to be a "blueprint of an object". I always understood this to mean that any functionality or behavior that the object would use should be contained within the class. However, according to the single responsibility principle, each class should have only one reason to change. For example, you should have one class to compile a report and one class to print it rather than a single Report class.
Can you guys help me understand the pros and cons to creating a new class? What are the costs to splitting an object into multiple classes? Are there compile-time or performance costs for keeping related functionality in the same class, or for splitting it into two? Are there perhaps times that you would want to split things out, while you might want to keep them together other times?
As far as I remember, there isn't a big difference between having 1 class which can do everything or several classes which can do the same.
It's about readability and how you can extend the code. It's also just about clean code and coupling.
If you have a class called "Printer" you don't want to have "WaterCoolerSound()" in it. Of course the more objects you have the higher the chance is that you can run out of memory. But I am not entirely sure whether one object with all functionality or several classes with the same functionality spread out, takes more memory.
In fact, you could say that if you JUST need a little bag to hold on to some data and not be able to dance like a bear at the same time, it would make sense to have two separate classes.
It's advisable not to think about the performance before you have the code. From the maintainability and understandability viewpoint, of course, smaller classes, with smaller methods are superior. (see The Single Responsibility Principle again :)
Don't get so confused about making classes for just a function. A class should have only related functions.If the functions are of different kinds which will do totally different functionalities and use totally different kind of variables then only u should make a separate class.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Consider that I have a complex class structure where many elements inherit from other elements. I may have a method GetStuff(string stuffName, int count) defined in an interface, which is inherited by other interface, which is then implemented abstractly by an abstract class, which is then implement explicit in a concrete class etc. etc...
How should I handle inherited members such as GetStuff() when documenting my code with XML comments which will be used with a tool such as Doxygen or Sandcastle? It seems wrong to just copy and paste the same description at each level. Should I be considering a different audience at the interface level vs the concrete class level? For example the documentation for GetStuff() at the interface may consider people implementing the interface, whereas the documentation at the concrete level may instead consider people who will be using the class?
Document the interface method according to its code contract. Do not comment on its implementation, only on its semantic purpose, i.e. what it’s supposed to do, not how. The audience for this documentation is both your implementors and your users: the method will both be implemented as well as called.
Document the abstract method simply by saying that it implements the interface method and linking to it. There is nothing extra to be said about it, and duplicating the comment violates the DRY (Don’t Repeat Yourself) principle: you would have to remember to make any change to it in both places. (Of course, in the case of an abstract method that doesn’t implement an interface method, document it in the same way that you would document an interface method.)
Document the concrete implementation by saying that it implements the interface method and/or that it overrides the abstract member. Optionally add information about its implementation if it is relevant to the caller — for example, its performance characteristics, or situations in which it might throw, etc.
remark
on part of post
by Eric Anastas
It seems wrong to just copy and paste
the same description at each level.
I can imagine it being wrong to just copy. It is however possible to let doxygen copy it for you and then change what you would like to change for that implementation/scope.
For more information, you can look at the description for #copydoc.