Tag Info

New answers tagged

0

I would usually keep the collaborator objects as pointer members in the object that will use them. I would also usually have them implemented using an abstract class and pass the pointers as parameters to Shop's constructor rather than having Shop building them itself. This decouples Shop from the detail of how products are loaded, and means I can change to ...


1

The subject you're asking about is called modeling, and it's as much an art as a science. But the first step of OO modeling is to forget about the mechanics of the language and think about the properties of the things you're modeling. A class named ProductsLoader is suspect to begin with. Names like that indicate that you're thinking procedurally instead ...


1

At a general level, the method needs to go with the object that has responsibility for the function. Based upon your domain, the Student has the responsibility to provide a GetSchedule() method, as the Student owns the courses that it is taking. And while the Parent may have a requirement to be able to see the Students schedule, the responsibility to ...


1

As said in the comments on the OP, I don't think an interfacing class class makes sense in this instance since there is a direct relationship between Students and Parents. Think about the relationships of the concepts outside of the system. Does every student have a schedule? By my limited knowledge I'd say it sounds like it. It also sounds like you'll ...


0

Use a wrapping class when the interface is private, i.e. the user can't create their own new derived classes. This is usually a pretty questionable design. Otherwise, make the interface and derived classes public. Don't use a factory method unless it has some language-required advantage, e.g. generic type deduction, which you can see in Tuple.Create.


2

You don't need a class for that, but maybe you want one. At the database design level, I like to avoid linking tables and think of those tables as first class entities instead. So if we have student and class tables for example, instead of creating a student_class linking table to satisfy that many-to-many relationship, we could call it something like ...


1

