Tag Info

New answers tagged

2

If you want an OCP-conforming way of handling an unspecified list of exceptions, then you can consider "chain of responsibility". But it's not clear from your question whether your code is specified to handle "an arbitrary set of exceptions, each in a different way, all of which will be specified in future and is subject to change", or whether the fixed list ...


1

I think Phil's answer should get accepted in the end because it contains the best info. But to just answer your Is there another way for doing this? question specifically: here is another way which seperates the exception handling part pretty well, though it depends on the exact situation how usefull it is template< class Fun > void TryCatch( Fun f ) ...


3

If you just want to log each exception - in some way depending on its specific type, you can split that concern out into a dedicated exception logger. First, you need a base type - let's assume you just subclass std::exception. Now, your main code can just be: try { // something that throws } catch (const std::exception& e) { ...


5

That depends on how you plan to recover from these exception, meaning what code is executed in the catch statements. If it's the same for all 3 exceptions, you could create a superclass for them and catch the superclass. If your method has to throw a new exception, just make it extend the superclass and it would still be caught by the caller and would not ...


-2

Patterns are common solutions to common problems. We are always following some patterns, the patterns by GoF address the most recurring ones. That, to have a shared understanding and shared approach known to software engineers. That said, my answer is no, but yes you are always following some pattern of your own. As the GoF rightly puts it- One ...


1

Collection types using interface instead of abstract class is a mistake. Indeed, such a huge mistake that the Java SE 8 language has had bizarre extensions grafted onto it so that interfaces could have implementation methods. So why the mistake? Ideally you want to define an interface (general definition of "interface", not the Java keyword) without ...


2

You're quoting your reference (Joshua Bloch, Effective Java) out of context. It isn't stating one particular purpose for interfaces and that they should only be used for that purpose. It's enumerating a (non-exhaustive) list of possible applications for them, all of which fall under the general heading "Prefer interfaces to abstract classes". How you get ...


8

Having these abstractions implemented as interfaces allows more flexibility. Interfaces allow programmers to use multiple inheritance of type in Java. This way you can treat any class as an instance of the interface regardless of its inheritance hierarchy. You can implement any number of interfaces in a single class but you can only have a single ...


4

So an interface implies a contract - You guarantee that any class implementing the interface contains these methods, with these parameter types, and returns this type. This is great when you know there are many different ways of doing the same thing (maintaining lists, sorting, etc) An abstract class, on the other hand, says that there are different ways of ...


3

Get rid of the getters/setters too, and you're fine! This is a highly controversial topic amongst Java programmers. Anyways, there's two situtation where i use public variables instead (!) of getters/setters: public final To me this signals "I'm immutable" much better than just a getter. Most IDEs will indicate the final modifier with a 'F' during ...


0

One commonly (albeit not universally) accepted principle of object design is that an object should be immutable unless this makes the design substantially more complex. Immutable objects are easier to reason about, can be used in a multithreaded environment more easily and are generally less prone to bugs. From the code you have shown us, there is no reason ...


2

To provide an alternative to letting the value be set by the subclass you can instead have them provide a doRun that returns true/false to signify success and the run assigns that result to self._ok, this also allows more checks like catching exceptions or ensuring it only runs once: class Check: @abstractmethod def doRun() """ You have to define ...


2

Why wouldn't it be okay to require subclasses to do work? The parent is abstract, after all. The more important question is: why is run() supposed to signal success via an out-of-bound mechanism (setting a global variable) rather than a return value? There are sometimes reasons for doing this (e.g. because it's an extremely entrenched convention, like errno ...


4

Arrays aren't the only option for implementing autorelease pools. Anything suitable for a set implementation should be suitable for an autorelease pool, including (single- or double-linked) lists, trees, and hash tables. When picking which data structure to use, consider the timing of the various operations and match that to usage. For an autorelease pool, ...


1

The usual way is to retain for the calling code, To make it consistent you should do it for all objects that you return. //popFromQueue will remove from the queue and pass the buck to the calling code Foo* pop(FooQueue* q){ Node* foo = q.head; q->head = foo->next; foo->next=null;//make sure new head isn't released; could have also ...


1

Problems of this kind can be solved by providing a graphical version of the model (for example, in an UML CASE tool), which shows just the domain attributes, together with a code generator which generates the implementation of class interfaces, database scripts etc. The code generator will provide you silently with any of your "technical attributes", so at ...


1

We need it so we can e.g. find the books in faster way, since databases find by number faster then by string. Surrogate keys should primarily be added because they provide you a uniform way for building your primary keys, not because of any hypothetical performance issues. They will help you to avoid having business data like an Isbn distributed over ...


0

All the actual code you've shown doesn't do anything, it just sets up properties, so any answer will involve some guessing. It's not clear to me why having an unconstrained generic type on transition makes sense. Could it take a string type? My guess is that what you are trying to do is let the "extension" class know that the transition has occurred, and ...


0

I'm not familiar with the particular automata classes you mention, but whenever you have a one-off class that you'd like to handle in similarly to the other classes, then the Facade pattern is pretty useful. I'm over-simplifying, but the facade pattern is little more than a wrapper around the class in order to either or both of: reduce the complexity of ...


1

A wrapper is the right way to go here -- you really want the UI part of the UI layer to just reflect what is given and not be responsible for more than very technical bits of filtering content. I would run with the first option you are looking at and create a specific subclass for the UI layer to handle this task. The real cost from a writing code ...


0

There's also a Key-Value approach. Each type of product would have its own set of properties stored as individual key-value items in your database. So you would not have a shippingWeight property as part of a class. Rather, you'd request the 'shippingWeight' value as needed. Some ecommerce systems use this (Magento, I believe) for it's flexibility. The ...


0

There are several ways to approach this depending on what tradeoffs you want to make. One such approach would be to have a set of classes that accept a Product and provide different information from it. For example, a ShippingWeightViewAdapter which knows how to get the shipping weight from any Product or subclass, providing an aggregate value where ...


0

I would expect the bundle class to have 2 lists, I am assuming that the downloadable and physical products are in 2 different tables with 2 different sets of keys. So you can have you 2 separate lists. I would have a method in the product bundle that returns an object with total digital items, total digital size, total physical items and total physical ...


1

You said it yourself, there is some kind of context, in which every book is handled. This OrganizationContext might be a class. And every time you load or save a book, this class knows about it and can do it's own logic on those field. Also, to make the coupling looser you could have HasOrganizationContext interface to represent those IDs and allow for ...


5

Introductory texts about object oriented design always focus on these "natural" objects that are modeled by code. This, I think, is usually a mistake, and results in a lot of confusion when trying to implement an architecture, since you're trying to model the wrong thing. An object oriented architecture deals with types and classes in your solution's ...


0

Steal an idea from gui libraries: every drawable object implements Drawable which has one method: draw(graphics_context) This approach has been in almost every gui hierarchy I can recall, including canvases.


0

I try to avoid inner classes in general unless they are simple lambdas, listeners with one or two lines of code, etc. Once an inner class has a life of its own and performs more complex functions, I refactor it into its own top-level class. I will use either a standard interface or create my own for the class that used to enclose it (A). I then construct ...



Top 50 recent answers are included