Tag Info

Hot answers tagged

74

It is... Not great. I've worked with code that did this clever trick and it led to confusion. After all, you would expect to be able to just assign the BigObject into a SmallObject variable if the objects are related enough to cast them. It doesn't work though - you get compiler errors if you try since as far as the type system is concerned, they're ...


66

The simplest way to avoid setters is to hand the values to the constructor method when you new up the object. This is also the usual pattern when you want to make an object immutable. That said, things are not always that clear in the real world. It is true that methods should be about behavior. However, some objects, like Customer, exist primarily to ...


56

It is perfectly fine to have an object which exposes data rather than behavior. We just call it a "data object". The pattern exists under names like Data Transfer Object or Value Object. If the purpose of the object is to hold data, then getters and setters are valid to access the data. So why would someone say "getter and setter methods are evil"? You will ...


54

The main reason is for performance. The "unlimited arguments" syntactical sugar is actually an array of Strings. If you are only passing one string, why create an array with only one string? Especially if ~90% of the invocations of this method will be with 3 or fewer arguments, there is no need for the heavier weight array object. It's a little lighter in ...


50

A C program is a collection of functions. A function is a collection of statements. You can encapsulate data with a struct. That's it. How did you write a class? That's pretty much how you write a .C file. Granted, you don't get things like method polymorphism and inheritance, but you can simulate those with different function names and composition ...


44

Congratulations! You rediscovered the well known fact that object orientation can be done without specific programming language support. It is basically the same way objects are introduced in Scheme in this classic text book. Note that Scheme does not have a class keyword or some kind of equivalent, and objects can be created without having even classes. ...


43

I've been wrestling with a problem in a Java project about circular references. Java's garbage collector doesn't rely on reference counting techniques. Circular references do not cause any kind of problem in Java. Time spent eliminating perfectly natural circular references in Java is time wasted. I coded this up [...] but the problem is that it's ...


23

"Programming to an interface" does not mean "use the most abstracted version possible". In that case everyone would just use Object. What it means is that you should define your program against the lowest possible abstraction without losing functionality. If you require a TreeMap then you will need to define a contract using a TreeMap.


22

The Principle of least knowledge or the Law of Demeter is a warning against entangling your class with details of other classes that traverse layer after layer. It tells you that it is better to talk only with your "friends" and not with "friends of friends". Imagine you've been asked to weld a shield onto a statue of a knight in shiny plate armor. You ...


19

Granted, circular dependencies are a questionable practice from a design point of view, but they are not prohibited, and from a purely technical point of view they are not even necessarily problematic, as you seem to regard them to be: they are perfectly legal in most scenarios, they are inevitable in some situations, and on some rare occasions they can even ...


15

The reason you have two different methods is that they do two different things. The .equals method returns a boolean value indicating whether the object on which you call the method is equal to the object passed in as a parameter (for some definition of "is equal to" that is consistent with the nature of the object being compared). The .compareTo method ...


14

Read SICP and learn Scheme, and the practical idea of abstract data types. Then coding in C is easy (since with SICP, a bit of C, and a bit of PHP, Ruby, etc... your thinking would be widen enough, and you would understand that object oriented programming might not be the best style in all cases, but only for some kind of programs). Be careful about C ...


11

Is functional design better than object-oriented design? It depends. Is MVVM better than MVC? It depends. Amos & Andy or Martin and Lewis? It depends. What does it depend on? The choices you make depend on how well each technique or technology meets your software's functional and non-functional requirements, while adequately satisfying your ...


10

While I can see why you would need to have a SmallObject, I would approach the problem differently. My approach to this type of issue is to use a Facade. Its sole purpose is to encapsulate BigObject and only make available specific members. In this way, it is a new interface on the same instance, and not a copy. Of course you may also want to perform a ...


10

Game theory treats games as a list of previous moves (value types including who played them) and a function ValidMoves(previousMoves) I would try and follow this pattern for the non UI part of the game and treat things like board setup as moves. the UI can then be standard OO stuff with one way ref to the logic Update to condense comments Consider ...


