Junilu Lacar

+ Follow
since Feb 26, 2001
Junilu likes ...
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
Forum Moderator
Columbus OH
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Junilu Lacar

Why would you name an object "EmployeeList" if it only represents one employee?

There are several ways to go about this but here are the main problems you have:

1. Figuring out which columns are included in the query and the order they will be in
2. Mapping the query columns to the appropriate setter() method on the object

For #1, you'll need metadata or you'll need to parse the text between "SELECT" and "FROM" of the query

For #2, for maximum flexibility, you'll have to use the Reflection API. Another option, although more tedious, would be to specify a "mapper" object for each query. That means you would potentially have to define as many mapper objects as you have queries. A mapper object will essentially have for its main logic whatever code you have in your while (rs.next()) loop.
10 hours ago

Daniel Demesmaecker wrote:@mod it really wasn't ment to be foul language, but more a figure of speach, but I will pay more attention in future

I know, which is why I just redacted that one word and not your entire post. Thank you for your cooperation.
1 day ago
Back at my keyboard now so I'll give you some concrete examples by what I mean when I say it's a matter of perspective.

This code is not very OO and is very puppeteer-ish:

With this code, the fact that patients are kept in a list is exposed for all to see. Then, you pass this list to a Patient and tell it to print out all the patients who have been admitted to the hospital. Even in real-world terms, that sounds kind of silly. Imagine being admitted into a hospital and someone coming to you with a list of all patients who have been admitted and telling you to read that entire list out. That's just not something you'd ask a patient to do, either in the virtual software world or in the real world.

This would be more OO and more director-ish:

Here, you have no idea what the underlying data structure is. All you know is that the Hospital object can somehow track the patients that get admitted to it via the admit(Patient) method. You also know that it can somehow print the list of patients who are currently admitted at that particular hospital. This code simply tells the Hospital object about other objects (Patient objects) and then tells the Hospital to do something related to all those patients it was informed about. How that information is managed is not anybody else's concern except the Hospital's.
2 days ago
It's a very common pattern that can be seen often: many programmers seem to have a tendency to let their imaginations run wild and create all kinds of complications for their programs and themselves.

The trick is to start with the simplest possible derivative of the problem. Want to print a Christmas tree made of "*" characters?

Instead of thinking of questions like "What if I want to print different sizes? What if I wanted to print different heights or widths? What if I wanted to put a star on top? What if I wanted to put presents under it?" You should train yourself to take the opposite tack and ask "How do I print a single *? Then how do I print 2 *s? Then how do I print 3 *s? And so on..."

In this case, if you had a 2-digit number, how would you separate the 1s digit from the 10s digit and get their sum? Then for 3-digit number, how to separate the 1s digit from the 10s fro. The 100s digit and getting their sum. And so on until you can generalize the problem to any N-digit number.
3 days ago

Dave Bloomberg wrote:Firstly I am trying to understand how to give a patient a specific list of Doctors, whenever I will have figured that out I will be able to figure out how to add and delete Doctors from appointments. All my issues are tied together with Appointments and ID[].

Why would you need to give a Patient object a list of Doctors? Conceptually, what exactly are you trying to do that requires a Patient object to go through a list of Doctors? The idea alone is making my spidey senses tingle like crazy.

As far as adding/deleting doctors from appointments, it's better to think from a more conceptual perspective. "Add/delete doctors" is a little too implementation-oriented. I would prefer to use more conceptual-oriented language like "assign a doctor" or "associate a doctor with an appointment" and "unassign" or "cancel". This moves your thinking away from implementation and closer to intent.

I'm on my phone so it's hard to type out a code example. Will do that later when I can reply from my laptop.
3 days ago

Daniel Demesmaecker wrote:I usualy take the firstletter of the classname, which coinsidentally in this case is i

Code should express intent, not implementation. In your case, your criteria for choosing a name, i, is essentially arbitrary.

Choose names that help express intent or purpose. Norm's suggestion is better than i, in my opinion.
3 days ago
Some useful design principles to refer to when considering assignment of roles and responsibilities and where best to encapsulate information/data:

