As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have a class that I writes iCal events, and it contains nested classes that are public. The class are bascially complex types for components in the iCal such as events, alarms, etc, and it made sense to make them public nested classes that were used by the rest of the program.
I have read that having public nested classes is a sign of bad programming is. Why is it bad and when is it appropriate nested classes?
This is all IMHO but comes from about 15 years of analysing other people's creations:
It is appropriate if the nested classes are private and are not exposed by the public interface of the containing class.
For example a linked list class would have a linked list node class nested inside it which is specific to the implementation internals but will not be exposed to the consumer of the linked list class.
Otherwise, I would not bother as it just adds unnecessary complexity.
For the sake of your example, I'd change all your classes to normal ones if they are exposed by the iCal event class.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
One of the disadvantages of inheritance is that the superclass and its subclasses are very tightly coupled. A lot of resources (e.g. SO) say to compensate for this by being 'cautious' when writing a class that might be subclassed.
Are there any guidelines about what precautions you should take, or testing processes to go through to make sure your base class is safe? Or do you just have to try to predict all potential subclass behavior?
Do as little as required in the parent classes. If you must do more complex operations then separate them into logical pieces, putting each piece in a different method so that children can override them as appropriate.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Would I be correct in thinking that an interface has 3 main benefits.
A blueprint to what must be created (I have also heard others refer to it as a contract).
Polymorphism.
Unlike inheritance (which IMO has many similarities) you can have many interfaces
Are there any other plus or minus points and does anyone not agree with my 3 points?
The "blueprint" metaphor works better for classes than for interfaces, but the "contract" metaphor is pretty accurate. An interface specifies what other classes can expect in terms of public methods, without saying anything about the underlying implementation. Where inheritance between classes tends to consist of is-a relationships, interfaces can be thought of as works-as-a relationships, though I don't think the latter term is in common use.
I would add that the use of interfaces goes some way to creating self-documenting code. For example, the interfaces that your class implements describes the functionality the class supports. So, you end up with code that looks like:
if (someClass is ISearchable)
{
someClass.Search();
}
Two objects with the same Interface do not need to be otherwise related.
So you could have
- Flower
- Truck
- Dinosaur
all having the same interface
- IColor
even though they are completely different objects.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The use of design patterns in programming is wide spread across many programming languages. A number of examples are the factory, or singleton design pattern. Many of these patterns use object orientation to create abstraction and encapsulation in the code, they aim at make code re-usable and structured. Many of these design patterns could also be used in R, maybe by using the proto library, or standard R object orientation?
My questions are:
What base code (S3, S4) / packages (proto, R.oo) can I use to reproduce design patterns as for example mentioned in the book by Gamma et al?
Are there examples of design patterns implemented in R, both in base R, or in packages?
Some examples of design patterns:
The system.time() function seems to behave much like a decorator pattern. However, almost exclusively decorators are mentioned in the context of object oriented programming. But still, it has the feel of a decorator, it extends (or decorates) an existing piece of code (in OOP always an object) with additional functionality without any need to change the piece of code. Here system.time() is shown in action:
system.time(bla <- Sys.sleep(1000))
#jverzani posted an example of singleton pattern on github.
An example of a Strategy Design Pattern is the apply family of functions. The functionality of looping over the given object is generic, the function that is applied (the strategy) is chosen when the user supplies the function.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Because it is not really* possible to create abstract classes in objective-c I was wondering if anyone could tell me why the creators of objective-c didn't add this feature to the language.
*of course there are a few workarounds to create a -kind of- abstract classes but thats not what i mean.
If you mean why you can't declare a class abstract rather than just implement it as an abstract class, I suppose it's because it doesn't interact so well with Objective-C's extremely dynamic, types-optional, Smalltalky message-passing style (Smalltalk doesn't have built-in support for declaring them either). For example:
You might not know what class you're sending alloc or init to, so it would be a pretty weak guarantee
Subclasses might still need to pass alloc and init up the class hierarchy, so we'd need to allow that, making it an even weaker guarantee
Categories modify classes at runtime, making it the abstract contract weaker still
In the end, you'd wind up with a keyword that just did roughly the same thing we do now to implement abstract classes (i.e. maybe override init to bail if the receiver isn't a subclass).
Type modifiers that just specify a contract become more useful the more you rely on the static type system — but Objective-C was designed not to rely on the type system all that much, so putting the contract in the type system is less useful than in some other languages.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I think it is not necessary for me to explain what is the good thing about OOP. But I would like to know discuss is the static method violate the OOP design? or a more OOP way to do is making a singleton to do such static method?
I would like to know what harm is done by static methods and what purpose is served by adhering to object oriented purity.
This question and its answer makes as much sense as any other argument about object-oriented purity and where a particular language falls on the continuum.
C# and Java both support the notion of methods and attributes associated with classes rather than a specific instance.
The benefit or harm of singletons in design have been explored in detail elsewhere.
Static methods wouldn't exist if they were considered to be bad practice in the OOP paradigm. Static methods are absolutely necessary at times, if you know how to use them. If you have a method that does not make use of, or change, any member of a class object, then it is static by nature.