New answers tagged

3

Why nested classes ? Bjarne Stroustrup explains in "The design and evolution of C++", the origin and rationale behind nested classes: original C++ in 1984 had a single name space (page 5 and 102). the use of nested classes was a compromise between the the concept of a class as a scope and the need of compatibility with C (page 102) it was further ...


5

Polymorphism with no shared interface will ONLY let you store objects in the same (strongly typed) container, not actually DO anything. You can't disptach method calls or anything like that. In your specific example, I think composition would be more appropriate, no? You already have an abstraction for a specific point in 2d space, so why woudn't you reuse ...


2

The two subclasses does not have any interface in common, so why you do you want to have them inherit from a common class in the first place? The Location class does not provide you any benefit as far as I can tell. To me it would seem to more logical to have the Line contain two Point's.


3

There is nothing wrong with inheritance, and in in your case it is clearly the simplest solution. The second solution introduces complexity for no benefit. "Composition over inheritance" is just a rule-of-thumb to avoid over-reliance in inheritance - it does not say you shouldn't use inheritance when it is appropriate. Furthermore, you are not even reducing ...


3

which seems highly coupled. It's not highly coupled. In fact, it's the minimum coupling state. The ClusteringEngine will always depend on the Graph, no matter what you do. Furthermore, either the CentralController or the Graph must depend on the ClusteringEngine, else there won't be any clustering in the system. And finally, one considers that if the ...


0

The standard way of resolving circular references (and removing coupling) in object oriented systems is dependency inversion. To do this, we'd take one of your concrete classes (most likely the ClusteringEngine, as it seems the most self-contained, but theoretically at least you could do this for your Graph instead), and declare an interface for it. All of ...


1

You have to have the same amount of code, regardless whether it all lives in a single large class or several smaller classes! An ORM can help you write this code, but if we're talking about organisation of higher level DB repository for your business objects, you don't have much choice. Its easy to create many classes to handle DB transactions between ...


3

To make it simple: Static state is bad because it is effectively global state since everyone has access to it. Wrapping it in a singleton doesn't change anything. In general it is good to avoid global state which is hard to test. Static functions that are pure functions or that only mutate their arguments are perfectly fine. If they don't do any ...


6

The notion that static methods are impossible to unit test is a myth that has proven difficult to kill. What makes a method hard to test in isolation is stuff like hidden dependencies and accessing static state. There is no difference whatsoever between a static method and an instance method, except for the fact that invocations of instance methods get a ...


0

This is a Java-specific design. For example in D, sort is an instance method on arrays, not a static method as in Java. But in Java arrays are special. They are defined as objects, but they are not instances of classes. The only instance methods they have are the ones inherited directly from Object. There are no Array-specific instance methods since there ...


2

Here is a good explaination on differentiating association, aggregation, and composition. But here's a thing. If you try to show everything your system is capable of (or every description of your system) on the same diagram, you're going to run out of relationships, or end up reusing the relationship kinds with widely different meaning on the same diagram. ...


1

Your first approach look good. Clan/character is a container relashionship and so the ideal approach would be the Clan has a list of members, and the character is unaware of Clan class. That means character's API must be designed so Clan can implement its services.


0

Yes and No. It Depends. Scenario 1: You are the sole developer on the project or its your personal project. Practices do not matter. What matters is that it works and its of good quality. Scenario 2: There are muliple people working on this project Yes it is a bad practice. Only required fields must be part of constructor parameters. Either use ...


4

Optional parameters is not a bad practice, definitely not, but sometimes the optional parameters may be optional solely because of what the class does. You arrived at a problem which is a result of a bad design. You are trying to figure out how to ignore certain properties of a model if you don't use them. The problem is, you are mixing responsibilities of ...


0

Having optional parameter constructors eliminates the need for multiple constructor overloads. In Java, there's an entire software pattern for this called the Builder Pattern, which essentially replaces multiple constructors with a fluent interface. It's an elaborate, overly complex and ultimately unsatisfying pattern; optional constructor parameters is a ...


1

Validation is a pretty tricky thing to handle but I've seen most frameworks handle it in a similar way. In the frameworks I've worked with, data validation works by annotating your model classes. This 'technique' of validation is good because it follows DRY or "Don't Repeat Yourself". The best form of suggestion is through example: .NET Data validation ...


2

To expand on what I was saying in the comments, this is a simple example in Ruby of how you can do what @user4205580 is asking without having to use getter methods. For those unfamiliar with Ruby values starting with @ are private instance variables. This is a quick and dirty example (writing it in a coffeeshop while waiting for my tea) and I don't claim it ...


3

I don't like using inheritance for this, because the API is going to be clunky. You will loose the nice functional chaining when you use Either if you wrap it in Task, because then, you will need to await it after every call. Instead I would opt in to either create EitherTask, that is Either which is asynchronous inside or even go step further and create ...


2

One possible option public class ActualApiResultWrapper : Either<IApiErrorEnum, IEnumerable<ActualApiResultDto>> { } Task<ActualApiResultWrapper> GetSeveral(); Then the next result, OtherApiResult... public class OtherApiResultWrapper : Either<IApiErrorEnum, IEnumerable<OtherApiResultDto>> { }


1

You can reduce verbosity by using exceptions, which is the idiomatic and established way of handling error conditions in C#. You are basically introducing a form of typed exceptions (like Java) or typed error codes on top of a language with unchecked exceptions. This is bound to be more verbose, and in particular you can't use try/catch constructs to handle ...