GRASP - General Responsibility Assignment Software Patterns/Principles

Tell, Don't Ask

Law of Demeter

Code smell: Inappropriate intimacy
3 days ago

Campbell Ritchie wrote:But real‑life patients know they are in hospital (well, sometimes). That is why that design arises spontaneously.

That is the "making your program mimic the real world" trap. Object-orientation is about using abstractions and assigning appropriate responsibilities to them. Just because a person knows that they're hospitalized doesn't mean that they have to manage that information. If you go to a hospital, who else needs to know if a patient is hospitalized? The hospital needs to know who they have as patients. Doctors need to know who they have as patients. Should Doctor objects keep a list of all their patients as well? In the real world, yes. But a doctor in the real world knowing who their real world patients are is an entirely different story from a Doctor object knowing who the associated Patient objects are.

"Knowing" in the software sense is about managing and using the information to perform certain things. The assignment of "knowledge" to objects in software should be based on needing that information to fulfill a responsibility, not whether or not a real world person or thing actually would also have that knowledge. Designing the latter way is a dangerous trap to get into when it comes to OOP.
3 days ago

Dave Bloomberg wrote:About me being puppeteer - I am still unsure on how I could change that but I will put in the effort and time to understand that.

It's really mostly a matter of perspective. Kind of like the difference between a first-person versus a third-person style of writing.

Consider this code you wrote:

This is code that is in the main() method of your program. We have a saying around here that Main Is A Pain. We recommend not writing too much code in main(). This code is a good example of a "puppeteer" mindset when organizing code. You're involved in all the nitty-gritty details of doing the job, right down to telling the patient and doctor what lists they should add new elements to.

The main() method should be more like "turning on the lights and raising the curtain" to kick off a play. This is what code written from a "director" mindset might look like:

That's it.

Also, writing any method that is more than 30 lines (for beginners) is smelly. A long method with 30 or more lines is probably doing way too much in one place. Doing too much in one place makes your code complicated and difficult to understand and work with. This is what the execute() method might look like:

Notice how there's very little code in these methods and that the code does not have a lot of detailed information/data. The initial code in your program should be focused on telling a story of what's happening underneath. That story starts from very high level (execute the app) and slowly evolves into a more detailed story (initialize, do something, then cleanup) as you get deeper into the code. Every time you drill down one level, the story your program tells becomes more and more about specific tasks. For example, your code might eventually have something like this somewhere down the execution path:

This code might be called after you select "Add a new patient" from a menu, enter the details of the patient, then confirm the patient details. That is, the above addPatient() method might be called at some point in the execution of this code:

And the above method might be called from this high-level code:

Organizing your program this way makes it easier to manage and maintain different things that need to be done. Each method should be focused on doing only one specific thing. Methods that do multiple things should be broken down into multiple methods that each do only one specific thing. This is called functional decomposition. This is how you become more like a director or playwright rather than a puppeteer.
3 days ago
Welcome to the Ranch!

Right now, your program outputs "wrong" for every number it checks that isn't equal to the guess. Do you really want to do that? If not, then you might want to display the "wrong" message under different conditions at a different point in the program's execution.
3 days ago
The decision of who tracks the state of being "hospitalized" is a good example.

It's very conceivable, given what we've seen from the hundreds who post here asking for help, that many inexperienced students would decide to have the Patient object be responsible for tracking whether or not it has been hospitalized. The result is a Patient that looks something like this:

The student looks at that and thinks it's a reasonable design.

Experienced developers, however, will look at that code and detect a smell. Perhaps not a big smell at first, but just a hint that something related to this is going to kick up a big stink. And indeed, later on in the code, we do see that big smell.

When we saw this code, our reaction was probably something like this:

That's because we immediately recognize what design principles have been seriously violated here. The student, however, has no idea.
3 days ago
That's probably the most frustrating thing about seeing students writing programs like this. As experienced developers, we know the kind of problems they will run up against because of the design decisions they're making. The students on ther hand have no idea why they are struggling because they haven't been given guidelines on good design. They know how to operate the car, so to speak, but they don't know the rules of the road or how to navigate their way around hazards and potential pitfalls.
3 days ago

Dave Bloomberg wrote:

This is another example of code that indicates a very procedural-oriented mindset. Why is this method static? If you have a Hospital abstraction, it seems like it would make sense for a Hospital object to manage the list of Patients that have been admitted. Also, I don't think I'd have Patient track whether or not they are hospitalized. I would ask a Hospital object that question.

I would imagine Hospital would look something like this instead:

Also, the method you wrote violates an important design principle: CQS or Command-Query Separation.  See https://en.wikipedia.org/wiki/Command%E2%80%93query_separation
3 days ago
One way to understand where you're falling short of object-orientation is by this analogy.

Right now, you've written your code like you're a puppeteer. You hold all the strings and for anything to happen, you have to explicitly tell objects to do something and give them the information they should use to do those things. You're deeply involved in the action and your presence is felt all throughout the code.

On the other hand, when you've written a proper object-oriented program, you're more like a producer or writer of a play. You set the scene, give the objects their lines, tell them what their roles and responsibilities  are and give a general outline of the plot and story.  Then you just kick off things by turning the lights on and raising the curtain, giving the objects their cues to do their thing. When an object gets their cue, they go and do their thing. Your presence in the action is very minimal and when you read the code, it reads more like a story of how different objects interact with each other and fulfill the responsibilities of their roles in the larger story that is being told by the program. You shouldn't see a lot of detailed information flying around. Rather, all you should see is one object after another being told to do something with whatever information it is managing and to enlist the help of other objects as appropriate.
3 days ago

Dave Bloomberg wrote:If anyone has any advice to give about how I write my code or how I create methods : Please do not hesitate to insert this comment , if you do find a big mistake, feel free to harras me

Ok, since you asked...

Let me preface my comments with this: Learn to sniff out Code smells and when I say that the code is smelly, it's nothing personal. Rather, it's all about the code. You might also want to take a look at the 10 Commandments of Egoless Programming because when you ask for critiques of your code, it's best that you put yourself in that mindset.

With that said, let's begin.

The biggest and most glaring smell in the code is the prevalence of static methods. When there are more static method than there are instance methods in a class like Hospital, that raises a red flag and a big sign that flashes "Procedural code ahead!"

Indeed, there are many indications that you still have a way to go in terms of understanding object-oriented programming.

Here's one example:

Instances of a class like Appointment should represent a single appointment. As such, an Appointment object should know only about one particular appointment and exhibit behavior pertaining only to that particular appointment. Yet, this method will print information about all appointments. This kind of responsibility should not be given to any particular instance of an Appointment.  If you're going to have some kind of abstraction that knows about multiple Appointment objects, I would think that something like a Schedule would be more appropriate.

Moreover, the list of appointments isn't even something that an Appointment object manages. It's just given the list of Appointments and told to print them all out. That's another indication that the printAppointment() method does not belong in the Appointment class. An instance method should represent behavior that is specific that a particular instance of the class. Instance methods should use one or more pieces of information that the instance manages. If it doesn't, then you have to question why that method is an instance method at all.

Object orientation is about behaviors and responsibilities and assigning those to an appropriate abstraction so that the job of managing the information related to those behaviors and responsibilities can be abstracted and encapsulated within the object. Externally, you should have not have to care about the details. All you should care about are the results.

Here's how I would have designed some of the interactions you're trying to represent:

The Schedule class would look something like this maybe:

One key to thinking and designing in a more object-oriented manner is to regard objects as things that you can delegate small, focused jobs to. Information that relates to that job should be managed by the object itself. Things that the object needs to perform its job would be passed in as parameters. Parameters can be things like collaborators (like the System.out object passed to the printTo() method above) or values that may vary the behavior of an object in some way.

I'll pause here for now to let you digest some of this feedback.

I still have a lot more though.
3 days ago