Win a copy of Learning OpenStack Networking: Build a solid foundation in virtual networking technologies for OpenStack-based clouds this week in the Cloud/Virtualization forum!

Junilu Lacar

Sheriff
+ Follow
since Feb 26, 2001
Junilu likes ...
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
Forum Moderator
Junilu Lacar currently moderates these forums:
Columbus OH
Cows and Likes
Cows
Total received
201
In last 30 days
2
Total given
73
Likes
Total received
1743
Received in last 30 days
32
Total given
314
Given in last 30 days
1
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Junilu Lacar

With Java enums, it's pretty straightforward to translate a String value to an equivalent enum value and vice versa. Just use the Enum.valueOf(String) and the Enum.toString() method, respectively.
4 hours ago

Jordi van Selm wrote:I make a 2D-array of the alphabet + the value of the letters and compare that to the char array (1D)...

Is there anyone willing to say which things I need to study?


I'd be willing to say you need to study object-oriented programming concepts some more. Using a 2D array with letter+value somehow mapped to each other is a very non-object oriented way of modeling the idea.

The letter and value are both attributes of a Scrabble "tile" are they not? They always go together, right? So that means a more natural object-oriented representation would be some kind of object, say a Tile, that has at least the attributes of "letter" and "value".
5 hours ago
Of course, when you search for Scrabble tile values, you quickly realize there are many sets of values depending on the language you're using.
5 hours ago
I like your idea to use an enum, Campbell, and yes, it seems like a straightforward proposition to implement double, triple letters. I would assign that responsibility to the Board or Square though. The Tile would just know its face value.
5 hours ago

Emily Rosemond wrote:This reason why I'm guessing is because a setter doesn't return anything, it sets a value. If it were to return something then it probably violates POLA, because clients didn't expect a setter to behave this way and I don't have authority to say it does violate POLA, I don't really know.



I'm guessing (see what I did there ) that you don't really know because you haven't been writing tests before you write the code.

One of the advantages of Test-Driven Development is that it makes you think about your API very carefully. Your tests become examples of how someone would use your class. If you read the test code or better yet, have someone else read the test code, and they don't understand why the code works that way, then you have probably violated POLA.

As an example of how to use the class under test, the test code should make sense to someone reading it for the first time. Otherwise, it's probably safe to say that the behavior you have coded into your object is surprising, or at least interesting in a not-so-good way.

A setter that returns a reference to the same object is interesting. It's not so surprising because it's a common pattern, especially when you're trying to create a fluent interface. The possibly not-so-good part is the rationale behind designing the setter method to return a self reference rather than just be a void method like most other setter methods. You have to be able to explain the reason using test code to show concrete examples why this is a good thing to do and a useful thing for users of your class.
11 hours ago

Emily Rosemond wrote:You might be able to, because you have years of experience, so you'll be able to look at the code and know, for beginners, it will take time.


Yes, I'm experienced but that only means I have made way more mistakes than you have.

"Experience is what allows us to recognize a mistake when we make it again."
11 hours ago

Emily Rosemond wrote:This code isn't meant for a program sitting in a publishing company or to interact with a sophisticated database. It's to illustrate my problem, Are there situations where it doesn't makes sense to follow DIP? Book and Author were the only example I could come up with. Why should a specific type of Author exist? Why should a sciencefictionauthor subclass exist? Why can't it be a label applied to an Author?


Why do you worry yourself over these things? As you said, it will take time for you to gain experience. The only way to gain experience is to actually practice. Write programs. Don't embark on flights of fantasy and imagination of what you would do if this or that thing were to happen. Don't try to NOT make mistakes. On the contrary, while you're still learning, try to make as many mistakes as you can. Then understand why they are mistakes and what you can do to avoid them in the future.

You're making a mistake right now by starting with a bunch of "What if" scenarios in your head. Stop that.

Find a good problem or exercise where the DIP or whatever principle you're trying to learn might apply. Then WRITE SOME CODE. Discover what kind of problems you encounter when you make one decision or another. If the code becomes difficult to work with, try to apply the principle you're trying to learn. Come back here and ask questions, ask for advice. We're more than willing to give you some, and more.

Good luck.
11 hours ago
Agility is not about making developers "produce more, faster" -- Seems like most people who claim to do Agile these days are getting it wrong. WTH.

Agility comes in the long run when developers are given the space to do their work at a SUSTAINABLE pace. That means they are allowed the time to write quality code. They are allowed time to learn. They are allowed time to make mistakes and learn even more.

When you have managers and tech leads cracking the whip as you have been describing, that's not developing at a sustainable pace. They are only driving your organization to the breaking point faster. When that happens, everybody loses.
12 hours ago

Paul Clapham wrote:... these days I find it hard to learn things by discussing theories. I find it much more useful to look at actual real-life examples (or reasonable approximations) and understand how they illustrate the theories (or how they conflict with them).


Yes, yes, yes.

Again, programmers should learn how to solve problems as they present themselves. The set of problems that can arise from a situation that involves hundreds of variables and moving parts is far too large for us to possibly predict and completely cover up front. We just have to do the best we can with what we know at the moment. As we learn more through testing and use of the program, we can expand our design and adapt it to handle a wider range of problems.

While you're still learning about the domain your program lives and operates in, however, focus on solving the known problems and making your program well-factored enough so it reflects your current understanding of how the program behaves as clearly and as cleanly as possible. That way, it will be easier for you and others to make changes when you discover more problems your program needs to handle.
13 hours ago