9

The principle you are talking of (better known as Law of Demeter) for functions can be applied by adding another helper method to your streamer class like { frame = encoder->WaitEncoderFrame() DoOrGetSomethingForFrame(frame); ... } void DoOrGetSomethingForFrame(Frame *frame) { frame->DoOrGetSomething(); } Now, each ...


8

To transform the Customer-class from a data object we can ask ourselves the following questions about the data fields: How do we want to use {data field}? Where is {data field} used? Can and should the use of {data field} be moved to the class? E.g.: What is the purpose of Customer.Name? Possible answers, display the name in a login web page, use the ...


8

It appears from the comments and edits that your concern is more about duplicating code in multiple implementation classes. That has nothing to do with how many interfaces are implemented. Composite Pattern with Delegation If the implementations of each interface is generic then they should be classes that are delegated to using the Composite Pattern. The ...


8

The standard way of removing a circular reference between two classes in object oriented programming is to introduce an interface that can then be implemented by one of them. So in your case, you could have RuleBook referring to State which then refers to an InitialPositionProvider (which would be an interface implemented by RuleBook). This also makes ...


7

Can anyone give a good example of when implementing explicit operator between unrelated types makes sense and how to do it? I will argue that it never makes sense to overload the explicit conversion operator. That operator has a well defined behavior, and using it for a different behavior will always fall into the realm of "clever". Just use a function. ...


7

I would agree that the first definition satisfies the three points your teacher made. I do not think we need the class keyword for anything. Under the covers, what else is an object but a data structure with with different types of data and functions to work with the data? Of course, the functions are data as well.. I would go even further and say that ...


7

I believe the circular references and the god object in your case could be easily removed by separating the control of the game flow from the state and rule models of the game. By doing that you would probably gain a lot of flexibility and get rid of some needless complexity. I think you should have a controller ("a game master" if you wish) that controls ...


7

On the other hand, these principles make using static methods and factories necessary. Since when? I think static methods should be out of any good object-oriented design, since they pollute the code with imperative programming practices that don't have anything to do with pure OOP. You could, but you'd be wrong. Modern OO design often includes ...


6

There is a very strong convention that casts on mutable reference types are identity-preserving. Because the system generally does not allow user-defined casting operators in situations where an object of the source type could be assigned to a reference of the destination type, there are only a few cases where user-defined casting operations would be ...


6

However, I lose the benefits of functional style. If you always lose the benefits of functional style code when converting bundles of functions to objects, you're doing it wrong (or have an usual idea of what the benefits of functional style are). After all, instance functions are the same thing as static functions but simply have an additional ...


6

TL;DR Modeling for behavior is good. Modeling for good(!) abstractions is better. Sometimes data objects are required. Behavior and Abstraction There are several reasons to avoid getters and setters. One is, as you noted, to avoid modeling data. This is actually the minor reason. The bigger reason is to provide abstraction. In your example with the ...


6

Trying to expand on Kasper's answer, it's easiest to rant against and eliminate setters. In a rather vague, handwaving (and hopefully humorous) argument: When would Customer.Name ever change? Seldom. Maybe they got married. Or went into witness protection. But in that case you'd also want to check on and possibly change their residence, next of kin, ...


5

This confusion would occur in situations where there are conflicting understandings of equals. compareTo is 'easy' in that it asks a simple question 'which one is bigger?' If you were given a bunch of Things, how do you sort them? equals on the other hand wants to ask 'are these the same thing?' BigDecimal in Java is one such place where there are ...


5

Of course you can! The Self programming language is a dynamic prototype-based object oriented language in which everything is an object and there is no sense of classes or whatsoever. It's focused in the idea of prototypical objects and the idea of cloning them instead of having classes as templates of how to create objects. You should check ...



Only top voted, non community-wiki answers of a minimum length are eligible