How should you decide when it comes to choosing the first "class" to be written in a new app? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

开发者_如何学编程 Improve this question

How should you decide when it comes to choosing the first class to be written in a new application in the world of OOP&D?

If your application seems to have many independent & dependent modules, is there a useful guideline to keep in mind before having a decision?

Although there might not be any concrete rules or a formulation, I am sure there are some basic issues to think about first.

Thanks!

---

Consider using TDD practice. Write your test first, formulating it like:

[TestClass]
public class WhenUserDoesThingX()
{
 [TestMethod]
 public void MessageYIsDisplayed()
 {
  // ... var actual =
  Assert.AreEqual("Y", actual);
 }
}

The first class would be whatever you have to implement for the code of WhenUserDoesThingX to compile.

---

If you're following a very strict OOP paradigm then why not start with the lowest level of your domain? Typically this is something like a "Manager", "Scene", "Main" or "World" which will then 'possess' all your objects.

---

It depends on the methodology really.

If you're using scrum or something scrum-ish, you might want to start out by writing some basic functionality. Also if you're not a company and you are developing something on your own, it's nice to have something very basic you can show. Usually this means the core of your application. Start by making a tiny bit of working functionality and add the rest later!

However, basic waterfall methodology focuses on rewriting as few code as possible. They first define everything as good as possible and then implement everything part by part or even layer by layer. In that case, you should start with the data layer classes and some unit tests for them.

You can also try test-driven development! In that case, the first thing you write is unit tests for classes that are doing nothing. After that, implement the functionality in the classes and try to keep the unit tests green while doing so!

---

If you've done much design work up front, then you should have a good idea what each module is supposed to do, so in theory you could jump in wherever you want and code as if everything else is already in place.

I'll tell you that I'm building my first major PHP project right now, without any frameworks, etc. While building it, I have a pretty decent idea of how I want things to fall into place, so what I'm doing is starting with the minimum amount I need to get something to display on the screen. Where the code is expecting a class to exist, I write it as if it already does, and I'll make barebones classes so that it'll run without errors.

For example, I have a method which tries to decide which "Controller" class to hand things off to. It defaults to my "Home_Controller" class and calls new Home_Controller() but the Home_Controller, for the moment, is just this:

class Home_Controller {

}

It might be different in a corporate setting, but since you're starting from scratch I'm assuming you're working on your own project like me. The best thing is to just start with something that will give you immediate visual feedback. The ability to look at something and say "wow, I made that" will keep you going and push you through the more mundane parts of the project.

That's just my two cents.

---

In my experience this is decided by the road map.

When you are about to start a new project, you must to define some landmark's in the road. This landmark's or sub-functionalities have a sub-domain of all your objects associated with it, so it's define a place to start.

May be this is not much academical, but it's work for me.

---

Ok, even I am the one who asked the question, I would like to share my opinion as well; but thanks to all of you for your responses.

My opinion-although I don't want to insist as it is the best practice- is basically something like below. (@AgentConundrumIt: Yes, you are right, this is my own project.)

The list of things I plan to do before selecting class to write in the first place:

• Get the final requirements needed for the application from the customer
• Have a picture in your mind on the possible the UI
• Decide what development tools, environment, technologies, tools etc. you need to use
• List the modules of the application and see which modules are dependent or in relation to other ones directly in terms of domain logic
• List the possible "INDEPENDENT" or "Stand-alone" classes you need to create for each module of the application
• Design them "on the paper" with the best OOP structure so that they can be testable
• Score them with their logical complexity, possible dependencies(if still exist) and probability of possible future changes
• Choose a class to start with the lowest score (High score means hard to implement and possible to be changed in the future and harder to unit-test at this stage as well, relatively)
• Start writing the TEST(s) that fails for the chosen class
• Develop your first class; keep going developing your first class until you pass all your tests for it.

So basically I have something like this in my mind as a start-up.

What do you think?

---

I am unwilling to invest enough into any single class when starting a project to make the process of choosing a first class even noteworthy, much less require all the steps you have listed.

Usually there is some module (package) that is either a clear choice or at least part of a the key central core. I start there. Relationships are often the most important part of any model, so I start by creating classes and defining only the relationships, mapping them and writing unit tests for the mappings, and looking for any missing relationships or awkwardness.

Finding low dependency classes that are likely to be essential to the project is often a place I want to start some lower level developer, not myself. I myself want to jump into the key parts of a design where there are the most dependencies and find any problems ASAP. I tend to move a set of classes forward as a meaningful iteration or two before I start working in earnest on any one. Usually by the time that process is done I know exactly where I want to "start".