Emily Rosemond wrote:When a class is an attribute of another class, does it always make sense to follow DIP? Are there situations where following DIP will introduce more problems than it solves?


Any situation where the principle is applied to a problem it wasn't meant to address.

What problem are you addressing by applying DIP to this kind of relationship?

DIP says that less stable parts of your program should depend on more stable parts, and not the other way around. Now, what about dependency stability is a problem between Book and Author. Is one inherently more unstable than the other? If something changes about Author, is that change likely to break any code where the Book-Author dependency comes into play? Ask the same questions going the other way, too.

I don't have any answers for you other than those questions. Again, because I don't know what exactly is the problem you're trying to solve here.
14 hours ago

Emily Rosemond wrote:A common pattern is to abstract out the class behind an interface, but what happens if doing so is unnecessary or pointless.


Complexity happens.

A rider on a gray horse follows soon thereafter.

Ok, a bit too dramatic but the reality is not far off. Think of the kind of unnecessary pain and suffering overly-complex programs and designs have caused all these years and the money wasted because of it. That's why I'm a big believer in YAGNI (You ain't gonna need it) and DTSTTCPW (Do the simplest thing that could possibly work). It's also why I lost all my hair. Well, a big part of the reason, at least.
14 hours ago

Campbell Ritchie wrote:

Paul Clapham wrote:. . . more than one Author. A design could implement that by having Book have a List of Authors, or you could force Author to take care of the list possibility. . . .

I think I would prefer the book to have a List of authors. If you have a book like Gamma Helm Johnson and Vlissides, with four authors, which author would hold the List? And I wouldn't want such a List as a static field of Author, so it probably belongs to the book.
An Author might also have a List<Book> showing their oeuvre. But that latter is making things too complicated, maybe.



Ok, I'll bite, with the caveat that I would only really go down this path of discussion if I knew of a real need that it would satisfy, that it's not something I'm doing "just in case."

My intuition would guide me back to GRASP - General Responsibility Assignment Software Principles/Patterns and also entity-relationship analysis. Specifically, the Pure Fabrication and Join Table. Perhaps I have a BookAuthorMatchingService that keeps a record of Author-Book pairings. Those who are familiar with database design will recognize this as a many-to-many join table.

With that nugget of an idea dug up by intuition (remember what I said earlier, intuition is nothing more and nothing less than recognition), I would explore the other design decisions that would lead me to. Since I know nothing of the problem and the context around these discussions, I will say no more than that.
18 hours ago

Emily Rosemond wrote:Given the requirements, my question still remains, and it's a simple yes or no. Author is an attribute of the Book class, does it make sense to abstract it out?


Maybe I missed it but what are the actual requirements? At face value and not knowing anything about the context, my answer would be a quick "No".
19 hours ago

Emily Rosemond wrote:I wanted to keep the Author immutable


This is a good place to start. It heads off many problems that start with mutability.

... but if on some rare occasion, an attribute needed to change, I would need to create a whole new object reflecting that change.


Why? What told you this was needed? Was it a bad code smell? Or was it "intuition"? Intuition is a double-edged sword. If you have a failing test or some kind of bad smell in your code that tells you something needs to be changed, intuition can guide you to the better choice.

Daniel Kahneman gives a quote in his book, "Thinking Fast and Slow"

The situation has provided a cue; this cue has given the expert access to information stored in memory, and the information provides the answer. Intuition is nothing more and nothing less than recognition. —Herbert Simon


In other words, Andy Hunt's Rule#1: Always consider context.

On the other hand, when we try to use intuition to predict the future, things seldom work out the way we thought they would. I had an intuition yesterday as I was walking through the airport that I would come into a lot of money, so I bought a MegaMillions ticket from a kiosk. I woke up this morning and I still don't have 650 million dollars in the bank. I guess I'll have to stick with my backup retirement plan now.

What situation (in other words, context) exists around your decision? Don't design in a vacuum. If you're going to be a programmer, learn how to solve problems. Don't imagine problems up for yourself to solve.

My guess is it will violate the POLA.


The key word there is "guess." Don't guess at problems; address them when they come up. Again, just make your code clean enough so you can easily refactor it to address any problems that come up.
21 hours ago

Paul Clapham wrote:I'd consider statements like "Book shouldn't know about Author" to be pontificating -- in other words I'm more practical than theoretical these days.


Yes, that.

To me, object-oriented programming is about good abstractions that represent ideas in your problem domain. The goal in OOAD is to discover and create those good abstractions and properly assign responsibilities to them so you can satisfy the users' current needs. I think that it's premature to dive deeply into discussions about proper abstractions and relationships if you don't have requirements that create the need to model those kinds of relationships in your system. That's kind of putting the cart way before the horse.

Try to think of it this way for a minute: What code smell(s) does the statement "Book shouldn't know about Author" address? How does a "Book knowing about Author" make it cumbersome to work with the code and add new functionality or enhance current functionality?

Don't try to model the real world in your program. That's not what OO was for. Rather, use what you and other people know about real world objects as metaphors that people can use to reason about the relationships between ideas in your problem domain and the objects that you use to represent those ideas and their relationships and responsibilities. When you have abstractions that represent the ideas in the problem domain well, the semantics of the real-world metaphors we use will usually lead to a decision on whether it's appropriate to model a relationship as "is a" or "has a" or whatever.
23 hours ago