1

I'd go to simple inheritance, but maybe you can group some classes in subsets like visual studio does. For instance, you got Control as the parent class with the core properties and behavior for all controls: caption, location, etc.; in the other hand there's a class that inherits Control that acts as a parent for SaveFileDialog and OpenFileDialog, since ...


0

If I understood your question correctly, you're looking for abstract static. This is not possible in Java, but here are some workarounds: http://stackoverflow.com/questions/1916019/java-abstract-static-workaround . As an alternative, you could use other languages with allow this, for example Scala


3

Any public property like this becomes part of the type's public API. According to the open/closed principle, it shouldn't ever change, even if the underlying code does. By exposing Bar through a public property, you are therefore forcing IMyObj to become part of that public API too. In the future, if you then decide the obj should implement IMyNewObj instead,...


3

Your design / domain model is plain wrong, if you have to deal with instanceof. This is a clear usecase OOP was invented for, resp. Polymorphism. treating a bunch of different objects as a family of objects. There are two ways to solve your problem: 1) Define a common base for Indian Books and USBooks. This makes sense, when both are indeed Books. 2) ...


6

Your design of B is wrong when it leaks A. This clearly violates the Law of Demeter and results in Train Wreck Code. Your intention for composing an object is to extend its knowledge or behavior: Say you want to build a car, the car needs an engine. so it makes perfectly sense to equip the car with an engine. As a driver, you want to use the API (so to ...


0

I will focus on the foo1() part of the question. Person has a public foo1 method that can alter its state (it's a mutable object). ... What about a simpler example, if Person was immutable (there would be no foo1 method in this case)? I suppose your uncertainty about whether Person should be immutable reflects your uncertainty about whether ...


2

For class B, is the fact that it has a reference to a Person just an implementation detail, or is it part of the spec of class B that it should provide access to a Person object? That's the question, and the answer decides what interface class B should provide. Could it make sense to change from a reference to Person to a reference to some different class ...


3

What is class B doing. Remember that OO is about telling objects to do things for you. So (for example) if B is a PersonnelManager, it could have a collection of Person objects and work at a higher abstraction level (e.g. giveRaise(percentage) ). I wouldn't expect it to proxy those Person objects for you (which is what you're implying in some of the above) ...


8

Knowing that Person is mutable, we should ask if we want clients of B to modify that person by calling foo1. We may decide to rewrite Person' getters in B or return a clone of that Person object, so that Person in class B won't be modified. If you do not want clients to modify the returned object, another option is to return an interface type which ...


0

There's nothing wrong in your Helper class. I have to confese I use this sort of Utils,Helpers or Holders to make accesible certain resources/logic from different places. However an architect of my company tell me over and over that these classes often gather code that I don't know where to place at. He also dislikes because you could bring components from ...


2

It looks like you are hiding an external dependency to Active Directory using this static class. One problem here is that if you are trying to unit test the class that calls these methods, you cannot fake static calls. So you immediately inhibit the testability of your code. I would refactor this to an interface, something like ...


0

Consider the programming language you are using (C#) as a set of tools. There is no rulebook, no "should" or "should not". Look at the job are doing, and choose the best tool for the job. If you need a global-available collection of methods, the same for all threads, then static classes are a good tool. If you want to store data within the class (...


0

I might be missing something but to my mind the answer boils down to the methods and member variables. If these are all static, the class itself can (and should be) made static. If not, then it isn't a static class. N.B. there is nothing that forces the class to be static even if the methods and variables are all static.


1

One of the things suggested in Object-Oriented Programming is Bad (the title is to get your attention, and the contents is disputed but entertaining) is that *Handler, *Manager and *Doer classes in general are a code smell that indicate someone trying to force object orientation onto a problem that is better suited for a procedural implementation. In C# you ...


2

I think static classes are nice in many cases. I could just say "use them when it's useful" but that's not very helpful. My rule of thumb is (as always): Am I hiding any dependencies? If you feel like a "helper class" is useful (although beware of low cohesion) then by all means, go ahead. Just make sure your methods don't access global state though. Pure ...


1

A class should be static if it only exists as an abstract concept in your application. For example, say you're creating a clone of Twitter. You may have 2 types of tweets, user tweets and ads. They both share common behavior but are different. Thus, you want to use polymorphism and a factory to create one or another. Those 2 tweets classes should be ...


1

You can use the Facade pattern like you thought to treat your AppleJuice and OrangeJuice objects like Juice objects. It's pretty simple. Here's your Juice class: class Juice { Juice(AppleJuice aj) { this.Color = aj.Color; this.VitaminC = aj.VitaminC; } Juice(OrangeJuice oj) { this.Color = oj.Color; this....


0

There is no need for any specific pattern here. While you can't change the properties within the dynamically generated classes created from SOAP service endpoints, you can add behavior to the types, the generated classes being partial. This makes it possible to create a method which converts AppleJuice or OrangeJuice to Juice: // Make sure the namespace ...


6

FileHandler should implement FileHandlerInterface. Abstract methods common to all children such as handle() should be hoisted to FileHandlerInterface if public, FileHandler if not. The purpose of abstract classes and interfaces is to define the contract for concrete classes and allow polymorphism. If I am handed FileHandlerInterface I should be able to do ...



Top 50 recent answers are included