That is correct. You simply have a property of groups (which makes more sense to me than students, but that's a matter of opinion) that is an enumerable collection of students that belong to the group.


0

This API is less about hiding implementation details and more about deferring to the programmer for the interesting parts of the action. listFiles() knows how to iterate over the files in a directory and return a subset of the them. Thread knows how to run code in parallel to the code that is currently running. However, from the application's perspective, ...


3

Yes, it is good practice. It looks a bit boilerplate and weird, because Java 7 and below does not support functional programming very well. The difference to just a regular expression is, that a regular expression limits you in your options to filter for files. E.g. lets say you want to filter files not by their name only but [just/additionally] by their ...


0

The IFooStream just connects both types since both got a length and a position,... But actually the IByteStream and the IFloatStream already exist as an essential part of the audio lib. It sounds like the only other types in the lib that depend on IFooStream and IReadableFooStream<T> are IByteStream and IFloatStream. Those last two sound like ...


9

In a word Simplicity. When you decouple too much, you get the hello world from hell. void main(String[] args) { TextOutputFactory outputFactory = new TextOutputFactory(); OutputStream stream = outputFactory.CreateStdOutputStream(); Encoding encoding = new EncodingFactory.CreateUtf8Encoding(); stream.Encoding = encoding; SystemConstant ...


12

what if; what if; what if? YAGNI Seriously. If someone wants to use different implementations of File or Math or Console then they can go through the pain of abstracting that away. Have you seen/used Java?!? The Java standard libraries are a fine example of what happens when you abstract things for the sake of abstraction. Do I really need to go ...


0

Is it misleading to label classes or methods as a particular design pattern (Strategy, Mediator, etc.) if they only loosely fit that definition? No, it is not misleading; rather it should not be. Too Loose Obstructs Understanding. If we say a global read only variable is a singleton, that's not "loose" that's just wrong. Besides, strictly speaking a ...


2

Labeling a pattern as [X] in Javadoc is really not so useful. Too many patterns are mis-applied because developers don't validate the patterns' assumptions (which are also not documented). Your Singleton example is trivial, as Singleton is more of an idiom than a design pattern. There's at least one project (http://www.jpatterns.org/) that uses Javadoc ...


2

I definitely must have the IByteStream and the IFloatStream interface. Without a compelling reason, I definitely say you don't. Do you make a ByteList or a FloatList? No, you leave List be and let people parameterize it. This sort of aliasing can occasionally be useful, but more often it is a code smell that your interface/class is too abstract (or ...


5

Is it misleading to label classes or methods as a particular design pattern (Strategy, Mediator, etc.) if they only loosely fit that definition? It depends. If you have a singleton and it does not prevent instantiation, then it would be misleading to label it a singleton, since it's not a singleton. It's a global variable. Doing otherwise leads your ...


0

For flexibility, DO NOT do initialisation in constructors. For simplicity, i.e. if you can afford it and are sure it will not cause you headaches later, DO initialisation in constructors (RAII). Then you can make the usual safe RAII assumptions about (monolithic?) deallocations. All programming relies on correct ordering of events. There is nothing ...


6

Yes, what you're referring to is method chaining. You would add these methods to your class, and the return for each method would be the class itself. class Query { public string serverName { get; set; } public string tSQL { get; set; } public Query(string ServerName, string TSQL) { serverName = ServerName; tSQL = TSQL; ...


4

The example is kinda messed up, and looks to me like it just hasn't been thought through. Currencies aren't like scientific measurements, you shouldn't implicitly convert between them on demand. The value of a currency will change on the day. You should really only convert between currencies with the end-users explicit permission, certainly not implicitly ...


1

How will the Currency method public Money convertToYourCurrency(Money money); know what's the argument's currency? Is it going to use a getter? One could say that, loosely speaking, the fix is a very simplistic visitor pattern. The Currency object is the visitor that, by the pattern's definition, performs operations on the Money objects. Of necessity ...


1

I think his first example is a little contrived. If you've really gotten yourself into that pickle, you probably didn't think hard enough about the problem in the first place. The "largerThan" and "addTo" methods make sense because rather than carry two values & imposing some semantics outside the class on the separate values, he's defining the ...


1

Now that you've explained more fully, it seems that there really is no subclass-specific logic. In that case, inheritance is not the right choice. If there really are only minor ways in which other parts of the code treat products, putting code into product classes would be wrong - a violation of separation of concerns which would encumber the product ...


2

Your question shows some misconceptions, I guess: if the alternative to passing an object as parameter is to create a new instance directly in the constructor PassTheObjectHere, then you are obviously not using any values/state of the previously created obj within PassTheObjectHere. If that is the case, it is pretty useless to pass obj as a parameter ...


3

It's a bit more complicated than that. Firstly, understand the tradeoffs. If you are going to pass a copy of the object (essentially "pass by value" semantics) rather than a reference to the original object, you are going to take a performance hit. Whether that hit is justified or not depends on your software's functional requirements. Secondly, it might ...


1

I think it really depends on the context you are working with. In your example, you are sending the TheObject instance to the PassTheObjectHere constructor, this way of working tells me that, inside your PassTheObjectHere instance, you are working with some previous initializated data. So if the ClassWithTheObject is going to share the conversational state ...


1

My opinion is that adding a type member is a better solution. It's simpler to define, allows you to treat the type as a first-class value, lets you code Product as a plain old data structure (which it is), works without RTTI, and you can use a switch instead of multiple if/else to efficiently branch based on the type. Using inheritance your code can break if ...


-1

If indeed you "must be able to differ each one in some operations" as you say, introducing three such intermediate classes is a perfectly sensible idea. Have a look at the idea of Abstract Class (e.g. in Java). An abstract class cannot be instantiated itself (most OO languages have a respective construct that will technically forbid instantiation) but it ...


2

It is not a real DTO, according to this definition of DTO. In that definition, a DTO is a streamlined, packaged object or group of objects without real behaviour. On the other hand, it is certainly a transfer object, by definition, and it certainly (likely) can package more than one object. Putting validation, especially inter-object validation in it makes ...


1

[Note: This question already has an accepted answer, and this answer only adds more arguments to it - but it is too long for a comment]. One such problem is deciding if a method should be part of the class or not. I have found a very good guideline offered by A. Stepanov on this question: He basically says that objects should be constructed from fully ...


4

I think the reason you are having trouble with which path to take is because there is a fundamental design flaw here. You have anemic classes here, which is itself an OO anti-pattern. The external logic that is switching on the type needs to be brought into the Product family of classes. The code smell for this is that, no matter which path you go, you will ...


-1

I think it's best to have one Product class with a type field, for a few reasons: If you ever need to serialize/deserialize in a way that the language doesn't natively support, there's only one constructor; you don't need to switch on the type and use one of several constructors. There's a slight benefit to readability - if readers see ElectricalProduct ...


3

Technically: no, this is not a violation of the LSP: The type Node gives us some guarantees here: Any method may work as documented below or return null or throw an exception. Any subtype of Node must still live by this contract. In practice: yes, this is a questionable design. The DOM interface seems to use a variant of the Composite Pattern, and the ...



Top 50 recent answers are included